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

ИМХО накручиваются какие-то велосипеды, тот же Qt куда проще и красивее.

anonymous
()

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

Они даже кошмар миграции решили свой сделать, от уж велосипердисты.

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

> тот же Qt куда проще и красивее.

Не сказал бы. В плане сложности Qt и GTK библиотеки одного порядка. В крайнем случае те, кто не понимает, что GTK это тоже ООП-шный тулкит, могут использовать gtkmm

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

>Что только люди не делают, лишь бы не писать на C++...

это точно :)

anonymous
()

Что только не придумают люди, чтобы на C++ не переходить: Макро GSEAL(), указатели "priv", закрытые члены класса...

Пользователи GTK, скиньтесь им на книжку Страуструпа, пускай откроют для себя истоки своего велосипеда. А то ведь вам потом с этим работать.

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

> кошмар миграции

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

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

>Пользователи GTK, скиньтесь им на книжку Страуструпа, пускай откроют для себя истоки своего велосипеда.

Страуструп изобрел ООП? Мусье идиотъ?

Sidrian
()

Сокращаю сказочку: "Мы поняли, зачем С++, но не осилили, поэтому сделаем тоже на С"

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

Почти все приложения написанные для Win2000 запускаются в висте, без перекомпиляции, так что не стоит линуксоидам троллить по кошмары.

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

> А то ведь вам потом с этим работать

Работали, работаем и будем работать. Ниасилившим ООП без слова "class" в синтаксисе языка предлагается изменить направление движения к ближайшей твердой вертикальной нехрупкой поверхности.

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

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

Тоже самое можно сазать и про qt-3.X.Y

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

у них есть специальный костыль на такой случай - vala

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

> Почти все приложения написанные для Win2000 запускаются в висте, без перекомпиляции

При условии наличия нужных версий библиотек. Если что, в линуксе это так же - я спокойно запускаю бинарники ХЗ какой давности, просто подложив в систему compat-библиотеки.

<moderatorial>wfrr, не тролли</moderatorial>

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

Нет, Страуструп один из главных разработчиков языка C++ и написал одну из лучших книжек по этому языку. Не дополняйте чужие мысли своими нелепыми догадками в стиле жёлтой прессы, "мусье".

anonymous
()

Что только люди не делают, лишь бы осиливать С. Мучаются со своим С++.

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

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

Что поделаешь, приходится. Мы и не на то способны.. лишь бы на c++ не переходить!

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

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

Как по мне, там и без плюсов неплохо. Как уже говорилось выше, люди, не понимающие ООП без слов class, extends и т.п., идут туда, куда уже сказали. :)

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

Модераторы, между пунктами "GtkStyle ..." и "Избавиться от всего кода..." не зря была фраза

> Следующей стадией будет создание development ветки GTK+ 3.0.

Она логически разделяла подготовку к переходу и фактическое отделение 3-ей ветки. Верните, пожвлуйста.

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

Почти все приложения написанные для Win2000 запускаются в висте, без перекомпиляции, так что не стоит линуксоидам троллить по кошмары.

Ну так и линуксовые приложения для gtk1 тоже спокойно запускаются и теперь, в эпоху gtk2 и в будущем, при gtk3

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

>Как уже говорилось выше, люди, не понимающие ООП без слов class, extends и т.п., идут туда, куда уже сказали. :)

Речь не в необходимости опнимания ООП без отдельных слов, а в адекватном выборе инструмента для реализаци требуемого - чего за любителями проектировать многоуровневые костыли (gtk'шниками) замечено не было

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

>При условии наличия нужных версий библиотек.

Угу SH* функции неизменный со мохнатых времен? А находятся они в shell32.dll которая в каждой версии меняется, и тем не менее все пашет.

><moderatorial>

Знатный аргумент, достойный... К тому же я не троллю а итнересуюсь преимуществами костылей GObject и прочих конструкций.

wfrr ★★☆
()

Да будет флейм...

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

>google://gtkmm

Это как поставить руль от лексуса на "Запорожец" :)

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

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

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

> При наличии только gtk2? Не шутите так.

Тебя не смущает, что виндовые приложения собранные под определенные версии MFC (mfc40.dll, mfc42.dll и т.д.) запускаются только при наличии указанных dll?

Тогда почему тебя смущает, что приложения собранные с gtk-1.2.so требуют наличия таковой в системе? Одновременное наличие рантаймов двух очень различных версий GTK в системе - это вполне нормальное явление. Как и наличие рантаймов DX8/DX9 и рантаймов MFC40/MFC41/MFC42.

no-dashi ★★★★★
()

Удивляет количество шума, которое наделали красноглазые Qt-шники. Прям как Моська на слона.

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

>А находятся они в shell32.dll которая в каждой версии меняется, и тем не менее все пашет.

Конечно пашет, оно же extern "C" там все.

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

> а в адекватном выборе инструмента для реализаци требуемого

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

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

Посчитать все прогрнаммики под винду это сродни пересчету анонимусов ЛОРа, конечно сейчас вы найдете кривое поделие которое заюзало очередную технологию (а может просто "кривое"), и не работает в висте, но это ничего не значит.

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

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

>В каких местах?

В местах ООП например. (правда тут уже корректнее сказать библиотеку Си, а не сам Си, но язык - это не только синтаксис).

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

Objective-C , D? Зачем изобретать велосипед?

wfrr ★★☆
()

Это пипец. С таким рвением преодолевать трудности, которые они сами себе специально создали - в первый раз такое вижу.

Прошу заметить, о функциональности ни слова. Сплошная возня с собственными костылями.

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

> логика весьма сомнительная и мне противная.

Кому как. С точки зрения эндюзера - мне очень нравится совместимость версий GTK, поскольку в результате та же VMWare не нуждается в ежемесячном апдейте.

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

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

>Тебя не смущает, что виндовые приложения собранные под определенные версии MFC (mfc40.dll, mfc42.dll и т.д.) запускаются только при наличии указанных dll?

Это забота, по большей части, программиста, использующего конкретные функции и link'ера (можно собрать статически), и дистрибьютора этих библиотек в системе (M$)

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

> Тогда почему вас смущает наличие пары версии куте?

Потому, что я нормально отношусь к libqt-3.3.so и libqt-4.0.so в один момент времени, но не воспринимаю libqt-3.1, libqt-3.2, libqt-3.3 и libqt-4.0 одновременно.

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

>Почти все приложения написанные для Win2000 запускаются в висте, без перекомпиляции...

Первое же вспомнившееся - Agnitum Outpost Firewall первой версии, которая ныне бесплатная, так вот хотел поставить его брату на ноут со свистой, а мне говорят - "свистни в х#й"(с), парниша. Так вот к чему это я? У меня такое подозрение, что только перекомпиляцией тут дело не обошлось бы :)

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

> Это забота [...] и дистрибьютора этих библиотек

Подкладывает compat'ы в систему создатель дистрибутива...

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

> К тому же я не троллю а итнересуюсь преимуществами костылей GObject и прочих конструкций.

GObject и прочие конструкции очень легко привязываются к интерпретируемым языкам, о чем очень подробно написано на gtk.org. А еще там разъясняется зачем городить огород, то есть делать так сложно.

rymis ★★
()

гтк-шники самые дальновидные разработчики. Во-первых, ГТК это истинно открытая система. Во-вторых, они ждут Vala и потом переведут постепенно GTK на него. а плюсы это тупик.

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

QtOctave собирался с qt4.2 сейчас работает с 4.4, что не так?

>С точки зрения девеолпера совместимость тоже хороша,

С точки зрения девелопера-пользователя библиотеки, с точки зрения разработчика библиотеки это гимморой, тянущий кучу кода и тормозящий развитие.

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

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