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 ()
Ответ на: комментарий от anonymous

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

То есть пользователи qt3 обречены "мириться с тормозами и костылями"? :D

Bohtvaroh ★★★★
() автор топика

>Все приложения, которые собираются для ветки 2.x с макросом GSEAL() и не используют deprecated кода будут без проблем собираться для ветки 3.x.

На кой? Если приложение не использует фич 3.х, пусть в зависимостях стоит 2.х.

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

> Тулкиты на С++ отлично связываются с языками, которые поддерживают ООП минимум на том уровне, какой необходим тулкиту

D отлично поддерживает ООП на уровне, необходимом Qt. Почему нет связки?

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

>Упс?

А-а-а, ну я то ее не пользую, для общего развития поинтересовался.

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

> На кой? Если приложение не использует фич 3.х, пусть в зависимостях стоит 2.х.

Наверное, чтобы не держать две версии библиотеки в системе. Простота миграции тому способствует. :)

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

Вижу, вы так и не промыли желудочки мозга, ибо из вашего потока фантазии вытекает что все в мире костыль.

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

Когда вся эта каша заваривалась , мало какие компиляторы поддерживали шаблоны .

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

>А с Qt3.1 -> Qt3.3 слабо повторить? :-)

Я правильно понимаю, у вас проблема с нумерацией версий? То есть, если было бы ветку 3.3 назвали 4.0 и там поломали обратную совместимость, проблем бы не было?

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

> А какие фичи там ещё нужны?

В кутях почему-то нет проблем с поиском новых фич... Могу на вскидку предложить создать аналог QGraphicsView-фреймворка. Или оно не нужно?

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

Не знаю, как насчет VMWare, но зависимости acroread из
debian-multimedia выглядят так:

$ apt-cache depends acroread
acroread
Зависит: libatk1.0-0
Зависит: libc6
|Зависит: libgl1-mesa-glx
Зависит: <libgl1>
libgl1-mesa-glide3
libgl1-mesa-glx
libgl1-mesa-swx11
Зависит: libglib2.0-0
|Зависит: libglu1-mesa
Зависит: <libglu1>
libglu1-mesa
Зависит: libgtk2.0-0
Зависит: libpango1.0-0
Зависит: libx11-6
Зависит: zlib1g
|Зависит: libldap2
Зависит: <libldap-2.4-2>
Зависит: libcupsys2
Зависит: acroread-debian-files
Зависит: libxul0d
Зависит: acroread-data
Предлагает: acroread-plugins
Предлагает: mozilla-acroread
Предлагает: <acroread-l10n>
acroread-l10n-en
acroread-l10n-pt-br
Рекомендует: gconf2
Конфликтует: acroread-debian-files
Конфликтует: acroread-plugins
Заменяет: acroread-debian-files
Заменяет: acroread-plugins
Заменяет: mozilla-acroread

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

> D отлично поддерживает ООП на уровне, необходимом Qt. Почему нет связки?

Потому что её никто не написал?

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

>Вы уж определитесь, нужен ли вам язык qt, или же вам нужен стандарт с++.

Можно не напрягаясь извлекать полезное из обоих

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

кст

>Тогда зачем им было отходить от стандарта, уменьшать совместимость

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

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

>Наверное, чтобы не держать две версии библиотеки в системе. Простота миграции тому способствует. :)

Все равно старый софт будет требовать 2.х (напомните, когда умерли все программы на 1.x?)

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

>> Что люди не делают, лишь бы на с++ не переходить =)

> Как по мне, там и без плюсов неплохо.

Ты пишешь на Gtk + голый Си?

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

Ой, и тут костыль, а этого нет в стандарте си!

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

>Не знаю, как насчет VMWare, но зависимости acroread из debian-multimedia выглядят так:

Е-мое!!! А ведь раньше он был статическим.

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

> Если мне не изменяет память, то gcc поддерживает хвостовую рекурсию.

Не изменяет. :) Но только при должном уровне оптимизации и -foptimize-sibling-calls.

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

> В прошлом тысячелетии, а что?

а как же неро с xmms? вроде не так давно они умерли и уж точно не в прошлом тысячелетии

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

>gcc поддерживает хвостовую рекурсию.

Костыль на уровне компилятора?

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

> Ты пишешь на Gtk + голый Си?

Я не пишу на GTK, но когда-то интересовался. Надо будет - буду писать.

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

> Потому что её никто не написал?

Хорошо. Допустим, недостаточно большому количеству разработчиков это надо. А почему нет привязки Qt к C? Потому что недостаточно возможностей в языке? В итоге получаем, что привязки Qt нет ни к D ни к любому другому языку потому, что нет соответствующих возможностей в C. А это уже проблемы Qt, но никак не D, Python, и т.д.

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

>>напомните, когда умерли все программы на 1.x?

>В прошлом тысячелетии, а что?

http://www.xmms.org/faq.php#Compilation1

P.S. я КДЕшник, не специалист по гномовской некрофилии

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

>Вот пример: в Лиспе ООП тоже в какой-то степени костыль, ибо оно идентично набору костылей к схеме (в Common Lisp оно конечно входит в стандарт, но все равно синтаксис лиспа состоит только из скобок и указания имени ф-ии после каждой из них).

Глупости говорите про стандарт.

>Однако в Лиспе самое лучшее ООП.

И снова... Чем же оно лучшее?

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

>Ты пишешь на Gtk + голый Си?

Да. Для программок типа GUI к какой-то программке с менюшками и т.п. отлично подходит.

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

boost - это не стандарт, а то, что возможно им станет.

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

>а как же неро с xmms? вроде не так давно они умерли и уж точно не в прошлом тысячелетии

А это некрофилы ;) Не, ну в самом деле, сравнить xmms 2000 и 2008 - много ли разницы?

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

>> Ты пишешь на Gtk + голый Си?

> Я не пишу на GTK

Почему меня это не удивляет?

> Надо будет - буду писать.

Надо будет - будешь писать на ассемблере и даже без Xlib.

Интересно, сколько процентов программ используют Gtk через _нормальные_ ОО-обертки типа PyGtk, Gtk--, wxGTK...

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

>Не правда. Просто Qt слишком рьяно городит несовместимости. Слишком.

Вот я поражаюсь с гномеров. Прикручивание ООП к сям - это нормально, а сигналы для плюсов - это костыль.

Что-то гика не видно, думаю он скажет, что 3.х будет истинно православный тулкит на кошерном языке.

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

> Хорошо. Допустим, недостаточно большому количеству разработчиков это надо. А почему нет привязки Qt к C? Потому что недостаточно возможностей в языке? В итоге получаем, что привязки Qt нет ни к D ни к любому другому языку потому, что нет соответствующих возможностей в C. А это уже проблемы Qt, но никак не D, Python, и т.д.

Во-первых С - не ООП-язык, поэтому нельзя к нему сделать биндинг. Питон ООП-язык, к нему есть биндинги, причём автоматические, их никто руками не пишет, просто поправляют. То же самое с перлом, руби, паскалём и т.д. А то, что Си не поддерживает парадигму и Ди не имеет достаточно приверженцев, явно не проблема С++.

troorl ★★
()

ПРЕДЛАГАЮ ОКОНЧИТЬ ПОЛЕМИКУ О КОСТЫЛЯХ!

С ОБОИХ СТОРОН ИХ ХВАТАЕТ! И в Си, и в С++.

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

>Си не поддерживает парадигму

А где можно помолиться вашим следам?

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

>То есть пользователи qt3 обречены "мириться с тормозами и костылями"? :D

Не надо вилять, уважаемый: qt3 была лучше gtk2 для своего времени, просто появилась qt4, которая лучше qt3 потому, что разработчики не стали тянуть за собой багаж архитектурных упущений (ни что не идеально), а gtk'шники признавать своих упущений не хотят - вот и гордятся тормозными костылями в отплату за обратную совместимость со всяким старьем, - ибо больше нечем.

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

> D отлично поддерживает ООП на уровне, необходимом Qt. Почему нет связки?
Как станет более популярна вторая версия, так наверняка будет =)

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

> Почему меня это не удивляет?

И шо ви этим хотели сказать? Я же сказал, надо будет - напишу, никаких проблем с "голым Си" и гтк не испытываю. Едиственное, что напрягает, создание собственных типов в GObject (слишком много макросов и возни).

> Интересно, сколько процентов программ используют Gtk через _нормальные_ ОО-обертки типа PyGtk, Gtk--, wxGTK...

Я бы wxGTK нормальной обёрткой называть не стал.

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

>ПРЕДЛАГАЮ ОКОНЧИТЬ ПОЛЕМИКУ О КОСТЫЛЯХ!

Предлагаю тебе принять лекарство, тогда и кончим. :]

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

Это был эталон троллинга (я только хотел написать), зря ты ответил :)

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

>> Почему меня это не удивляет?

> И шо ви этим хотели сказать?

То, что фразы "как по мне, там и без плюсов неплохо" нужно произносить, только если есть значительный опыт работы на Gtk без Си++.

>> Интересно, сколько процентов программ используют Gtk через _нормальные_ ОО-обертки типа PyGtk, Gtk--, wxGTK...

> Я бы wxGTK нормальной обёрткой называть не стал.

Но по первым двум возражений нет? Ну и славно.

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