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

>Как насчёт воспользоваться готовым биндингом?

GTK - говно внутри, биндинги - лишь красивая обертка

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

>Биндинги к QT пишутся если они реально нужны а написание биндингов к GTK является самоцелью. У меня биндинги и к питону и к руби потянулись по зависимостям. Биндинги GTK к большинству языков лежат мёртвым грузом в репозитории так как число приложений их использующих близко к числу самих биндингов

В точку! :)

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

> Не только. Биндинги к QT пишутся если они реально нужны а написание биндингов к GTK является самоцелью. У меня биндинги и к питону и к руби потянулись по зависимостям. Биндинги GTK к большинству языков лежат мёртвым грузом в репозитории так как число приложений их использующих близко к числу самих биндингов

нет

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

D ничо так. и ObjectiveC тоже неплох. но...

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

В С++ нет ничего этого автоматом, о чем местные тролли не знают.

для учета использования boost - это костыль. счетчик использования там делается через создание нового UINTа, отдельно от класса. //скотинко

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

>нет

мне бы научиться так аргументировать! :)

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

>Кто тупому КДЕ-шнику объяснит - нужно оно, или не нужно???

не нужно

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

>непригодности языка Си для ООП

ООП на C - это хранение данных в структуре и передача указателя на оную в функции. И это всё. И это всё, что требуется в 80% случаев. И не нужно городить огород из макросов и ручных проверок типов для обеспечения полиморфизма и пр. Ибо не нужно в 80% случаев. Подводя черту: да, я люблю C, и именно с ООП, но именно таким "дедовским" способом.

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

>> Что-то меня настораживают такие слова... "каша из макросов"... а как эту кашу биндить к другим языкам, допустим паскаль или хаскель? Делаю вывод, что наличие стандарта на ABI ещё не гарантирует простоты биндинга.

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

хм... если пользоваться готовым, то между gtk и qt4 для меня никакой разницы нет, т.к. биндинги и к паскалю, и к хаскелю уже есть. О чём тогда вообще разговор про биндинги qt? или ко всем остальным языкам их сделать нереально?

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

>>Страус написал самую идиотскую книгу по C++!

>Значит, что ты как идиот зря потратив время на ее прочтение =)

Он Ъ и поэтому не читал

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

>ООП на C - это хранение данных в структуре и передача указателя на оную в функции. И это всё. И это всё, что требуется в 80% случаев.

Посмотрим, сколько изврата будет в gtk3 с теми же приватными методами =)

>Подводя черту: да, я люблю C, и именно с ООП, но именно таким "дедовским" способом.

А может лучше с девушкой?

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

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

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

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

А эти 20% - как программировать? Ну и ООП без полиморфизма - это уже не ООП.

tailgunner ★★★★★
()

нихрена себе нафлеймотролефлудили

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

>В С++ нет ничего этого автоматом, о чем местные тролли не знают.

Прикол в том что на Си++-ной модели памяти подсчет ссылок это единственный способ контроля времени жизни объекта, если не извращаться со всякими (бесполезными) объектами-значениями. При этом Страус зачем-то не опустил этот долбаный счетчик ссылок на уровень языка.

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

>>>Страус написал самую идиотскую книгу по C++!

>>Значит, что ты как идиот зря потратив время на ее прочтение =)

>Он Ъ и поэтому не читал

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

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

> А я люблю С++, за его вменяемый ООП

Вообще-то это я придумал термин "объектно-ориентированный". Так вот, С++ - это не то, что я имел в виду -- Alan Kay

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

а потом все будут говорить про qt и его "кошмары миграции"

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

Не знаю, как у других, а в федоре вся конфигурационная часть и обновления написаны с использованием pygtk.

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

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

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

Я не спорю, pygtk широко используется, я говорил о биндингах к всяким брейнфакам. Можно ещё моно вспомнить =)

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

> Я не спорю, pygtk широко используется, я говорил о биндингах к всяким брейнфакам.

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

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

Моно не трожь, F-Spot и Banshee рулят.

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

>Выделение памяти в С++ без boost::smart_pointers это суперкостыльное программирование либо источник утечек памяти.

Либо следствие криворукости и кривого дизайна.

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

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

> Если кто на D пишет, посмотрите эту вещь

10x, как раз были аналогичные мысли. Буду почитать что они там наконцептировали. :)

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

> в случае gtk это не так

тем не менее, наличие большого числа биндингов не стоит называть минусом тулкита. Равно как и изначальную заточенность gtk (и glib вообще) именно на написание биндингов

(как бы капча coading)

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

всё, stop trolling

Дано:

ООП = QTLanguage + libqt ООП = C + GLib (не GTK как тут некоторые думают)

холиварщики строятся в колонны и идут в лес. просто есть два тулкита для разных языков. На С единственная сложность - это делать free когда надо. решается обнулением указателей в начале и выходом в одной точке c if(pointer) free(pointer); как сказано в писании, это писать должен компутер, потому и делают vala - дописывалку быдлокоманд.

ЗЫ: Торвальдс не только С++ опустил, он еще и GTK опустил перед QT. такой вот дуализм. ЗЗЫ: я пишу на gtk+С+vala.

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

>Равно как и изначальную заточенность gtk (и glib вообще) именно на написание биндингов

Ага, в то время как qt изначально заточен на написание GUI =) У каждого своя ниша =)

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

>У меня мона не установлена. Эх, тяжела жизнь гномеров :'(

А вот левый таббар в Амароке не работает при использовании цветовой схемы отличной от дефолтовой - там цвет фона hardcoded.

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

Пристрилите их, чтоб не мучились. Лучше Qt все равно ничего не придумаешь.

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

>Либо следствие криворукости и кривого дизайна.

на самом деле это следствие эксепшенов. вот сделаешь new X() а тебе где то по дороге приходит эксепшен и опаньки. а с поинтерами std::shared_pointer<X> px(new X()) и не боишся эксепшена.

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

> А вот левый таббар в Амароке не работает при использовании цветовой схемы отличной от дефолтовой - там цвет фона hardcoded.

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

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

> А вот левый таббар в Амароке не работает при использовании цветовой схемы отличной от дефолтовой - там цвет фона hardcoded.

Пиздежь. 4.2

anonymous
()
Ответ на: всё, stop trolling от anonymous

> Торвальдс не только С++ опустил, он еще и GTK опустил перед QT.

не путай придурошный GNOME и GTK.

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

> Если кто на D пишет, посмотрите эту вещь - http://hybrid.team0xf.com/wiki/Main/Overview .

Hybrid. Разработан специально для и параллельно с Deadlock. Идеально подходит для описания графических интерфейсов в играх и других программах, перерисовывающих всё окно в каждом кадре. API чем то смахивает на JavaFX. Только bind нет... А жаль.

Чего же я новость не написал когда он вышел около месяца назад?

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

>А вот левый таббар в Амароке не работает при использовании цветовой схемы отличной от дефолтовой - там цвет фона hardcoded.

Ай-яй-яй, какой плохой язык С++, цвет фона хардкодит.... %)

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

виноват, виноват. извиняюсь.

gnome это вообще недоразумение. и появление в его составе всяких там мигелей и mono - вполне ожидаемое наступление гномокапца.

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

>А вот левый таббар в Амароке не работает при использовании цветовой схемы отличной от дефолтовой - там цвет фона hardcoded.

Это где "коллекция", "контекст"? Проверил, всё отлично работает. Амарок 1.4.9.1

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

>Я свое мнение о моно изменил когда узнал что f-spot и banshee написаны на нем.

я тоже) ни то ни другое не хочет запускается в бубунте...

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

> gnome это вообще недоразумение. и появление в его составе всяких там мигелей

появление в составе GNOME основателя GNOME? I lol'd

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

> gnome это вообще недоразумение. и появление в его составе всяких там мигелей и mono - вполне ожидаемое наступление гномокапца.

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

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

>появление в составе GNOME основателя GNOME? I lol'd

это весенний молодняк анонимусов забрел в тему. Зеленые еще... глупые...

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

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

А кто их одновременно запихал? qt-3.x бинарно совместимы, причём, зачастую, в обе стороны. Исключение составляет ситуация, когда в следующий минор добавляются какие-то новые классы. qt-3.3.x полностью совместимы

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

>Ты хочешь сказать, что гномокопец наступает с создания гнома?

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

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

> это весенний молодняк анонимусов забрел в тему. Зеленые еще... глупые...

The initial project leaders for GNOME were Miguel de Icaza and Federico Mena. (с) wikipedia

комментарии?

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