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

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

>нужно оно, или не нужно???

гнум не нужен. )

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

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

Да. оно нужно. С чего такие странные вопросы?

tailgunner ★★★★★
()
Ответ на: кст от wfrr

>Настойчиво советую вам сделать промывание желудочков головного мозга, >ибо никто от стандартов не отходил и ничего не уменьшал. >wfrr # (*) (04.06.2008 15:44:48)

wfrr что вы такой нервный? сделайте себе промывание

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

> Но по первым двум возражений нет? Ну и славно.

Кроме того, что пипи - тормоз, возражений не имею. Проходите. :)

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

>Cи - не ООП-язык как интересно, значит язык, в котором реализовано ООП не является ООП-языком? Даже не смешно.

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

>>напомните, когда умерли все программы на 1.x?

>В прошлом тысячелетии, а что?

Когда закончилось прошлое тысячелетие? Точнее когда вышел GTK-2.0? ;) А когда вышел например стабильный GIMP на GTK-2?

Swappp
()

> Наверное, таким образом разработчики пытаются избежать кошмара миграции, который можно видеть на примере библиотеки Qt.

Вы идиот? Qt3 и Qt4 - разные звери, там переписали почти всё. А тут - даже ничего нового не добавили, просто всё старое срезали и обозвали 3.0.

Кстати, кошмара миграции не было, т.к. была специально сделана qt3support ( http://doc.trolltech.com/4.0/qt3support.html ).

Кошмар миграции - это, наверное, с гтк1 на гтк2.

ChALkeR ★★★★★
()

понаехало боевых анонимусов.

FYI:

С - язык гарантирующий полный контроль над тем _что делается_. Потому на нем пишутъ KERNEL

С++ - С + возможность описания нового ТИПА ДАННЫХ. То есть можно матрицу объявить и умножать её одним знаком. В С++ НЕТ ООП. Тем, у кого то класс=объект, срочно пересесть на виндавз. Для ООПа в C++ надо добавить костыли - boost::smart_pointers, и, опционально boost::signal. Выделение памяти в С++

В Qt есть ООП: QObject; В GTK юзается GObject; И, прежде чем расфуфыриваться про то что C++\QT круче чем GTK\GObject стоит наверное, хотя бы узнать что это такое, и почему в обоих тулкитах одинаковые действия делаются с одинаковой сложностью.

ЗЫ: сигнал в QT - это что то. а на ассемблере - что то с чем то.

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

> Между прочим, все приложения, собранные с Gtk-2.X1.Y, без перекомпиляции запускаются на любой версии Gtk-2.X2.Y, при условии что X2 > X1. Так что не стоит Qt-шникам троллить про "кошмары" :-)

Qt 4.3 приложения запускаяются на Qt4.4. Comments?

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

>То, что фразы "как по мне, там и без плюсов неплохо" нужно произносить, только если есть значительный опыт работы на Gtk без Си++.

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

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

>новых возможностей в этой версии будет много, потерпите, скоро всё сами увидите. :)

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

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

>>То, что фразы "как по мне, там и без плюсов неплохо" нужно произносить, только если есть значительный опыт работы на Gtk без Си++.

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

Дадада, Страус - маст дай.

> так что это сомнительная сентенция.

Ты ветеран программирования на Gtk + голый Си, я правильно понимаю?

tailgunner ★★★★★
()

Если резюмировать планы, то всё сводится к переписыванию ГТК заново. :)

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

> Ключевое слово "переписывают".

Прошу прощения, а вот появился новый фреймворк с новыми возможностями и старые приложения начали его использовать без переписывания - ЭТО КАК?

Aceler ★★★★★
()
Ответ на: понаехало боевых анонимусов. от anonymous

>С++ - С + возможность описания нового ТИПА ДАННЫХ. То есть можно матрицу объявить и умножать её одним знаком.

Есть хорошее мнение что на начальной стадии работы над проектом всех любителей делать новые типы и перегружать операторы надо отправить специализировать шаблоны для максимального использования в std::valarray инструкций 3DNow/SSE2. Так они натворят гораздо меньше вреда на начальном этапе.

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

> Кстати, кошмара миграции не было

Это уже становится мантрой.

> Кошмар миграции - это, наверное, с гтк1 на гтк2.

Почему нет? :)

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

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

Нужно. Это улучшит совместимость GTK с С++ рано или поздно :)

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

> без переписывания - ЭТО КАК?

Под "переписывать" в том контексте понималось переписывание с нуля.

Bohtvaroh ★★★★
() автор топика
Ответ на: понаехало боевых анонимусов. от anonymous

С++ - С + возможность описания нового ТИПА ДАННЫХ. То есть можно матрицу объявить и умножать её одним знаком. В С++ НЕТ ООП.

У тебя неправильно работает diff в мозге, свяжись с мейнтейнером diff'а, и с мейнтейнером мозга немедленно.

Дальнейший твой бред можно не читать.

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

>>>То, что фразы "как по мне, там и без плюсов неплохо" нужно произносить, только если есть значительный опыт работы на Gtk без Си++.

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

>Дадада, Страус - маст дай.

Что-нибудь кроме эмоций будет?

>> так что это сомнительная сентенция.

>Ты ветеран программирования на Gtk + голый Си, я правильно понимаю?

Гуйню на Си/Си++ я под оффтопик в основном писал. С Си интерфейсами GDI & OpenGL гиморроя намного меньше чем со всяким хламом из std::.

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

>Нужно. Это улучшит совместимость GTK с С++ рано или поздно :)

о_О Зачем?

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

> Под "переписывать" в том контексте понималось переписывание с нуля.

Ну оно и в этом контексте также понимается. Та часть, которая может работать с qt3, в переписывании не нуждается - те же гуя можно просто пересоздать с новыми библиотеками. Всё остальное же так или иначе придётся переписывать - если раньше вы работали с десятком звуковых движков, а в Qt 4.4 появился Phonon - сели, переписали, порадовались.

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

> Тогда исправьте новость. "На примере библиотеки gtk2" надо было закончить фразу :)

Одно было давно, а другое свежо. Можно в принципе и то, и то привести как довод. :)

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

Ну вот, опять развели срач C++ vs C.

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

А GObject - вообще отдельная песня. Юзать GObject'ы удобно, а вот написать свой - убиться веником. Каша из макросов.

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

>С Си интерфейсами GDI & OpenGL гиморроя намного меньше чем со всяким хламом из std::.

Не сравнивай с вендой, троллишко, сравнивай qt и gtk

anonymous
()

>Ты ветеран программирования на Gtk + голый Си, я правильно понимаю?

Я - Страуструп. И, к сожалению, я вынужден признать, что С++ - говно.

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

>>>>То, что фразы "как по мне, там и без плюсов неплохо" нужно произносить, только если есть значительный опыт работы на Gtk без Си++.

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

>>Дадада, Страус - маст дай.

>Что-нибудь кроме эмоций будет?

Это не эмоции. Так - грустная ирония...

>> Ты ветеран программирования на Gtk + голый Си, я правильно понимаю?

> Гуйню на Си/Си++ я под оффтопик в основном писал

То есть - не ветеран. Но мнение имеешь.

> С Си интерфейсами GDI & OpenGL гиморроя намного меньше чем со всяким хламом из std::.

Я не писал на WinAPI и OpenGL, но писал для PM (говорят, это похоже на WinAPI). Так вот, с std::* геморроя куда меньше, _если_ понимать STL и Си++. Ты их не понял (или не захотел понимать).

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

>"Правильный" тулкит должен легко биндиться на другие языки, чего за тулкитами, завязанными на С++, не наблюдается.

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

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

кагбэ вы такими словами то не кидайтесь, типа valarray. Оный не везде применим вообще то.

далее, вы прежде чем писать про SSE хоть узнайте что это такое. А то насоветуете такого, что штрафные циклы на межстрочный промах будет начислять или еще круче - #GP/#AC по башке лупить.

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

>Юзать GObject'ы удобно, а вот написать свой - убиться веником. Каша из макросов.

Попробуй написать ActiveX компонент. Или шаблон a-la те что в Loki:: или boost::. Или Джава Бин промышленного коммерческого уровня. Или вообще любую нормальную библиотеку с нормальным API.

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

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

Им нужно, чтобы qt биндился на язык, на котором написан gtk, но это, в силу совершенной непригодности языка Си для ООП - невозможно

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

>То есть - не ветеран. Но мнение имеешь.

То есть, ты перешёл на личности. И пытаешься что-то доказывать.

>понимать STL и Си++

заучить. нечего там понимать

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

>А GObject - вообще отдельная песня. >Юзать GObject'ы удобно, а вот написать свой - убиться веником. >Каша из макросов.

слова не мальчика но мужа. Вот собсна и главная беда GTK. НЕТУ МЛЯ распространяемого и вменяемого генератора object'ов. есть GOB ненормальный какой то, есть vala - нормально генерит классы только после танцев с бубном - нет документации вменяемой.

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

>Нет, Страуструп один из главных разработчиков языка C++ и написал одну >из лучших книжек по этому языку. Не дополняйте чужие мысли своими >нелепыми догадками в стиле жёлтой прессы, "мусье".

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

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

>>То есть - не ветеран. Но мнение имеешь.

>То есть, ты перешёл на личности.

Пытаюсь оценить достоверность источника информации.

> И пытаешься что-то доказывать.

Нет.

>>понимать STL и Си++

>заучить. нечего там понимать

Можно и так, если вас не интересует результат.

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

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

садись, два.

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

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

садись, два.

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

>У тебя неправильно работает diff в мозге, свяжись с мейнтейнером diff'а, и с мейнтейнером мозга немедленно.

якой умный анонимуз. иди торвальдса унизь еще, он тоже с++ обложил как то.

//скотинко

anonymous
()

Как по мне, пофигу на чём написана программа, если она работает не слишком медленно и выполняет свои функции. Лично у меня единственное пожелание, чтобы внешне они выглядели одинаково. Пока этого не будет, будет продолжаться срач GTK+ vs Qt, плавно переходящий в C vs C++ etc...

У freedesktop нету никаких сподвижек в сотрону создания спеки для тем GUI?

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

> Юзать GObject'ы удобно, а вот написать свой - убиться веником. Каша из макросов.

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

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

>якой умный анонимуз. иди торвальдса унизь еще, он тоже с++ обложил как то.

он еще и гном обложил, так что его мнение как неврастеника ничего не значит

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

>> Юзать GObject'ы удобно, а вот написать свой - убиться веником. Каша из макросов.

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

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

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

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

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

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

>Им нужно, чтобы qt биндился на язык, на котором написан gtk

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

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