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

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

>Как минимум: в настоящем ООП языке объектом является ВСЕ. Включая функции и классы.

Почему?

>Еще - в настоящем ООП язык должен быть способ узнать у объекта все его свойства-методы-...

RTTI?

>> Почему не использовать язык, где уже она есть?

>Можно. Но только если он не крив как плюсы. Я люблю ООП, на уровне языка. Но к плюсам это не относится.

Ну пишите Гном на питоне например =) Топик-то о мышах.

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

>Нет я помню, что на ЛОРе, но мы кажется обсуждали прикручивание _тех_же_плюсовых_костылей_(с)svu к C? А не ущербность(с)svu плюсового ООП.

ООП не ущербно, в отличие от его реализации в плюсах.

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

>>IIRC, самая первая реализация Модулы3

>Брррр... А где оно живёт ?

ХЗ

> И живёт ли вообще ?

Помилуй бог, конечно нет. Это 1988 год или около того, столько не живут %)

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

> Это 1988 год или около того, столько не живут %)

То есть все, кто старше 20 лет, мертвы? Жуть берёт от того, сколько в этом топике зомбей

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

>> Это 1988 год или около того, столько не живут %)

>То есть все, кто старше 20 лет, мертвы? Жуть берёт от того, сколько в этом топике зомбей

от силы десяток на весь ЛОР

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

>> Это 1988 год или около того, столько не живут %)

> То есть все, кто старше 20 лет, мертвы?

Ога

> Жуть берёт от того, сколько в этом топике зомбей

АААА!!!!111 Говорящие компиляторы!!!!!!!11111адынадын

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

> RTTI?

Я видел ее в работе. Извините, но даже по сравнению с жабской рефлексией (при том что жабка тоже не тру ОО) - это убожище.

> Ну пишите Гном на питоне например

Платформообращующие библиотеки в юниксе должны быть на С. Так было всегда, так есть и так будет, пока есть юникс. Если тянет на плюсы - проследуйте на ближайшее кладбище, там БЕОС хоронят.

svu ★★★★★
()

Будь проклят тот день, когда тырнет "пришел в массы". Куда не плюнь - кругом феерия безграмотности. :Е

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

> Платформообращующие библиотеки в юниксе должны быть на С.

Ну так Xlib и есть на C. А уж эти ваши gtk -- это обёртка к платформенной библиотеке. А на эту обёртку ещё добавляют биндинги к питону :)

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

> std::auto_ptr условно полезен но лучше бы refcounter был на уровне языка и доступен через vTable

std::auto_ptr не подсчитывает ссылки, читайте документацию по STL

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

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

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

обёртка - это gdk. А gtk - сама по себе библиотека, и биндинги к ней - меньшее зло, чем, биндинги к C++.

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

> gtk и gnome - это тоже платформа.

Поклонники этой платформы погут проёти на другое кладбище, на котором возлагаются венки на могилу платформы MFC.

> Можно их использовать и вообще не знать про какой-то там xlib (тем более что его выкидывать хотят). А вообще gtk как бы платформонезависим - формально, прикладухи и под каким-нибудь макосом должны собираться...

Вот пишут люди на qt или tk и тоже не знают ни про какой Xlib, и работает тоже всё под теми же макосями. Где тут произошла бифуркация?

gaa ★★
()

Кстати, а почему PyGTK такой "непитоновский"? Зачем было тащить в питон эти сишные слоты? Для облегчения портирования с/на С?

PS PyQt мне еще меньше нравится, хотя сам я KDE использую.

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

>Вот пишут люди на qt или tk и тоже не знают ни про какой Xlib

или gtk

anonymous
()

Чё вы тут паритесь все и так ясно. В qt4 сломали все, вот и приходится писать под него софт, а если сломать gtk3 то нах никому ненужно переписывать под него, просто напишут на qt, вот они костыли и переносят с версии на версию добавляя еще костылей для пушёй совместимости, вот и некогда думать о функционале.

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

> на котором возлагаются венки на могилу платформы MFC.

Какое отношение MFС имеет к гтк??

> Где тут произошла бифуркация?

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

Ни кутя, ни тк не соблюдают условие "платформообращующая либа на С" - поэтому идут лесом. Ок, тк пусть останется - там интерфейс через скрипт ЕМНИП, это тру.

svu ★★★★★
()

Дааа, тема gtk волнует умы и сердца

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

Просто сходите на сайт xcb. Его типа специально сделали те, кто скорбит о несовершенстве xlib - и хотят его задепрекейтить. И постепенно двигаются в этом направлении...

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

> Поклонники этой платформы погут проёти на другое кладбище, на котором возлагаются венки на могилу платформы MFC.

Это с какого перепугу MFC внезапно стала C-библиотекой? Она всю жизнь была C++...

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

> Ни кутя, ни тк не соблюдают условие "платформообращующая либа на С" - поэтому идут лесом.

Я согласен со всем этим, но что делать людям, если ь удобны Kile, Konqueror (со всеми kparts), KDevelop и т.д.? Перейти на FF, GEdit и Tex plugin и прочее из Гнома/gtk - не удобно (scite вот правда люблю), несмотря на все мое отвращение к С++.

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

>> на котором возлагаются венки на могилу платформы MFC.

> Какое отношение MFС имеет к гтк??

Ну тоже типа платформа. Только вот мёртвая, ибо представляла собой обёртку для другой платформы(win32).

>> Где тут произошла бифуркация?

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

Это платформа над платформой, читай обёртка над платформой. И от того, написана она на C или нет(вот тут как раз всплывают tk и qt), никак не меняется сам UNIX с требованием C-шности платформенных библиотек.

> Ни кутя, ни тк не соблюдают условие "платформообращующая либа на С" - поэтому идут лесом.

Обёрткообразующая либа. Платформа -- это X11.

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

Ещё есть ETK - API весьма похож на GTK+, вместо glib - ecore, присутствует продвинутый канвас evas, офигенная библиотека для описания интерфейсов edje (включая анимацию), нормальная поддержка тем, а не той безвкусицы, что есть в GTK+, типа clearlooks, murrine, etc, быстрая и качественная обработка растровой графики imlib2, возомжность рисовать через cairo. Написана на Си. Один недостаток - в разработке, хотя уже достаточно стабильная, и практически нет приложений её использующих.

Спрашивается, а нафига тогда нужны уродства в виде GTK или Qt? Короче, нет предела совершенству!

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

>Я просто говорю, что лучше, когда это разные проекты.

Конечно лучше. Скажу больше: это просто охрененно, когда для написания той или иной программы нужна пачка разнородных библиотек разных версий, с разными системами сборки, с разным подходом к стабильности API, с разным стилем именования в конце концов! А особенно хорошо эти прелести раскрываются, когда встаёт вопрос переносимости на другую платформу....

Продолжай, я записываю.

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

> Просто сходите на сайт xcb.

Ходил уже сегодня, там дата последнего обновления далеко в прошлом.

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

>>Как минимум: в настоящем ООП языке объектом является ВСЕ. Включая функции и классы.

> Почему?

Вот почему цппшники так рьяно наезжают на сишников, которым ООП и без кейворда class в языке хорошо пишется? А когда им показываешь пальцем на конеподобный трах с шаблонами в stl, boost, etc, которыми они пытаются подражать встроенным средствам в более мощные языки, они сразу говорят, что им и так нормально, другие языки не нужны?

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

> Это с какого перепугу MFC внезапно стала C-библиотекой? Она всю жизнь была C++...

А там вообще про платформы-надстройки говорилось, вне зависимости от языка.

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

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

Там говорилось про платформообразующие либы, которые традиционно в юниксе пишутся на Си!

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

> платформообразующие либы, которые традиционно в юниксе пишутся на Си!

"Пути меняются, Стилгар. Ты и сам их менял." (c) Дюна

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

> Там говорилось про платформообразующие либы, которые традиционно в юниксе пишутся на Си!

И пусть продолжают писаться!

Но вот gtk -- это уже не платформенная либа, а обёртка к платформенной либе Xlib, которая в свою очередь обёртывает иксовый протокол :)

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

> Только вот мёртвая, ибо представляла собой обёртку для другой платформы(win32).

Совсем по другой причине. Маркетинг МС выделывает чудеса с девелоперсами, девелоперсами, девелоперсами.

> Обёрткообразующая либа. Платформа -- это X11.

Возьмите себя в руки и вспомните о том, что платформы бывают разных уровней. О том, что платформы подобны стеку. И пр. и пр. А то Вы все обзовете обертками над микрокодом Вашего проца.

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

> Но вот gtk -- это уже не платформенная либа, а обёртка к платформенной либе Xlib, которая в свою очередь обёртывает иксовый протокол :)

Совсем не так, платформа - это ваш x86_64 или что там у вас. :D

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

> етк - не смотрел. Как-то не верю в платформу имени одного гения...

Лучше один гений, чем тысяча посредственностей.

З.Ы.: сам особым фанатом Растермана не являюсь :))

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

> Ну тоже типа платформа. Только вот мёртвая, ибо представляла собой обёртку для другой платформы(win32).

И? Куда-то вы в сторону уводите. svu сказал "платформообращующие библиотеки в юниксе должны быть на С". Т.е. про язык а не какую-то обёртку, которая тоже не на C.

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

> Возьмите себя в руки и вспомните о том, что платформы бывают разных уровней. О том, что платформы подобны стеку. И пр. и пр.

Ладно, давайте отделим то, что является платформенной библиотекой UNIX. По мне, так тут дело выше Xlib не уходит.

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

> Ладно, давайте отделим то, что является платформенной библиотекой UNIX. По мне, так тут дело выше Xlib не уходит.

Писец, тебе ведь уже сказали про платформы _разных_уровней_ . Прекрати так тупить!

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

> И? Куда-то вы в сторону уводите. svu сказал "платформообращующие библиотеки в юниксе должны быть на С". Т.е. про язык а не какую-то обёртку, которая тоже не на C.
Возможно, у меня просто плохо получается проводить аналогии или же мои собеседники их плохо видят. Ну да ладно, буду тренироваться...

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

> Писец, тебе ведь уже сказали про платформы _разных_уровней_ . Прекрати так тупить!

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

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

>> Обёрткообразующая либа. Платформа -- это X11.

> Возьмите себя в руки и вспомните о том, что платформы бывают разных уровней. О том, что платформы подобны стеку. И пр. и пр. А то Вы все обзовете обертками над микрокодом Вашего проца.

+1, gaa забрался в какие-то дебри. Модульность - это хорошо как ни крути. Хотя насчёт "платформы! я больше склоняюсь к тому, что платформа - GNOME, GTK+ - библиотека. Не поворачивается у меня язык назвать GTK+ платформой. Впрочем я не такой уж и знаток GTK...

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

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

Какое сегодня число? 4 июня 2008г - уже далёкое прошлое? Опять я всё пропустил.

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

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

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

>Вот почему цппшники так рьяно наезжают на сишников, которым ООП и без кейворда class в языке хорошо пишется? А когда им показываешь пальцем на конеподобный трах с шаблонами в stl, boost, etc, которыми они пытаются подражать встроенным средствам в более мощные языки, они сразу говорят, что им и так нормально, другие языки не нужны?

Поправочка. Языки по соотношению удобство/скорость. Если мне покажут язык без костылей, то мой выбор будет сделан!

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