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

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

> Это Вы нереально "отожгли", да :D Сколько надежд я когда-то вкладывал в е17.. а до сих пор нет приличных приятных глазу тем..

http://code.google.com/p/detour/

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

>О чем и речь. Использовать С с парой синтаксических плюшек.

Тонны макросов, vala, извращения с заголовками - это "пара синтаксических плюшек"? Кто-то занимается перетаскиванием из пустого в порожнее вместо того, чтобы создавать действительно удобные вещи

>Специально для Вас extended edition: "за двумя зайцами погонишься, ни одного не поймаешь".

Добавление какой-либо функциональности не делает уже существующую хуже, материальные аналогии тут неуместны

>И ООПв плюсах дурацкое

Сугубо личное

>и с голым С совместимость потеряна в мелочах, после С99

совместимость не нужна, ибо это повод для создания костылей

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

> Добавление какой-либо функциональности не делает уже существующую хуже, материальные аналогии тут неуместны

В случае плюсов это не так. Иначе почему они абсолютно не годятся для системного программирования?

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

>Сюрприз, IT-мир уже 50 лет выпускает новые версии софта.

Покажи мне кроссплатформенный тулкит, позволяющий делать рендеринг веб-страниц практически из любого виджета. Нет такого? Это не нужно? А что нужно?

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

>В случае плюсов это не так.

Ах да, вот не было бы шаблонов,исключений,rtti (по авторитетному мнению г-на Absurd'а) - был бы хороший язык, а так - говно =) Маразматичная аргументация.

>Иначе почему они абсолютно не годятся для системного программирования?

абсолютно - 4.2, для линукса - спорный вопрос, для винды - я даже сам когда-то писал portio-драйвер, главное - чтобы ABI и API (в большей мере) были стабильны - как раз то, чего конкретно в линуксе не наблюдается

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

>Иначе почему они абсолютно не годятся для системного программирования?

И вообще глупо однозначно судить о языке по его применимости для системного программирования: много ли системного можно написать на лиспе? а на php? ruby? Никакой это не аргумент, а очередное увиливание в идеологическую муть.

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

> Тонны макросов, vala, извращения с заголовками - это "пара синтаксических плюшек"?

"Тонны макросов" в gobject добавляют кучу того, что в плюсах как языке просто нет - и пришлось бы добавлять другую (ок, чуть меньшую) тонну макросов.

> Добавление какой-либо функциональности не делает уже существующую хуже, материальные аналогии тут неуместны

Это не добавление. Это поиск компромисса между двумя взаимоисключающими целями. И невозможность осмысленного компромисса на этом месте не зависит от материальности.

> Сугубо личное

Процентов на 10 (буду скромен;). Отсутствие нормальной рефлексии в плюсах (костыль RTTI в рассмотрение не берем) не зависит от моей личности - ну и другие всякие "мелочи", типа охренительной модели множественного наследования, любопытных деталей инстанциирования темплейтов и пр. и пр.

> совместимость не нужна, ибо это повод для создания костылей

Если бы сообщили эту потрясающую мысль Страуструпу в момент создания плюсов - он, возможно, создал бы что-нибудь приличное, и мы с Вами бы тут не беседовали бы.

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

>Кто-то занимается перетаскиванием из пустого в порожнее вместо того, чтобы создавать действительно удобные вещи

Хотя, впрочем, не мне решать, чем им заниматься. А так - желаю им успехов :)

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

> Покажи мне кроссплатформенный тулкит, позволяющий делать рендеринг веб-страниц практически из любого виджета.

http://developer.mozilla.org/en/docs/The_Joy_of_XUL

> Нет такого?

Есть

> Это не нужно?

Нужно. Поэтому есть. См. выше.

> А что нужно?

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

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

Анонимус какой-то необразованный попался, неинтересно спорит.

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

>XUL

это даже не смешно

>Есть

см. выше

>Нужны мультиметоды и рефлексия.

Это от Qt-то?!

>И регулярный, менее навороченный синтаксис

Да-да, видали мы ваш простой код на gtk =)

>Без плюшек типа ">>" - не понять что, бинарный сдвиг вправо или ошибка в закрытии темплейтов.

пропатчи руки, пропатчи компилятор и твои проблемы исчезнут

anonymous
()

Команда гнома решила придумать велосипед. Да если уж тут такие споры перепишите вcе под mono. Чтобы никому обидно не было.

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

>пришлось бы добавлять другую (ок, чуть меньшую) тонну макросов.

>>Спрятать все открытые поля структур с помощью макроса GSEAL().

>>Реализовать закрытые члены класса, что включает изменения в коде GType.

>>Поскольку не останется простого способа для доступа к полям класса, а использование g_object_[sg]et() утомительно, необходимо ввести новые методы доступа, вроде g_object_get_int(), *double(), *string() и т.д.

>>Удалить все поля структур из публичного API

...

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

>>XUL

>это даже не смешно

Аргументировать-то свои реплики когда начнёшь?

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

> "Тонны макросов" в gobject добавляют кучу того, что в плюсах как языке просто нет - и пришлось бы добавлять другую (ок, чуть меньшую) тонну макросов.

Сравним количество макросов в GTK и Qt. В последней не "чуть меньшая тонна", а меньше в разы.

И напоследок провокационный вопрос (чисто теоретического плана): в Object Pascal объектная модель лучше, чем в C++?

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

>Это не добавление. Это поиск компромисса между двумя взаимоисключающими целями. И невозможность осмысленного компромисса на этом месте не зависит от материальности.

Ничего не удаляется и уже существующее не становится хуже - это факт. Все остальное важно только тем, кто от этого зависит.

>Отсутствие нормальной рефлексии в плюсах

Насколько ее повсеместное применение оправдано?

>ну и другие всякие "мелочи", типа охренительной модели множественного наследования

что в ней охренительного?

>любопытных деталей инстанциирования темплейтов и пр. и пр.

что за любопытные детали?

>Если бы сообщили эту потрясающую мысль Страуструпу в момент создания плюсов - он, возможно, создал бы что-нибудь приличное, и мы с Вами бы тут не беседовали бы.

Ну да, теперь плюсы виноваты во всех бедах =)

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

Переделка этой вашей "чуть меньшей" части макросов и прочих ухищрений составляет около трети работы по подготовке к релизу gtk3 - и не принесет никаких существенных улучшений, что говорит о бесполезности этой работы

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

> Сравним количество макросов в GTK и Qt. В последней не "чуть меньшая тонна", а меньше в разы.

Это не важно. Важно то, что эти макросы в GTK являются банальным следствием полного отсутствия ОО в языке С. А в Qt они прекрасно демонстрируют тезис об убогости ОО в плюсах. Разница показательная.

> в Object Pascal объектная модель лучше, чем в C++?

Провокация не удалась. Ибо с Паскалем я имел дело последний раз лет 10-15 назад, так что совсем не копенгаген.

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

>И напоследок провокационный вопрос (чисто теоретического плана): в Object Pascal объектная модель лучше, чем в C++?

Лучше тем, что там нету перегрузок операторов, которые ИМХО великое зло.

Хуже тем, что там нету шаблонных классов. Реализации шаблонов Map, List, Set очень великолепные вещи.

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

> Ничего не удаляется и уже существующее не становится хуже - это факт.

Что значит "ничего не удаляется"? Даже в самый первый момент плюсы уже в мелочах были несовместимы с С. Например, строгость приведения типов у языков разная, плюсы строже (за ссылками - в гугл).

> Насколько ее повсеместное применение оправдано?

Аргумент в духе "мне не нужно - значит, не нужно никому". Просто отсутствие оной явно показывает, что ОО в плюсах - костыльная, ОО частично "времени компиляции", а не "времени выполнения".

> что в ней охренительного?

Вы когда-нибудь забывали сделать деструктор виртуальным? А, например, использовали виртуальное наследование вместо невиртуального - или наоборот? Такие ошибки ловить бывает увлекательно, если дерево наследования развесистое...

> что за любопытные детали?

ЕМНИП традиционный сишный линкер не очень хорошо справляется с этим плюсовыми темплейтами. Пришлось придумать разные интересные опции для компилятора.

> Ну да, теперь плюсы виноваты во всех бедах =)

Нет, не во всех. Башни-близнецы взорвали не они. Но это единственное исключение.

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

>> Ну да, теперь плюсы виноваты во всех бедах =)

> Нет, не во всех. Башни-близнецы взорвали не они.

Ха! Мне кажется, ты недооцениваечь губительности плюсов.

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

+ Хуже тем, что нету статических методов классов.

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

>Это не важно

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

>>добавлять другую (ок, чуть меньшую) тонну макросов.

>А в Qt они прекрасно демонстрируют тезис об убогости ОО в плюсах.

Макросы в С++-QT - по большей мере для удобства, а в Си-GTK - это необходимость

>Разница показательная.

Что может показывать разница неоднородных(значных) вещей?

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

> Это не важно.

Как это не важно? Получается, один макрос без параметров или 6 штук по 10 параметров в каждом - не важно? Или 6 макросов лучше, поскольку они высокой цели служат?

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

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

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

Просто меня не интересуют количественные сравнения. Меня интересуют качественные.

> Макросы в С++-QT - по большей мере для удобства,

Это "удобство" - выражение тех частей объектной модели, которых нет в плюсах. И которые не укладываются в плюсовый язык.

> Что может показывать разница неоднородных(значных) вещей?

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

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

>> Макросы в С++-QT - по большей мере для удобства,

>Это "удобство" - выражение тех частей объектной модели, которых нет в плюсах. И которые не укладываются в плюсовый язык.

Если имеются в виду слоты/сигналы, то про "не укладывается" - это неправда. Просто Qt начала разрабатываться давно, когда компиляторы Си++ не предоставляли средств для построения таких вещей.

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

> Просто меня не интересуют количественные сравнения. Меня интересуют качественные.

Ты, наверное, яму во дворе кофейной ложкой рыть будешь?

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

>Что значит "ничего не удаляется"?

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

>Даже в самый первый момент плюсы уже в мелочах были несовместимы с С.

Такая задача не ставилась

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

Это мне давно известно

>Просто отсутствие оной явно показывает, что ОО в плюсах - костыльная, ОО частично "времени компиляции", а не "времени выполнения"

runtime-ОО с куда большими возможностями (это ж runtime!), чем у плюсов есть в других языках, но С++ ОО по большей части compile-time - с этим соревноваться по производительности другие языки не могут

>Вы когда-нибудь забывали сделать деструктор виртуальным?

нет и я читаю предупреждения компилятора

>А, например, использовали виртуальное наследование вместо невиртуального - или наоборот?

да

>Такие ошибки ловить бывает увлекательно, если дерево наследования развесистое...

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

>ЕМНИП традиционный сишный линкер не очень хорошо справляется с этим плюсовыми темплейтами. Пришлось придумать разные интересные опции для компилятора.

ЕМНИП, юзайте ICC

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

> Qt начала разрабатываться давно, когда компиляторы Си++ не предоставляли средств для построения таких вещей.

Шаблончеги =)

Временами мне начинает казаться, что лучше б их не было...

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

> И вообще глупо однозначно судить о языке по его применимости для системного программирования: много ли системного можно написать на лиспе? а на php? ruby? Никакой это не аргумент, а очередное увиливание в идеологическую муть.

"Добавление какой-либо функциональности не делает уже существующую хуже"

А я говорю - делает. В случае плюсов. Сам дальше разжуёшь?

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

Да, в первую очередь это именно про слоты-сигналы. "Когда компиляторы не предоставляли" - в это я готов поверить. Но, отвлекаясь от конкретных компиляторов, это уже в стандарте языка зафиксировано?

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

>Просто меня не интересуют количественные сравнения. Меня интересуют качественные.

"Code Less. Create More. " - отсюда и функциональность, и качество конечных приложений. Что за "качество" у Gtk?

>Это "удобство" - выражение тех частей объектной модели, которых нет в плюсах. И которые не укладываются в плюсовый язык.

Это прям-таки аномально и поэтому стоит изобрести новый язык?

>Если С++ заявляет себя ОО на уровне языка - он должен предоставлять достаточный набор фич ОО безо всяких макросов.

Наследование, инкапсуляция, полиморфизм - что из перечисленного реализуется макросами?

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

>Просто Qt начала разрабатываться давно, когда компиляторы Си++ не предоставляли средств для построения таких вещей.

Молодец, напиши шаблон для реализации паттерна Сигнал-Слот, чтобы с ABI все было в порядке и чтобы раздельная компиляция работала нормально.

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

> Насколько ее повсеместное применение оправдано?

Ну вот RTTI же оправдан? А это частный, мелкий случай рефлексии. Представь, какие возможности открываются, когда можно в живой программе перебрать методы и атрибуты объекта класса. Если фантазии не хватает, то подсказываю: можно не только сериализацию объекта любого класса на раз-два делать без костылей вида DECLARE_ATTRIBUTE() или френдовских serialize(), уникальних в каждом классе, а даже само определение класса разобрать и собрать заново.

> что в ней охренительного?

Scott Mayers, Effective C++, Item 43. Вообще, Effective C++ и More Effective C++ нужно читать ещё до того, как первую программу на плюсах сядешь писать. Известный граблепроходец подробно и занимательно описывает, почему половину C++ использовать вредно.

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

>>"Добавление какой-либо функциональности не делает уже существующую хуже"

>А я говорю - делает. В случае плюсов.

Конкретный пример с исходником в студию

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

>Наследование, инкапсуляция, полиморфизм - что из перечисленного реализуется макросами?

В С++ нет ни первого ни второго ни третьего. Могу расписать. Но лучше бы ты просто исчез и не утруждал меня.

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

>> Просто Qt начала разрабатываться давно, когда компиляторы Си++ не предоставляли средств для построения таких вещей.

> Молодец, напиши шаблон для реализации паттерна Сигнал-Слот

Щасс, шнурки вот поглажу, и сразу начну.

> чтобы с ABI все было в порядке и чтобы раздельная компиляция работала нормально.

Мне вполне достаточно того, что тролльтехи сказали сами.

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

> Это значит, что плюсовый код не использующий шаблоны будет компилироваться компилятором, который их поддерживает, и будет работать

Ну давайте еще хвалить деревья за то, что они зеленые и растут. Это очевидные вещи.

> Такая задача не ставилась

Ставилась! И если б не ставилась - это был бы совсем другой язык. Вроде, Objective C как раз делался таким образом - и есть ощущения, что там кривизны меньше.

> но С++ ОО по большей части compile-time - с этим соревноваться по производительности другие языки не могут

Именно поэтому это "недоОО". Нельзя сделать нормальный ОО компайл-тайм. Потому что в рантайме оно связывает руки. Я понимаю, что плюсам хочется скорости - но это тот случай, когда надо либо трусы одеть, либо крестик снять. Не надо соединять несоединимое - получаются плюсы.

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

Язык, провоцирующий ошибки - не пригоден таким же образом.

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

>>Наследование, инкапсуляция, полиморфизм - что из перечисленного реализуется макросами?

> В С++ нет ни первого ни второго ни третьего. Могу расписать. Но лучше бы ты просто исчез и не утруждал меня.

o_O Распиши мне, пожалуйста

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

>чтобы с ABI все было в порядке

есть исходники, ABI нужен только проприетарщикам - вот пусть они об этом и думают

>и чтобы раздельная компиляция работала нормально

культ разработчика? пройдет со временем.

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

>> Наследование, инкапсуляция, полиморфизм - что из перечисленного реализуется макросами?

> В С++ нет ни первого ни второго ни третьего. Могу расписать.

Да, пожалуйста. И дай используемые тобой определения наследования, инкапсуляции и полиморфизма.

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

>>>Наследование, инкапсуляция, полиморфизм - что из перечисленного реализуется макросами?

>> В С++ нет ни первого ни второго ни третьего. Могу расписать. Но лучше бы ты просто исчез и не утруждал меня.

>o_O Распиши мне, пожалуйста

Я пока за тредом понаблюдаю.

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

>В С++ нет ни первого ни второго ни третьего

Керниган, перелогиньтесь! ROFL =D

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

Не, вру, про Objective C - это сгоряча. Он как раз совместим С, но гораздо тоньше плюсов.

/me посыпает голову пеплом антисклерозина.

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

>> чтобы с ABI все было в порядке и чтобы раздельная компиляция работала нормально.

>Мне вполне достаточно того, что тролльтехи сказали сами.

Это отмазка.

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

> Если имеются в виду слоты/сигналы, то про "не укладывается" - это неправда. Просто Qt начала разрабатываться давно, когда компиляторы Си++ не предоставляли средств для построения таких вещей.

Дело даже не в этом. Например в qt4 сделали их многопоточными. Непонятно, как они этого добились, если бы это было прибито к языку. Да и стоит таки заглянуть в файлы *.moc: ничего там страшного нет

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

> культ разработчика? пройдет со временем.

Убойный аргумент в споре о языках программирования. Наповал, вдребезги, навылет. "Хрусть - и пополам".

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