LINUX.ORG.RU

Будущее GTK

 ,


0

0

Сайт ars technica выложил подборку статей и интервью, где обсуждаются планы будущего развития GTK+. В общем, можно выделить такие направления:

  • Imendio, компания, ведущая около-GTK'шную разработку, а также спонсирующая порт GTK+ на MacOS X, предлагает реализовать эффекты, анимацию, физику (!) для улучшения пользовательского интерфейса (полный доклад http://developer.imendio.com/sites/de...)
  • Хавок Пеннингтон, который недавно ушел из Red Hat, 9 лет занимавшийся разработкой GNOME, предлагает интегрировать так давно необходимый Canvas в GTK+3.0. До этого разработчикам приходилось использовать для своих нужд сторонние разработки, что вызывало ряд проблем. Полный текст письма http://mail.gnome.org/archives/gtk-de....
  • Целый ряд разработчиков во главе с Mirco Muller (Canonical, Ltd) мечтают увидеть отрисовку виджетов полностью на OpenGL, что позволит создавать любые мыслимые и немыслимые эффекты для приложений. Некоторые успехи уже есть http://arstechnica.com/news.ars/post/..., но это все равно еще не предел. Плюс Andrea Cimitan уже сделал поддержку rgba прозрачности в виджетах, что добавляет оптимизма.

Подводя итоги, нужно сказать что GTK+ - замечательный тулкит, но все же некоторые болезни есть и у него. Сюда входят и две абсолютно разные модели заселения тулбаров, и три схемы построения интерфейса на основе XML, и разные проблемы с попиксельным позиционированием виджетов. Все это не может быть решено без слома старого API, поэтому в стане GTK+ все чаще звучат голоса в поддержку нового API в GTK+3.0. Все же, усилия Immendio, Пеннингтона и огромного сообщества делают будущее GTK+ чистым и ясным.

>>> Подробности

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

>Ну это я так, всё равно фантазирую.

Чуваг, ты не фантазируешь, ты газифицируешь.

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

Другие языки - это пистон? Спасибо, не надо.

C++-библиотеки должны сдохнуть, вместе с самим C++.

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

Мнение школьника никому на фиг не нужно. Школьник мог бы и промолчать, меньше бы обпозорился.

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

>C++-библиотеки должны сдохнуть, вместе с самим C++.

Анонимусам они ничего не должны.

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

>1) множественные формы появились только в 4.4

В Qt4 вижу QObject::tr ( const char * sourceText, const char * comment = 0, int n = -1 )

n — это та самая plural form. И в лингвисте можно их задавать

>2) создать программу, которая не работает с кириллицей - до сих пор как нехрен делать.

А это везде так, кроме явы, вероятно. Хотя, пределы человеческого маразма бесконечны, и, возможно, даже на яве можно сделать приложение, которое работает только с ascii

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

>2) создать программу, которая не работает с кириллицей - до сих пор как нехрен делать.

Кстати, для выявления таких творений есть -DQT_NO_ASCII_CAST :)

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

> а склепать, пардон, говно -- как нехрен делать ;)

hydrogen-music.org

Полегче в выражениях :)

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

> Не стоит так "массово" заниматься развешиванием ярлыков.

Ну про ПМ не знаю, а C++ видел в программе ПОВТ и САПР лет 5 назад

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

> Он медленнее GTK, поэтому по крайней мере на более медленных машинах он лучше. Поэтому с вашим ИХМОм можете сами знайте куда сходить.

Возможно уважаемый анонимуз, Объясните мне убогому, почему у меня на Intel Quadro 6600, 4 Gb RAM, Nvidia 8600 GT 512 Mb, - Gnome, основанный на замечательном легком и быстром GTK, тормозит, а KDE 3.5.9, на глючном, убогом и тормозном Qt, летает? И не надо фанатизма, я сам сидел 2 года на Гноме, пока KDE 3 не допилили до нормального состояния.

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

> Тулкиты скорее всего не причём, тормозит винт, особенно в гноме при запуске это заметно.

ржал.

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

> тебе придется ВЕСЬ Qt на фабриках переписать, чтобы не отрезать от GTK нехилую часть при внедрении в этот самый Qt. Возьмешься? А смысл?

Да запихать их в один пакет да и дело с концом. :) Ещё неплохо бы написать единый формат тем, но это тоже весёлая задачка.

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

А что, прикольно - вместе с иксами устанавливаешь пакет gtkqt, который автоматом тащит за собой gtk-qt-engine и после этого тебе уже всё равно. Ну или почти всё равно - диалоги пока что в рамках FDO не доделаны.

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

Шёл бы ты сравнил время запуска гнома на старом винте, на винте поновее, на raid-0,1 и на SSD. Первоклассник знает, что самое узкое место в компе (не считая сетевых заморочек) - это винт. Привет, школа!

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

> криворуким красноглазикам винт мешает.

унылый тролль уныл... (C)

Bohtvaroh ★★★★
()

Так в чём физика заключается? Слайды ненужные постить -- уже лоро-новости?

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

> пакет gtkqt, который автоматом тащит за собой gtk-qt-engine

Это унылое Г не позволяет редактировать меню гткшных приложений на лету.

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

>2) создать программу, которая не работает с кириллицей - до сих пор как нехрен делать.

keywords: "миша", "прищемить", "неправильные двери" =)

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

> Это унылое Г не позволяет редактировать меню гткшных приложений на лету.

Значит надо работать. Предложите менее унылое Г.

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

> Я уже полностью отказался от мыл-программ и храню всю свою почту в вебе из-за при3.14зженных мейлеров, почему нельзя сохранять МОЮ почту в МОЕМ MAILBOX нахрена мне куча нестандартных директорий от разных тандербердов, кмылово и прочего дерьма, почему отсутствует в моей домашней директории СТАНДАРТНАЯ общедоступная (для программ) адресная книжка и еще море почему?

KMail: Настройки -> Настройка KMail -> Прочее -> По умолчанию сообщения на диске хранятся в: Обычных файлах (формат "mbox")/Каталогах (формат "maildir")

Вот, не поленился открыть тебе глаза, надеюсь оценишь.

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

> Виста не использует GL. GL используется в макоси. И что-то не заметил я там аццких тормозов и жутких потребляемых ресурсов

запусти в макоси терминал, и сравни скорость его прорисовки с оной под линухом на том же компе.
при компиляции софта оч критично (приходится перенаправлять, детачить screen, и т.п.).
вполне себе аццкие тормоза, разов в 10 тормознее иксов под линухом.

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

>запусти в макоси терминал, и сравни скорость его прорисовки с оной под линухом на том же компе

на работчий мак мне линь водрузить никто не даст, но на компе со схожими железяками konsole и gnome-terminal рисуются медленнее, чем терминалка в леопарде. Везде, естественно, ttf с субпиксельным сглаживанием.

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

> При движении в сторону Gtk3 переход будет постепенный без кардинального ломания софта. А не как в KDE.

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

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

>> Гтк-шный ооп - феерическое говно. Прекрати вообще выдавать эти кривые костыли за вершину программерской мысли.

>Qt'шный ООП в частности и C++'ный ООП в общем - говно. Прекрати выдавать эти кривые костыли за вершину программерской мысли.

Нет млять - GTK-шная эмуляция С++ на С это просто п*дец какая вершина технической мысли от дебилоидов-фанатиков С для извращенцев пейсателей грфических программ на С. Эмуляция объектов на убогом се увешанном кучей макросов для преобразования в наследуемые объекты и объекты-родители. Ипануться и не встать.

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

>Эмуляция объектов на убогом се увешанном кучей макросов для преобразования в наследуемые объекты и объекты-родители. Ипануться и не встать.

На Це++ графические программы пишутся еще черезжопней - идиот Страус нормальные эвенты так и не сделал, а городить vTable из 400+ элементов для каждого потомка TWindow даже Микросовту в голову не пришло.

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

> На Це++ графические программы пишутся еще черезжопней

Зато пишутся гораздо проще, потому что объекты там есть и пользоваться ими можно без костылей-макросов. наверное поэтому разработчики Opera, Skype, GoogleEarth, Tora, ATI и др. и используют нормальный полноценный C++ тулкит, а не GTK-шное извращение.

> идиот Страус нормальные эвенты так и не сделал, а городить vTable из 400+ элементов для каждого потомка TWindow даже Микросовту в голову не пришло.

Напомнить, что такое MFC?

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

>> На Це++ графические программы пишутся еще черезжопней

>Зато пишутся гораздо проще, потому что объекты там есть и пользоваться ими можно без костылей-макросов. наверное поэтому разработчики Opera, Skype, GoogleEarth, Tora, ATI и др. и используют нормальный полноценный C++ тулкит, а не GTK-шное извращение.

Все костыли там в moc. Комплексный подход.

>Напомнить, что такое MFC?

switch по идентификатору события, стыдливо спрятанный за макросами BEGIN_MSG_MAP ... END_MSG_MAP ? Бгг

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

>switch по идентификатору события, стыдливо спрятанный за макросами

по сравнению с тем что творится в гтк - это сказка просто. кроме всего прочего писать на МФЦ действительно просто хоть и быдловато. писать на гтк - это вообще понос мозга.

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

>кроме всего прочего писать на МФЦ действительно просто хоть и быдловато. писать на гтк - это вообще понос мозга.

Ну если сравнивать формочковый быдлокодинг на МФЦ с чем-то аналогичным COM-кодингу на гтк, то да.

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

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

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

>> идиот Страус нормальные эвенты так и не сделал

>А какие "эвенты" считаются нормальными?

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

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

>Нет млять - GTK-шная эмуляция С++ на С это просто п*дец

идиот, школу закончи сначала, может поймешь тогда, что gobject это не эмуляция говноплюсов

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

>Зато пишутся гораздо проще

по-твоему, дельфи и vb - вершина программерской мысли? =)

> потому что объекты там есть и пользоваться ими можно без костылей-макросов.

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

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

> А какая разница под каким DE?

В гноме ты идёшь в диалог настройки панелей и говоришь "Хачу динамические клавиатурные комбинации прямо щаз" и получаешь их.

В кедах ты прыгаешь с бубном и gtkrc

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

>В гноме ты идёшь в диалог настройки панелей и говоришь "Хачу динамические клавиатурные комбинации прямо щаз" и получаешь их.

>В кедах ты прыгаешь с бубном и gtkrc

В кедах ты хочешь записать диск через удобную граф.оболочку - записываешь его в K3B

В гноме ты прогаешь с бубном и получаешь хyй

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

>В гноме ты прогаешь с бубном и получаешь хyй

что любишь, то и получаешь, а те, кто хочет записать диск - идут в меню "Переход->Создать CD/DVD", кидают туда нужные файлики и нажимают кнопочку "записать на диск"

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

>В гноме ты прогаешь с бубном и получаешь хyй

Хм... чем K3B круче Brasero?

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

> тогда, что gobject это не эмуляция плюсов

gobject - жалкий FAIL. Смешно, но они делают проверку типа даже когда кастуют из дочернего класса в базовый и в каждой функции сидит ручная защита от ошибки типизации популярной в си. олсоу вся твоя гтк - унылый быдлокод, на С++ можно писать гораздо компактнее и эффективнее.

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

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

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

Даже майкрософт ничего не смог придумать кроме как всегда делать явный кастинг с помощью QueryInterface, в т.ч для конвертации дочернего типа в базовый. Базировались бы на Objective C как Apple, было бы веселее.

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

Сложность написания кода на С++ равна сложности написания кода на С плюс трудозатраты на войну с С++.

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

> Сложность написания кода на С++ равна сложности написания кода на С плюс трудозатраты на войну с С++.

А ты не борись с ним - используй его. Впрочем, если ты начинал с Явы, лучше там и оставайся.

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

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

лолшто?

> Сложность написания кода на С++ равна сложности написания кода на С плюс трудозатраты на войну с С++.

ты по себе-то не суди.

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