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 ()

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

Итак, "gobject на уровне пользователя идеален", а глупая команда гном-девелоперов зачем-то в 3-й версии пытается "Спрятать все открытые поля структур с помощью макроса GSEAL()"...

Супер!!!

Так что же эти идиоты, гном-девелоперы, не спросили премудрого xTERM ???

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

> Почти плюсы :)

Зачем мне нужны почти плюсы, если есть полностью плюсы?

> Если _особо_ лень - возьми готовые "препроцессоры" по-типа Vala

Вала, конечно, достойна изучения. Но сомневаюсь, что в ней будет такая же свобода менять реализацию, как в С++, не говоря уже о С.

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

Я вообще смотрю с третьей стороны. Надо найти/сделать хороший __лексический__ препроцессор над С. А недо-плюсы мне не нужны.

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

> Я вообще смотрю с третьей стороны. Надо найти/сделать хороший __лексический__ препроцессор над С. А недо-плюсы мне не нужны.

Если честно, так и не врубился, что там за модульное ОО предполагается. Из ближайшего релевантного помню Seed7.

Nihilist
()
Ответ на: комментарий от no-dashi

>Между прочим, все приложения, собранные с Gtk-2.X1.Y, без перекомпиляции запускаются на любой версии Gtk-2.X2.Y, при условии что X2 > X1. Так что не стоит Qt-шникам троллить про "кошмары" :-)

Страшный секрет!

>Использование d-указателей Битовые поля и зарезервированные переменные являются хорошим, но не достаточным решением. Настало время рассмотреть технику d-указателей. Термин "d-указатель" ввел Arnt Gulbrandsen ( Trolltech ) для техники, использованной при разработке библиотеки Qt, обеспечив ей одной из первых C++ GUI-библиотек бинарную совместимость на протяжении многих выпусков. Эта техника была быстро адаптирована как основной прием программирования многими разработчиками KDE-библиотек. Это замечательное решение проблемы добавления новых закрытых данных-членов в класс без потери бинарной совместимости. Примечание: Техника d-указателей неоднократно описывалась в истории информатики под различными именами, такими, как pimpl (pointer to implementation), handle/body, чеширский кот. Он-лайн версии этих документов вы можете найти с помощью Google, добавив "C++" в строку поиска.

http://qt.osdn.org.ua/binarycompat.html

zabivator
()
Ответ на: комментарий от Absurd

1. Я сильно сомневаюсь в пользе бинарной совместимости. Тем более в создании дополнительных тормозов (я подозреваю, что все там сводится к лишней индерекции) для ее осуществления.

2. Хороший язык программирования должнен иметь возможность из ОДНОГО исходника делать две версии -- исходник-совместимую и бинарно-совместимую. Все эти техники, скорее всего -- преобразование исходного кода.

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

>> Страшный секрет! Настало время рассмотреть технику d-указателей.

> Изобрели pimpl?

Придумали ему ещё одно имя :)

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

> Хороший язык программирования должнен иметь возможность из ОДНОГО исходника делать две версии-- исходник-совместимую и бинарно-совместимую.

Две версии чего? Печатать на принтере в двух вариантах, раскладывать в разные папки и ложить на полку?

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

> Две версии чего? Печатать на принтере в двух вариантах, раскладывать в разные папки и ложить на полку?

Очевидно -- две версии либы или бинарника.

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

> Очевидно -- две версии либы или бинарника.

А если компилятор языка не умеет делать либы и бинарники в привычных форматах? Что не мешает ему на ходу подключать модули и каким-то лыком понимать их интерфейсы?

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

>А если компилятор языка не умеет делать либы и бинарники в привычных форматах? Что не мешает ему на ходу подключать модули и каким-то лыком понимать их интерфейсы?

И что не мешает ему тормозить? Знаем, проходили.

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

>>А если компилятор языка не умеет делать либы и бинарники в привычных форматах? Что не мешает ему на ходу подключать модули и каким-то лыком понимать их интерфейсы?

>И что не мешает ему тормозить? Знаем, проходили.

Проблемы нишебродов шерифа не волнуют.

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

>>И что не мешает ему тормозить? Знаем, проходили.

>Проблемы нишебродов шерифа не волнуют.

Ну да, спонсируйте своей недальновидностью полупроводниковую промышленность, в итоге все вермя оставаясь на одном и том же уровне )))

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

>>>И что не мешает ему тормозить? Знаем, проходили.

>>Проблемы нишебродов шерифа не волнуют.

>Ну да, спонсируйте своей недальновидностью полупроводниковую промышленность, в итоге все вермя оставаясь на одном и том же уровне )))

DirectX в винде рассчитан на позднее связывание и ABI. Ужасных торозов вроде не замечается.

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

>DirectX в винде рассчитан на позднее связывание и ABI. Ужасных торозов вроде не замечается.

Ну ты и сравнил продукт, толкаемый одним вендором с кучкой фофанов, толком не представляющих, что бы им такого "кошерного" с их любимым поделием замутить, вместо наращивания функциональности и удобства использования.

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