[devel] Gtk+ и DirectFB

[devel] Gtk+ и DirectFB

[Alexey Rusakov]

Доброго времени суток.

За это лето я узнал о по крайней мере двух людях (lav@ и legion@, 
возможно, есть кто-то ещё), заинтересованных в появлении в Сизифе сборки 
Gtk+ с DirectFB вместо Xlib. Апстрим Gtk+ относится к этому 
благосклонно, и версия 2.10.2 не просто собирается с DirectFB, а даже 
пытается работать. На данный момент есть несколько вопросов скорее 
организационного плана:
1. DirectFB в Сизифе старый. Хотя на данном этапе не это является слабым 
местом, всё же хочется понять, насколько нынешний мейнтейнер в нём 
заинтересован.
2. Требуется собрать Cairo с поддержкой DirectFB. Принципиальных 
сложностей здесь никаких, Cairo можно собрать с одновременной поддержкой 
обоих библиотек (Xlib и DirectFB), но для пакета, разумеется, это будет 
ещё одна зависимость (от libdirectfb). Выслушиваются мнения о том, 
насколько это будет мешать, кроме того, есть вопрос мейнтейнерства 
(поддержку DirectFB проверять, видимо, буду в основном я, а не at@). 
Возможно, стоит создать тим.
3. В отличие от Cairo, Gtk+ поддерживать одновременно и Xlib, и DirectFB 
- не умеет. Сборки с разными backends пересекаются друг с другом по 
файлам. Посему вопрос к заинтересованным в сборке людям: может ли 
потребоваться одновременное присутствие в системе libgtk+2 и 
libgtk+2_dfb? Судя по обсуждению с lav@, в основном это может 
потребоваться мне, поскольку я работаю в иксах, и каждый раз подменять 
библиотеку для тестирования неохота, а сетапить виртуальную машину под 
это, честно говоря, лень, да и неясно, насколько будет работать. В любом 
случае, вопрос: стоит ли заниматься распиливанием libgtk+2 так, чтобы 
можно было держать на машине оба пакета одновременно?

Засим пока всё, жду ответов от всех, кому это интересно.

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Alexey Rusakov пишет:
> Доброго времени суток.
> 
> За это лето я узнал о по крайней мере двух людях (lav@ и legion@, 
> возможно, есть кто-то ещё), заинтересованных в появлении в Сизифе сборки 
> Gtk+ с DirectFB вместо Xlib. Апстрим Gtk+ относится к этому 
> благосклонно, и версия 2.10.2 не просто собирается с DirectFB, а даже 
> пытается работать. На данный момент есть несколько вопросов скорее 
> организационного плана:

А можете куда-нибудь это выложить? ... очень хочется протестировать :)

> 1. DirectFB в Сизифе старый. Хотя на данном этапе не это является слабым 
> местом, всё же хочется понять, насколько нынешний мейнтейнер в нём 
> заинтересован.

Если будет сборка с Gtk2 с DirectFB, то я могу взять у Валеры
libdirectfb ... мне он будет нужен.

> 2. Требуется собрать Cairo с поддержкой DirectFB. Принципиальных 
> сложностей здесь никаких, Cairo можно собрать с одновременной поддержкой 
> обоих библиотек (Xlib и DirectFB), но для пакета, разумеется, это будет 

В этом случае будут зависимости не нужные для DirectFB

$ ldd /usr/lib/libcairo.so.2.9.1 |grep X
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xa7e17000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xa7d36000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xa7be1000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xa7bdc000)

А для сборки с Xlib будет лишняя зависимость на libdirectfb ... это не
желательно для обоих бэкендов ... не лучше ли сделать две разные
сборки с разными бэкендами ?

> ещё одна зависимость (от libdirectfb). Выслушиваются мнения о том, 
> насколько это будет мешать, кроме того, есть вопрос мейнтейнерства 
> (поддержку DirectFB проверять, видимо, буду в основном я, а не at@). 
> Возможно, стоит создать тим.
> 3. В отличие от Cairo, Gtk+ поддерживать одновременно и Xlib, и DirectFB 
> - не умеет. Сборки с разными backends пересекаются друг с другом по 
> файлам. Посему вопрос к заинтересованным в сборке людям: может ли 
> потребоваться одновременное присутствие в системе libgtk+2 и 
> libgtk+2_dfb? Судя по обсуждению с lav@, в основном это может 
> потребоваться мне, поскольку я работаю в иксах, и каждый раз подменять 
> библиотеку для тестирования неохота, а сетапить виртуальную машину под 
> это, честно говоря, лень, да и неясно, насколько будет работать. В любом 
> случае, вопрос: стоит ли заниматься распиливанием libgtk+2 так, чтобы 
> можно было держать на машине оба пакета одновременно?

Если такое будет, то будет замечательно.

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

> > 1. DirectFB в Сизифе старый. Хотя на данном этапе не это является слабым
> > местом, всё же хочется понять, насколько нынешний мейнтейнер в нём
> > заинтересован.
>
> Если будет сборка с Gtk2 с DirectFB, то я могу взять у Валеры
> libdirectfb ... мне он будет нужен.

мне он уже давно без надобности. отдам хоть щас

-- 
Valery V. Inozemtsev

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Gtk+ и DirectFB

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]

On Mon, Aug 28, 2006 at 11:05:51AM +0400, Alexey Gladkov wrote:
> Если будет сборка с Gtk2 с DirectFB, то я могу взять у Валеры
> libdirectfb ... мне он будет нужен.

Я тоже хотел поковырять directfb, но я не умею его тестировать.
Сходу претензии к нему такие: soname привязн к версии; если бинарная
совместимость сохраняется, то можно вписать в Provides старый soname.
В пакете libdirectfb самый большой файл -- ChangeLog; при том, что также
имеется файл NEWS, паковать ChangeLog точно не стоит.  Low-level ChangeLog
в пакете нужен не больше, чем исходники.  Кстати это касается всех пакетов.

> > 2. Требуется собрать Cairo с поддержкой DirectFB. Принципиальных 
> > сложностей здесь никаких, Cairo можно собрать с одновременной поддержкой 
> > обоих библиотек (Xlib и DirectFB), но для пакета, разумеется, это будет 
> 
> В этом случае будут зависимости не нужные для DirectFB
> 
> $ ldd /usr/lib/libcairo.so.2.9.1 |grep X
>         libXrender.so.1 => /usr/lib/libXrender.so.1 (0xa7e17000)
>         libX11.so.6 => /usr/lib/libX11.so.6 (0xa7d36000)
>         libXau.so.6 => /usr/lib/libXau.so.6 (0xa7be1000)
>         libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xa7bdc000)
> 
> А для сборки с Xlib будет лишняя зависимость на libdirectfb ... это не
> желательно для обоих бэкендов ... не лучше ли сделать две разные
> сборки с разными бэкендами ?

Делать две сборки libcairo?  Да ну!  Уж лучше пусть будет зависимость на
libdirectfb.  Это довольно маленькая библиотека (300K), если ChangeLog
выкинуть.

Но если собирать libcairo+libdirectfb без libX11 вообще -- тогда другое дело.
Только не знаю есть в этом смысл или нет.  И soname'ами что делать.  Они
ведь провайдятся.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Valery V. Inozemtsev пишет:
>>> 1. DirectFB в Сизифе старый. Хотя на данном этапе не это является слабым
>>> местом, всё же хочется понять, насколько нынешний мейнтейнер в нём
>>> заинтересован.
>> Если будет сборка с Gtk2 с DirectFB, то я могу взять у Валеры
>> libdirectfb ... мне он будет нужен.
> 
> мне он уже давно без надобности. отдам хоть щас

Как только по пробую Gtk2 с DirectFB :)

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Alexey Tourbin пишет:
> Я тоже хотел поковырять directfb, но я не умею его тестировать.
> Сходу претензии к нему такие: soname привязн к версии; если бинарная
> совместимость сохраняется, то можно вписать в Provides старый soname.
> В пакете libdirectfb самый большой файл -- ChangeLog; при том, что также
> имеется файл NEWS, паковать ChangeLog точно не стоит.  Low-level ChangeLog
> в пакете нужен не больше, чем исходники.  Кстати это касается всех пакетов.

Думаю, это можно пофиксить.

> Делать две сборки libcairo?  Да ну!  Уж лучше пусть будет зависимость на
> libdirectfb.  Это довольно маленькая библиотека (300K), если ChangeLog
> выкинуть.

Обратная ситуация хуже.

> Но если собирать libcairo+libdirectfb без libX11 вообще -- тогда другое дело.
> Только не знаю есть в этом смысл или нет.  И soname'ами что делать.  Они
> ведь провайдятся.

Думаю смысл есть. Это нужно для встроенных систем. Тянуть libX*
библиотеки в этом случае не имеет смысла ... более того это накладно.

По сути в этом случае библиотеки будут замещать друг друга так как API
и ABI у них не должен меняться.

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Led]

В сообщении от 28 августа 2006 11:29 Alexey Gladkov написал(a):
> Alexey Tourbin пишет:
> > Я тоже хотел поковырять directfb, но я не умею его тестировать.
> > Сходу претензии к нему такие: soname привязн к версии; если бинарная
> > совместимость сохраняется, то можно вписать в Provides старый soname.
> > В пакете libdirectfb самый большой файл -- ChangeLog; при том, что также
> > имеется файл NEWS, паковать ChangeLog точно не стоит.  Low-level
> > ChangeLog в пакете нужен не больше, чем исходники.  Кстати это касается
> > всех пакетов.
>
> Думаю, это можно пофиксить.
>
> > Делать две сборки libcairo?  Да ну!  Уж лучше пусть будет зависимость на
> > libdirectfb.  Это довольно маленькая библиотека (300K), если ChangeLog
> > выкинуть.
>
> Обратная ситуация хуже.
>
> > Но если собирать libcairo+libdirectfb без libX11 вообще -- тогда другое
> > дело. Только не знаю есть в этом смысл или нет.  И soname'ами что делать.
> >  Они ведь провайдятся.
>
> Думаю смысл есть. Это нужно для встроенных систем. Тянуть libX*
> библиотеки в этом случае не имеет смысла ... более того это накладно.

Это тянет чуть ли не на новый Arch (embeded или как его там...)

>
> По сути в этом случае библиотеки будут замещать друг друга так как API
> и ABI у них не должен меняться.

-- 
Led.

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Led пишет:
> Это тянет чуть ли не на новый Arch (embeded или как его там...)

А есть ещё что-нибудь кроме Gtk, Pango, Cairo что нужно собирать в так
называемый embeded ?

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Led]

В сообщении от 28 августа 2006 13:17 Alexey Gladkov написал(a):
> Led пишет:
> > Это тянет чуть ли не на новый Arch (embeded или как его там...)
>
> А есть ещё что-нибудь кроме Gtk, Pango, Cairo что нужно собирать в так
> называемый embeded ?

QT-Embeded?

-- 
Led.

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Led пишет:
> QT-Embeded?
> 

Это понятно. :)
А ещё что-нибудь ?

-- 
Rgrds, legion

Re: [devel] Gtk+ и DirectFB

[Led]

В сообщении от 28 августа 2006 14:39 Alexey Gladkov написал(a):
> Led пишет:
> > QT-Embeded?
>
> Это понятно. :)
> А ещё что-нибудь ?

Ну, наверное, весь прикладной софт, собранный с соответствующими Qt и GTK+ и с 
libdirectfb вместо libX*. По крайней мере, скриншоты GIMP в FB видел ещё года 
3 назад:)

-- 
Led.

Re: [devel] Gtk+ и DirectFB

[Alexey Gladkov]

Led пишет:
> В сообщении от 28 августа 2006 14:39 Alexey Gladkov написал(a):
>> Led пишет:
>>> QT-Embeded?
>> Это понятно. :)
>> А ещё что-нибудь ?
> 
> Ну, наверное, весь прикладной софт, собранный с соответствующими Qt и GTK+ и с 
> libdirectfb вместо libX*. По крайней мере, скриншоты GIMP в FB видел ещё года 
> 3 назад:)
> 

Как раз этого и не требуется. Изменяется только бэкенд у библиотек, а
API, ABI не меняется... или я заблуждаюсь ?

-- 
Rgrds, legion

Re: [devel] Embedded Sisyphus

[Alex V. Myltsev]

Alexey Gladkov wrote:
> Led пишет:
>> QT-Embeded?
> Это понятно. :)
> А ещё что-нибудь ?

uСlibc, и всё с ним собирать?
Если уж embedded.

busybox вместо *utils (или вместе, но чтобы зависимости позволяли одно
на другое поменять).

dropbear туда утащить ("created _only_ for embedded systems").

Возможно, init-ng или другой параллельный init, если с ним грузиться
будет быстрее.

Мог бы получиться репозиторий для сборки appliances. Со своими
особенностями: не важна обновляемость пакетов (потому что appliance
обновляется целиком), не важна совместимость со взрослым Сизифом (потому
что на разных машинах они работают). Маленький хакерский репозиторий :).

Re: [devel] Embedded Sisyphus

[Anton Farygin]

Alex V. Myltsev wrote:
> Alexey Gladkov wrote:
>> Led пишет:
>>> QT-Embeded?
>> Это понятно. :)
>> А ещё что-нибудь ?
> 
> uСlibc, и всё с ним собирать?
> Если уж embedded.
> 
> busybox вместо *utils (или вместе, но чтобы зависимости позволяли одно
> на другое поменять).
> 
> dropbear туда утащить ("created _only_ for embedded systems").
> 
> Возможно, init-ng или другой параллельный init, если с ним грузиться
> будет быстрее.
> 
> Мог бы получиться репозиторий для сборки appliances. Со своими
> особенностями: не важна обновляемость пакетов (потому что appliance
> обновляется целиком), не важна совместимость со взрослым Сизифом (потому
> что на разных машинах они работают). Маленький хакерский репозиторий :).

Идея весьма интересна.

Только с рядом дополнений. busybox я бы выкинул, ибо всё равно его если 
и собирать, то под конкретную задачу.. uClibc.. сложно сказать.

Вообще на самом деле мне становится интересно видеть Sisyphus на X-Scale 
;) и для X-Scale. имеется в виду всё, что нужно для разработки на 
обычном PC под arm. Весь сизиф на arm, это конечно перебор, но хотя бы 
базовую часть я бы не отказался ;)

там правда возникает вопрос, на который уже есть ответ..

что делать с RPM ? выкинуть!

Rgds,
Rider

Re: [devel] Embedded Sisyphus

[@ 2006-08-28 13:29 UTC (permalink / raw)]

Re: [devel] Embedded Sisyphus

[@ 2006-08-28 13:33 UTC (permalink / raw)]

Re: [devel] Выкинуть RPM

[@ 2006-08-28 13:43 UTC (permalink / raw)]

Re: [devel] Embedded Sisyphus

[@ 2006-08-28 14:00 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 19:04 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 19:16 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 19:27 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 19:37 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 19:43 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 20:22 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 20:28 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 20:41 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 20:42 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 20:56 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 21:04 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 21:33 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 21:37 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 21:46 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-28 22:23 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-29 6:11 UTC (permalink / raw)]

Re: [devel] Embedded Sisyphus

[@ 2006-08-29 6:20 UTC (permalink / raw)]

Re: [devel] Embedded Sisyphus

[@ 2006-08-29 11:58 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-29 18:37 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-30 6:31 UTC (permalink / raw)]

Re: [devel] Embedded Sisyphus

[@ 2006-08-31 9:08 UTC (permalink / raw)]

Re: [devel] Embedded Sisyphus

[@ 2006-08-31 18:55 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-08-31 19:23 UTC (permalink / raw)]

Re: [devel] Embedded Sisyphus

[@ 2006-09-01 9:18 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-09-01 13:37 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-09-01 23:33 UTC (permalink / raw)]

Re: [devel] Gtk+ и DirectFB

[@ 2006-09-01 23:42 UTC (permalink / raw)]

Re: [devel] Embedded Sisyphus

[@ 2006-09-02 13:19 UTC (permalink / raw)]

Re: [devel] Embedded Sisyphus

[@ 2006-09-04 5:27 UTC (permalink / raw)]

Re: [devel] Embedded Sisyphus

[@ 2006-09-04 9:23 UTC (permalink / raw)]

Re: [devel] Embedded Sisyphus

[@ 2006-09-04 12:59 UTC (permalink / raw)]

Re: [devel] Embedded Sisyphus

[@ 2006-09-05 8:46 UTC (permalink / raw)]

Re: [devel] Embedded Sisyphus

[@ 2006-09-06 8:23 UTC (permalink / raw)]

Re: [devel] Embedded Sisyphus

[@ 2006-09-07 8:12 UTC (permalink / raw)]