LINUX.ORG.RU

Планы по выпуску GTK+ версии 3

 


1

0

В списке рассылки gtk-devel-list обсуждаются планы выпуска GTK+ версии 3. Основные подготовительные действия, которые необходимо предпринять в текущей ветке:

  • Спрятать все открытые поля структур с помощью макроса GSEAL(). В случае необходимости предоставить новые методы доступа к этим полям. Также должны быть скрыты поля-указатели "priv" на структуры, содержащие закрытые данные. Эти действия уже практически полностью проведены в репозитории git://git.imendio.com/projects/gtk+.git
  • Реализовать закрытые члены класса, что включает изменения в коде GType.
  • Объявить как deprecated публичные данные класса с помощью макроса GSEAL().
  • Поскольку не останется простого способа для доступа к полям класса, а использование g_object_[sg]et() утомительно, необходимо ввести новые методы доступа, вроде g_object_get_int(), *double(), *string() и т.д.
  • Существует множество макросов, таких как GTK_WIDGET_GET_FLAGS(), которые всегда были причиной многочисленных проблем (см. bug #69872). Необходимо реализовать нормальные методы доступа (в виде функций) и избавиться от этих макросов.
  • GtkStyle, без сомнений, самый сложный тип, нуждающийся в скрытии публичных полей, и до релиза должно быть проведено множество исследований.
  • Избавиться от всего кода, объявленного deprecated в 2.x. Это подразумевает все соответствующие виджеты и функции.
  • Удалить все поля структур из публичного API. Есть два способа достичь этого:
    a) переместить все структуры в закрытые заголовки;
    b) переместить структуры в C-файл реализации, но тогда всей библиотеке придётся использовать соответствующие методы доступа.
    Эти варианты ещё обсуждаются.
  • Отключить deprecated-код по умолчанию во флагах компиляции.
Таким образом, версия 3.0 будет готова к релизу. Все приложения, которые собираются для ветки 2.x с макросом GSEAL() и не используют deprecated-кода, будут без проблем собираться для ветки 3.x. Наверное, таким образом разработчики пытаются избежать кошмара миграции, который можно видеть на примере библиотеки Qt.

>>> Подробности

★★★★

Проверено: JB ()
Ответ на: комментарий от MYMUR

>>gtk правильнее было бы сравнивать с kdelibs а не с qt

>Он с Qt-то по большому счёту в разных весовых категориях находится, т.к. один из них --- гуй-либа, а другой --- целый фреймворк, а ты его ДЕ-либой предлагаешь сравнивать.... о_О

В какой-то степени это приемущество Gtk. Он делает то, что должен, и не больше. Нужны БД и прочее - обратитесь к соответствующим либам.

xTERM ★★
()
Ответ на: комментарий от xTERM

>В какой-то степени это приемущество Gtk. Он делает то, что должен, и не больше. Нужны БД и прочее - обратитесь к соответствующим либам.

Э-э-э... а в чём выражается это "преимущество", можно слегка развернуть мысль? QtGui как бы тоже "делает то, что должен, и не больше".

Или тебя кто-то заставляет юзать QtXml если он тебе не нужен? Или ты думаешь, что я не могу вместо него заюзать libxml2, если мне вдруг захочется?

Жду пояснений....

MYMUR ★★★★
()
Ответ на: комментарий от xTERM

>К тому же Qt3 был монолитным, не забывай.

поясни

anonymous
()
Ответ на: комментарий от xTERM

> В какой-то степени это приемущество Gtk. Он делает то, что должен, и не больше. Нужны БД и прочее - обратитесь к соответствующим либам.

А потом трахайся с тем, что либа для работы с бд вернула тебе текст как wchar_t*, а не Glib::ustring. Ну ладно, настоящий индеец и это заборет кучей макросов и биндингов.

gaa ★★
()
Ответ на: комментарий от gaa

> А потом трахайся с тем, что либа для работы с бд вернула тебе текст как wchar_t*, а не Glib::ustring. Ну ладно, настоящий индеец и это заборет кучей макросов и биндингов.

+1 Вы не сравнивайте RAD Qt и SAD GTK+какая-то_либа

troorl ★★
()
Ответ на: комментарий от gaa

>Ну ладно, настоящий индеец и это заборет кучей макросов и биндингов.

Посмеялся)

xTERM ★★
()
Ответ на: комментарий от xTERM

>Я просто говорю, что лучше, когда это разные проекты.

Конечно лучше. Скажу больше: это просто охрененно, когда для написания той или иной программы нужна пачка разнородных библиотек разных версий, с разными системами сборки, с разным подходом к стабильности API, с разным стилем именования в конце концов! А особенно хорошо эти прелести раскрываются, когда встаёт вопрос переносимости на другую платформу....

Продолжай, я записываю.

MYMUR ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.