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

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

>>Столлман его как раз не продавал :)

>Не скажу за дистрибутивы, но фсф гнутый софт продавала.

Это да, но я никогда не слышал о продаже именно Линукса.

> Т.е никто на него серьезно не ставил, ЧИТД.

Серьезных денег не ставили, да. Но люди ставили на него свою работу - ИМХО, это вполне серьезная ставка :)

>>BSD - подходила гораздо меньше

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

Вообще-то в "подходящесть" входит и правильная лицензия :) SMP в Линуксе началось в 1995 (?) c машины, которую выделила Caldera.

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

> SMP в Линуксе началось в 1995 (?) c машины, которую выделила Caldera.

Так вот, кто виновнат в появлении BKL...

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

>> SMP в Линуксе началось в 1995 (?) c машины, которую выделила Caldera.

> Так вот, кто виновнат в появлении BKL...

Не, в BKL виноват лично Алан Кокс.

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

Кокс также виноват в половине важных подсистем ядра, наверное ;)

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

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

А что, кто-то умудрялся "случайно" перегрузить оператор в плюсах? ;)

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

>Кто тот дефайн определил? Не сам программист?

Ну во-первых может и не сам. Заковыристый дефайн может быть запрятан в глубине хедеров используемой библиотеки.

Во-вторых попробуйте читать не просто отдельное сообщение, а хоть немного брать в расчёт контекст.

В-третьих "а кто оператор присваивания перегрузил? Не сам программист?"

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

> А что, кто-то умудрялся "случайно" перегрузить оператор в плюсах? ;)

Неправильно - сколько угодно.

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

>Гном использует кучу сторонних либ (в том числе с fd.o). КДЕ всеми силами старается этого не делать.

Это просто офигенно подходит под:

"А теперь представь себе код который вынужден тянуть за собой и <something>-барахло из одного модуля и <something2>-барахло из другого модуля и какие-то велосипелы из третьего модуля." © Absurd

Или у плюсо-ненавистников такие заявления подходят только для плюсовых проектов, а к чисто сишным они (по непонятным мне причинам) не применимы?

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

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

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

>Неправильно - сколько угодно.

А Вы не подменяйте понятия. Мы не про "неправильно", мы про "случайно" ;)

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

Замените "замещение стандартных функций" на "перегрузку операторов" и получите то, о чём я Вам говорю :)

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

>А где моя подпись под заявлением Absurd-a? Вы еще начните у меня требовать ответа за слова гика - на том основании, что мы оба гном защищаем.

Каюсь, двусмысленно получилось. Контрпример (из Ваших уст) был предназначен как раз Абсурду.

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

>On the second thought. Да, сишный чужой код использовать безопаснее, чем плюсовый. Он предсказуемей

Только если разобрать его весь, до последнего дефайна. Иначе предсказуемость может моментально испариться (пример выше).

Предсказуемость кода от языка зависит, в меньшей мере. А в большей --- от программиста. Можно на С наколбасить непредсказуемое и нечитаемое го*но, можно на С++ написать совершенно противоположную вещь.

Только не надо говорить, что С++ мол располагает к написанию непредсказуемого го*на и побуждает его писать. Лично я ту же пресловутую перегрузку писал от силы раза 3, и то когда это было _действительно_необходимо_ и без перегрузки того же оператора присваивания нарушалась функциональность программы. В С тоже сплошь и рядов встречаются ситуации, когда _необходимо_ писать копирующую функцию для структуры, потому что использование обычного присваивания ведёт к ошибке.

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

> Замените "замещение стандартных функций" на "перегрузку операторов" и получите то, о чём я Вам говорю :)

Протестую, Ваша Честь. Замещение стандартных функций - это экзотика и очень специальный случай. Перегрузка операторов (корректная и некорректная) - это норма жизни в плюсах.

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

"А теперь представь себе код который вынужден тянуть за собой и <something>-барахло из одного модуля и <something2>-барахло из другого модуля и какие-то велосипелы из третьего модуля." © Absurd

Не вижу проблем чтобы использовать Си библиотеку из Си. Однако на плюсах характерно желание написать Ъ-операционную среду и не пущать в нее никого чтобы все развалилось нафиг (представьте себе микс из wx, Qt, std:: и boost::, бгг), при этом обвязывая Си примитивы врапперами в Ъ-стиле. Однако для пропиеритарных вещей в себе это возможно не проблема.

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

> Только не надо говорить, что С++ мол располагает к написанию непредсказуемого го*на и побуждает его писать.

А что делать, если это так? В этом суть моих претензий к нему.

> В С тоже сплошь и рядов встречаются ситуации, когда _необходимо_ писать копирующую функцию для структуры, потому что использование обычного присваивания ведёт к ошибке.

Верю. Но в С это явная функция. И каждый, кто ее вызывает - видит, что в этом месте есть вызов функции. Тогда как в плюсах - никто ни в чем не уверен. Ибо оператор перегружен. А еще может быть перегружен хитро - с использованием неявного приведения типов. И т.д. и т.п. Ужос, летящий на крыльях ночи.

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

> представьте себе микс из wx, Qt, std:: и boost::, бгг

Представь себе микс из COM, DirectX, OpenGL и Gtk, бгг.

> обвязывая Си примитивы врапперами в Ъ-стиле

Блин, даже не знаю, что сказать.

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

>> представьте себе микс из wx, Qt, std:: и boost::, бгг

>Представь себе микс из COM, DirectX, OpenGL и Gtk, бгг.

Ты нервничаешь. Ну ладно, давай по пунктам.

COM и DirectX подвержены типичному плюсовому NIH-синдрому, так как они написаны на плюсах. В них все свое.

А вот OpenGL и Gtk - нет, так как они написаны не на плюсах.

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

>> обвязывая Си примитивы врапперами в Ъ-стиле

>Блин, даже не знаю, что сказать.

Ну нужно же деструктор приделать чтобы ресурс не утекал.

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

>>> представьте себе микс из wx, Qt, std:: и boost::, бгг

>> Представь себе микс из COM, DirectX, OpenGL и Gtk, бгг.

> Ты нервничаешь.

Йа? o_O Тебе показалось.

> COM и DirectX подвержены типичному плюсовому NIH-синдрому, так как они написаны на плюсах

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

>>> обвязывая Си примитивы врапперами в Ъ-стиле

>>Блин, даже не знаю, что сказать.

>Ну нужно же деструктор приделать чтобы ресурс не утекал.

Ну если resource guard называть wrapper, тогда ой.

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

>Не уверен, что COM написан на Си++ (голый Си, но спорить не стану), однако наружу из него торчит голый Си, то же и о DirectX

Оно by design соответствует массивам виртуальных функций в формате Visual С++. Хотя COM-код соответствует минималистичному С++, согласен. Скорее всего иначе оно бы не работало.

>И гипотетическая программа, которая всё это смешивает - тоже на голом Си. И она будет бгг, хотя в ней, программе, никакого Си++.

Если пользоваться только COM-сервисами в стиле NIH, то получится надежный и быстрый компонент оффтопика. Бгг оно будет если туда stlport'а и буста напихать.

>>Ну нужно же деструктор приделать чтобы ресурс не утекал.

>Ну если resource guard называть wrapper, тогда ой.

Ой, это действительно ужасно. Враппер в плюсовую модель экзепшенов - так сойдет?

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

>> И гипотетическая программа, которая всё это смешивает - тоже на голом Си. И она будет бгг, хотя в ней, программе, никакого Си++.

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

Т.е. смешать в одной проге DirectX, OpenGL и Gtk под капотом COM - это нормально и никаких сложностей не вызовет, если не пользоваться "NIH-сервисами COM", да?

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

>Однако на плюсах характерно желание написать Ъ-операционную среду и не пущать в нее никого чтобы все развалилось нафиг (представьте себе микс из wx, Qt, std:: и boost::, бгг), при этом обвязывая Си примитивы врапперами в Ъ-стиле.

Полный сиплюсплюс головного мозга.... =\

Почему у меня не возникает никакого подобного желания? Почему я ни разу не тащил одновременно wx и Qt, а boost:: так вообще использую "только по праздникам"? Может быть, потому, что _необходимость_ всего тобой перечисленного в одном проекте перерастает из теоретической (с вероятностью 0.01%) в обязательную исключительно в твоём воспалённом сиплюсплюсом мозгу?

Ты давай, не стесняйся, поделись с нами, какие ещё "характерные желания" тебя гложут помимо wx+Qt+std+boost, а мы, глядишь, подскажем чего....

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

> Полный сиплюсплюс головного мозга.... =\

Это лучше, чем Михаил ГМ? Или хуже?

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

>смешать в одной проге DirectX, OpenGL и Gtk под капотом COM

Я где-то писал что я их смешиваю как-то? Или ты что-то курил?

>если не пользоваться "NIH-сервисами COM", да?

Не понял.

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

> Я где-то писал что я их смешиваю как-то? Или ты что-то курил?
LOL, тебе повторили твою же фразу

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

>Почему я ни разу не тащил одновременно wx и Qt, а boost:: так вообще использую "только по праздникам"?

А если кому-то понадобился одновременно wx-код lester'a и твой допустим Qt код?

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

>> смешать в одной проге DirectX, OpenGL и Gtk под капотом COM

> Я где-то писал что я их смешиваю как-то?

Нет. Но ты зачем-то предложил смешать в одной программе wx, Qt, stl и boost. Вот я в качестве ответной любезности предложил тебе вышеприведенную Ъ-Си смесь.

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

а если кому-то понадобится одновременно код на с++ и код на Java? и это еще не самый худший вариант ;)

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

>Нет. Но ты зачем-то предложил смешать в одной программе wx, Qt, stl и boost. Вот я в качестве ответной любезности предложил тебе вышеприведенную Ъ-Си смесь.

Дело в том что инфраструктура у всех С++ - фреймворков дублирует друг друга.

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

>Верю. Но в С это явная функция. И каждый, кто ее вызывает - видит, что в этом месте есть вызов функции. Тогда как в плюсах - никто ни в чем не уверен. Ибо оператор перегружен. А еще может быть перегружен хитро - с использованием неявного приведения типов. И т.д. и т.п. Ужос, летящий на крыльях ночи.

Если это реализовано _правильно_, то "каждому, кто это вызывает" может быть вообще по барабану, как оно реализовано. Инициализируем объект класса "Полином" целым числом, умножаем его на другой полином и прибавляем вещественное число --- в результате получаем соотвествующий полином, который, собственно говоря, и должен получиться.

Можно, конечно, и так: "вызываем функцию инициализации полинома целым числом", "вызываем функцию умножения на полином", "вызываем функцию прибавления вещественного числа"....

А если реализовано неправильно --- то мы уже об этом говорили :) Проблема кривых рук программиста --- не проблема языка. Не умеешь --- не берись. И это применимо к _любому_ языку.

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

>А если кому-то понадобился одновременно wx-код lester'a и твой допустим Qt код?

А если ещё вдобавок твой COM-код и Gtk-код svu? Ой, давай лучше сразу пойдём повесимся? А то ведь ещё вдруг понадобится std::-код расстрелянного gaa и CL-код mv....

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

с каких пор возможность выбора это плохо? о_О насчет смешивания кода разных фреймворков - это фантастика (с) вменяемый код пишут вменяемые люди, которые сядут перед тем как что-либо писать и один раз выберут на чем и с помощью чего они будут писать, если человек не в состоянии определится даже с этим - то его код будет в конце концов похож на свалку, и дело тут совсем не в qt, boost и т.п.

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

>А если ещё вдобавок твой COM-код

Уже не пишу COM-код года два. И под Линукс он не пошел бы.

>Gtk-код svu

Си-код можно при желании интегрировать куда угодно.

>А то ведь ещё вдруг понадобится std::-код расстрелянного gaa

Остала понесло...

>CL-код mv....

Это другая весовая категория.

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

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

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

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

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

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

Я действительно не помню проблем с интегрированием Сишных фреймворков. С плюсовыми - были. Большие.

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

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

Так что там с макросом MAX? Он удобочитаем?

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

> А если ещё вдобавок твой COM-код и Gtk-код svu? Ой, давай лучше сразу пойдём повесимся? А то ведь ещё вдруг понадобится std::-код расстрелянного gaa и CL-код mv....

Будем использовать CORBA, в чём проблемы? :)

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

>> Так что там с макросом MAX? Он удобочитаем?

> а почему std::max() не работает если сравнивается int и short?

Ви таки почему вопросом на вопрос отвечаете?

Это следует воспринимать как констатацию отсутствия внятного ответа на вопрос?

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

> дело тут совсем не в qt, boost и т.п.

Моё мнение, что без stl, boost и других библиотек, предоставляющих высокоуровневые абстракции, C++ сейчас ну совсем нафиг не нужен.

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

> Проблема кривых рук программиста --- не проблема языка.

Проблема языка - "замыливание" взгляда программиста. Отвлечение его внимания от существенных деталей. Одно дело, когда это делает сам программист, вредными макросами (заменяя стандартные функции своими). Другое дело, когда это делает язык.

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

не стоит вырывать слова из контекста :) насчет нужен/не нужен - любой "голый" язык общего назначения без библиотек никому не нужен, будь то ява, с, с++, python, pascal и т.п.

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

> Моё мнение, что без stl, boost и других библиотек, предоставляющих высокоуровневые абстракции, C++ сейчас ну совсем нафиг не нужен.

Мне, мне нужен :)

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

вам не кажется, что это всего лишь ваше субьективное мнение? для меня к примеру грамотный код на с++ верх читабельности и понятности

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

Перегрузка операторов и неявные приведения типов, неявные вызовы конструктора копирования - это объективная реальность.

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

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

>Проблема языка - "замыливание" взгляда программиста. Отвлечение его внимания от существенных деталей. Одно дело, когда это делает сам программист, вредными макросами (заменяя стандартные функции своими). Другое дело, когда это делает язык.

Интересно, однако получается: в одном случае использование каких-то возможностей языка --- это у нас "делает сам программист", а в другом случае вдруг оказывается "это делает язык" ;)

Почему так? Потому что один язык --- это любимый С и ему мы всё простим, а все его недостатки --- это наше собственные кривые руки, а другой язык --- это гадкий С++, и всё наше неумение и непонимание --- это всё его вина, он "замыливает" и "отвлекает"? %)

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

"Сам программист" расставляет подводные камни в С редко, я уже об этом сказал. А в плюсах - легко и приятно, гордясь своим владением мощью этого языка. Начинающий программист - это всегда обезъяна с гранатой, но в плюсах эта граната противотанковая.

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

> Начинающий программист - это всегда обезъяна с гранатой, но в плюсах эта граната противотанковая.

Так мы рассматриваем языки для всех или только для начинающих?

P.S. Считается, что языки для начинающих -- это Basic, Pascal, Python, но никак не C или C++.

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

> неявные приведения типов, неявные вызовы конструктора копирования - это объективная реальность.

Почему неявные? Места и случаи, когда они вызываются описаны явно. А то, что жители Нью Дели об этом не помнят -- не проблема языка.

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