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

Они положили начало гномокапцу

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

да вы все кто такие вообще?

В лагере QT есть отличный софт, но он частенько сильно завязан на kde: KPDF тот же самый в котором есть нормальная копипаста, konsole, k3b. В лагере GTK есть отличный софт, который к счастью, реже завязан на gnomoубожество. Потому прежде чем флудить стоит хотя бы указать с чем вы конкретно не согласны и в чем предмет спора: если ДЕ, то KDE vs Gnome, если GUI то QT vs GTK, если ООП то QT vs GLib.

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

>А вот я не вижу противоречия. Хотя для мертворожённого слишком хорошо шевелится

KDE4 сначала стабилизируйте.

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

я про того ананимуса, на чей пост ты отвечал)))

но рефлексы на уровне, молоток!

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

> Согласен. gtk правильнее было бы сравнивать с kdelibs а не с qt

а qt c glib+gdk+gtk? Я всегда предполагал в qt раздутого монстра...

anonymous
()

Да, не перевелись еще тролли на земле русской...

Это ж текст о том, КАК переходить на гтк 3. А не о том, что нового в нем будет. Так почему кдешники со свойственной им прозорливостью увидели, что из этого текста следует, что ничего нового не будет?

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

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

> Согласен. gtk правильнее было бы сравнивать с kdelibs а не с qt

приехали...

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

> Согласен. gtk правильнее было бы сравнивать с kdelibs а не с qt

Совсем что-ли?

s/kdelibs/qt-gui

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

Да я, знаете, сегодня как-то не в голосе;)

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

> Так почему кдешники увидели, что из этого текста следует, что ничего нового не будет?

А чего будет?

anonymous
()

А где gaa с его tkLOR?..

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

А об этом на ЛОРе уже были новости. И, уверен, еще будут ;)

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

>Мейерса, Саттера и Александреску хотябы можно почитать. Опус Страуструпа полезен только с медицинской точки зрения.

ля. У кого из первых троих есть _полное_ руководство по языку? Вы может новичкам "Современное проектирование..." рекомендуете? О_о

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

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

>> Мейерса, Саттера и Александреску хотябы можно почитать. Опус Страуструпа полезен только с медицинской точки зрения.

> ля. У кого из первых троих есть _полное_ руководство по языку? Вы может новичкам "Современное проектирование..." рекомендуете? О_о

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

Что только не придумают, чтобы не читать K&R (

anonymous
()
Ответ на: да вы все кто такие вообще? от anonymous

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

welcome to lOR, Neo

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

>кдешнегов

И это самый культурный из модераторов! ЛОРокапец!

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

>а вот и сву подтянулся, ждём гарика

Ждем гика.

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

Re^2: Планы по выпуску GTK+ версии 3.

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

Он ЕГЭ сдаёт, ему не до троллинга.

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

>>Что только не придумают, чтобы не читать K&R (

>казалось бы, причем K&R к плюсам?

плюсы кагбэ ненужны

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

>У кого из первых троих есть _полное_ руководство по языку?

Языка в С++ нет. Есть косяки. Следовательно надо начинать с того чтобы бороться с косяками. Мейерс учит обходить маленькие косяки, Саттер - средние, Александреску - фундаментальные.

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

> /me ушёл править Википедию

s/Википедию/Википедией

так солиднее ;)

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

>Ты что-то упустил. Мигель - это тот хмырь, что основал гном. Ты хочешь сказать, что гномокопец наступает с создания гнома?

Он хочет сказать, что Гном был хорош до тех пор, пока его не начали писать :)

MYMUR ★★★★
()

Опять сплошные "спецы" в любых мыслимых и немыслимых языках, ООП, рекурсиям, замыканиям, сигналам, слотам и прочей галиматье 8) А где результат-то ?.. Судя по количеству визгов только этом треде: QT и GTK, а заодно и весь сопутствующий продукт уже дано должен быть переписан ЛОР-визгунами... Но что-то подсказывает мне - никогда они этого не сделают 8). Может хватит анонировать над вещами, в коих 95% постеров - как свиньи в апельсинах ? Заняться непосредственно чем-нить полезным... Только ради всего святого - не умножайте хаоса во вселенной: не пишите ... 8)

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

>gtk правильнее было бы сравнивать с kdelibs а не с qt

Он с Qt-то по большому счёту в разных весовых категориях находится, т.к. один из них --- гуй-либа, а другой --- целый фреймворк, а ты его ДЕ-либой предлагаешь сравнивать.... о_О

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

>а вот и сву подтянулся, ждём гарика

Ну и сами-знаете-кого. В двух экземплярах %)

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

> почему кдешники со свойственной им прозорливостью увидели, что из этого текста следует, что ничего нового не будет?

Контуженые увидели "> кошмара миграции, который можно видеть на примере библиотеки Qt." и это сработало в качестве ментального слабительного. Других мотиваций даже не ищи.

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

Да, провокация оказалось результативной. :)

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

Раз уж анонимусы просят, то выскажу своё фи: Мыши плакали и кололись но продолжали писать ООП на C.

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

> Настоящий ООП без костылей невозможно реализовать ввиде библиотеки,

CLOS реализован в виде библиотеки. Если кто-то из поклонников творчества Страуструпа с этим не согласен, то направление на стену уже указали.

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

>Раз уж анонимусы просят, то выскажу своё фи: Мыши плакали и кололись но продолжали писать ООП на C.

ваше фи никому не интересно. ООП на Си гораздо гибче плюсового кстати

anonymous
()

Тем, кто спрашивает, почему тяжело делать байндинги к Qt: дело в том, что к классам С++ почти нереально подобраться из других языков. Си ф-ии можно вызывать непосредственно, поэтому доступ к Gtk из (в том числе) скриптовых языком можно осуществить почти непосредственно, не напрягаясь и не теряя производительность. Для С++ прийдется писать/юзать вропперы. Это сложно, тормознуто, и к тому же приводит по сути к корявому разбиению цпп классов на процедуры (что не надежно и запутанно). Добавьте сюда еще препроцессор moc от Trolltech, который в виде дополнительной надстройки к С++ еще больше все усложнит.

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

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

Если лично вас не научили работать с динамической памятью, то это ещё не значит что больше никто не умеет. К сожалению, уже целое поколение выросло, которое считает, что malloc/free -- чёрная магия, а mmap -- нечто вообще непостижимое.

pppp

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

Видать, колючий кактус ООП на си все-таки не так наводит панику на мышей, как тортик с битым стеклом ООП на плюсах.

ЗЫ Когда в плюсах можно будет менять объектную модель, не сваливаясь в обычный "С с парочкой синтаксических сахаринок" - тогда поговорим.

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

> К сожалению, уже целое поколение выросло, которое считает, что malloc/free -- чёрная магия, а mmap -- нечто вообще непостижимое.

Это не поколение, это мутация.

anonymous
()

>Спрятать все открытые поля структур с помощью макроса GSEAL(). В случае необходимости предоставить новые методы доступа к этим полям. Также должны быть скрыты поля-указатели "priv" на структуры, содержащие закрытые данные.

http://en.wikipedia.org/wiki/C%2B%2B

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

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

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

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

Осиль наконец SWIG.

> Добавьте сюда еще препроцессор moc от Trolltech, который в виде дополнительной надстройки к С++ еще больше все усложнит.

Тем не менее PyQt вполне существует.

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

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

Библиотечный интерфейс в юниксе для C++ плохо подходит, поэтому есть такой костыль, как name mangling. Именно он заставляет трахаться с дополнительными прослойками между плюсатой библиотекой и программой на другом языке.

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

>как тортик с битым стеклом ООП на плюсах.

"Тортик с битым стеклом" - это в точку. Блестяще!

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

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

Тем, что комитетом OMG признан единственным языком, удовлетворяющим спецификациям ООП.

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

>>gtk правильнее было бы сравнивать с kdelibs а не с qt

>Он с Qt-то по большому счёту в разных весовых категориях находится, т.к. один из них --- гуй-либа, а другой --- целый фреймворк, а ты его ДЕ-либой предлагаешь сравнивать.... о_О

В какой-то степени это приемущество Gtk. Он делает то, что должен, и не больше. Нужны БД и прочее - обратитесь к соответствующим либам.

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

>Си ф-ии можно вызывать непосредственно, поэтому доступ к Gtk из (в том числе) скриптовых языком можно осуществить почти непосредственно, не напрягаясь и не теряя производительность.

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

>Для С++ прийдется писать/юзать вропперы.

Юзай, уже все написано

>Это сложно

сугубо индивидуально

>тормознуто

тормознее скриптованого gtk уже ничего не придумаешь

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

это уже твоя криворукость

>Добавьте сюда еще препроцессор moc от Trolltech, который в виде дополнительной надстройки к С++ еще больше все усложнит.

ага, все тебе чьи-то яйца жмут

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