URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 40703
[ Назад ]

Исходное сообщение
"OpenNews: GTK+: перспективы развития"

Отправлено opennews , 17-Мрт-08 14:54 
Библиотека GTK+ прошла долгий путь развития и сейчас очень популярна. GNOME, одна из ведущих оконных сред, использует GTK+ почти исключительно, GIMP построен на GTK+,  множество коммерческих разработчиков ПО, таких как Abobe, NVidia и VMware, решили использовать эту библиотеку в качестве графической основы для своих продуктов.


Тем не менее, у GTK+ все еще имеется ряд серьезных недостатков. Развитие второй версии началось в 2002 году. С тех пор GTK+ заметно повзрослела. Но, на протяжении всего цикла разработки версии 2.x,  разработчики сохранили ABI (двоичный интерфейс приложения) совместимым. Разработчики приложений, использующих GTK+, очень рады этому обстоятельству: они могут быть уверены, что их программы продолжат работать без всяких изменений и с новыми версиями GTK+. Пакеты, выпущенные в 2002 году продолжают работать с самыми последними версиями GTK+. Это очень важно, так как сторонние разработчики приложений избавляются от необходимости пересобирать свои пакеты только потому, что во всех дистрибутивах постоянно обновляется GTK+. Для коммерческих компаний это означает лишнюю работу и проблемы, и, как следствие, расходы.


Обязательство не нарушать ABI сделало многих людей счастливыми. Но это обязательство налагает очень жесткие ограничения на развитие GTK+.  Не очень просто добавлять новые функции и оставлять ABI совместимым. Незначительные улучшения — да. Но как только требуется внести радикальные изменения возникают серьезные неприятности, а иногда это и вовсе невозможно.


На конференции GTK+ Hackfest 2008 в Берлине, разработчики представили свое видение будущего GTK+ и причины, по которым соглашения по ABI должны быть разорваны. Другие разработчики  обозначили те части GTK+, которые могут и должны улучшаться без нарушения совместимости.

Оформление (theming)
. Оформление является одним из важнейших аспектов GTK+, нуждающимся в серьезном пересмотре, ведь концепция не менялась с самых первых релизов.  В результате, очень трудно реализовать некоторые модные графические идеи или сделать пользовательские виджеты, которые стали бы частью рабочего стола. Поэтому, планируется сделать оформление в стиле CSS.

Анимация
. Хотя создание анимации и возможно в GTK+, но связано со значительными трудностями. Исходя из желания создать приятный интерфейс в стиле iPhone, были созданы дополнительные библиотеки: Clutter, Pigment и Moonlight. Все они имеют недостатки: Clutter не использует систему событий GLib, Moonlight написан на C++, а Pigment еще в очень грубом состоянии. Однако, есть четкое понимание того, как эти библиотеки могут взаимодействовать с GTK+ и что требуется сделать, чтобы это стало возможным.

Холст (Canvas)
. GTK+ не имеет стандартного холста. Существует GnomeCanvas, но он не очень популярен и в нем нет некоторых ключевых возможностей. Многие разработчики прибегают к помощи Cairo, когда речь идет о произвольной графике, но в Cairo отсутствует способ прорисовки элементов GUI. Есть еще несколько кандидатов для GTKCanvas и все они не лишены серьезных недостатков. И тогда возникает вопрос: вообще, специализированный canvas — это хорошая идея? Вместо введения специализированных библиотек для рисования можно использовать вышеупомянутые анимационные библиотеки.

Интеграция с операционной системой
. GTK+ не ограничивается использованием только совместно с X11. Многие  приложения на GTK+, портированые в Windows, пользуются удивительной популярностью. Inkscape, например, имеет значительную базу Windows-пользователей. Многие приложения широко используют возможности операционной системы, но, в настоящее время, GTK+ предоставляют к ней сильно ограниченный доступ. Хотя, первые решения этой проблемы уже появляются (libgtkhotkey 0.1).

Интроспекция (introspection)
. Самой обсуждаемой темой среди разработчиков GTK+, за последние несколько месяцев, является интроспекция. Интроспекция позволяет инспектировать объект, его методы и наследования. Это очень удобно не только для отладки, но также позволяет очень легко создавать «обертки» (binding) для любых других языков программирования. Пока еще не все готово, но первые результаты удивительны.


Возможно, пройдет еще немало времени, пока GTK+ 3.0 будет выпущен. И даже в версии 3.0 не будет всех вышеперечисленных возможностей. Сначала будут исправлены «ошибки прошлого» (например, общая доступность приватных структур данных) и лишь к версии 3.2 начнут добавляться новые возможности. Одно можно сказать наверняка: GTK+ будет снова выглядеть очень интересно.

URL: http://federkiel.wordpress.com/2008/03/12/gtk-30-getting-ser.../
Новость: http://www.opennet.me/opennews/art.shtml?num=14771


Содержание

Сообщения в этом обсуждении
"GTK+: перспективы развития"
Отправлено Аноним , 17-Мрт-08 14:58 
Создание третьей ветки, внутри которой будут несовместимые друг с другом варианты - 3.12.6a, 3.12.6b и т.д. Почему нет?

"GTK+: перспективы развития"
Отправлено анонимус , 17-Мрт-08 15:44 
>Создание третьей ветки, внутри которой будут несовместимые друг с другом варианты -
>3.12.6a, 3.12.6b и т.д. Почему нет?

А обслуживать все три ветки будете вы???


"OpenNews: GTK+: перспективы развития"
Отправлено Architect , 17-Мрт-08 19:02 
На мой взгляд, при таких требованиях к совместимости версий, было бы лучше предоставить пользователям GTK+ развитые унифицированные интерфейсы для создания библиотек компонентов. По-моему, когда-то давно, такая идея уже была озвучена в комьюнити. При таком подходе не придется трогать само ядро, зато новые компоненты смогут создавать все кому это нужно.

"OpenNews: GTK+: перспективы развития"
Отправлено a2 , 17-Мрт-08 21:05 
>На мой взгляд, при таких требованиях к совместимости версий, было бы лучше
>предоставить пользователям GTK+ развитые унифицированные интерфейсы для создания библиотек компонентов. По-моему,
>когда-то давно, такая идея уже была озвучена в комьюнити. При таком
>подходе не придется трогать само ядро, зато новые компоненты смогут создавать
>все кому это нужно.

при этом сохранив совместимость? многовато им поработать пришлось бы.


"GTK+: перспективы развития"
Отправлено Аноним , 17-Мрт-08 22:43 
"Все они имеют недостатки: ... Moonlight написан на C++.. "
"Самой обсуждаемой темой среди разработчиков GTK+, за последние несколько месяцев, является интроспекция. Интроспекция позволяет инспектировать объект, его методы и наследования."

я вот что не понимаю. как можно, мысля терминами обектов, отказываться использовать обьекты?


"GTK+: перспективы развития"
Отправлено Аноним , 18-Мрт-08 11:10 
"Все они имеют недостатки: ... Moonlight написан на C++.. "

Скорее на С# http://www.mono-project.com/Moonlight