LINUX.ORG.RU
Форум — Development  

Рациональные доводы в пользу Qt и Gtk

 , , ,


2

5

Привет ЛОР, пишу в удаленный тред конечно, но! Есть пару недостоющих мне приложений, которые я хочу дописать, но в свете последних событий (выхода Gtk3 и Qt5) не могу выбрать тулкит.

Это конечно невозможно, но прошу привести рациональные доводы в пользу того или иного тулкита. Т. к. писать я собираюсь под то на чем сижу, то даже такие мелочи как DE важны. Ко всему кроссплатформенность не так важна, если только на мобильные платформы, т. к. не хватает мне этого ПО именно в Linux.

Пока что я прикинул только:

Qt

  • Qt5 пошустрее Gtk, но это, я думаю, дело поправимое
  • Огромная поддержка платформ, но в то же время Linux не является приоритетной платформой, как с GTK, да и опять же дело поправимое

Gtk

  • Gnome3 мне не очень пока что нравится, но это субъективно, да и не гномом едины
  • Мейнстрим - на Qt нет ни одного крупного браузера (QupZilla явно не попадает под определение крупного популярного браузера)
  • Gnome'вский стек по мне лучше, хотя бы тем что он на GLibc, который еще много где используется
★

 ← 1 2 3 →
Ответ на: комментарий от dearboy

Любой функционал можно разделить на модули. Соответственно разные модули можно разделить между бэкендом и фронтэндом. Ну а дальше уже все дело техники.

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

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

ivanlex ★★★★★
()

всё бы хорошо но разработчики gtk отпиливают ноги своему детищу

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

ну да, ну да, куте ни разу от иксов не зависит напрямую, ага.

и не знаю, какие там у тебя 24, у меня только на QtGui ldd 29 либ показывает

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

ну да, ну да, куте ни разу от иксов не зависит напрямую, ага.
и не знаю, какие там у тебя 24, у меня только на QtGui ldd 29 либ показывает

опять показываешь свое невежество:

а) ты явно у себя смотришь Qt4, а я приводил (и это было видно) данные про Qt5
б) «только на QtGui ldd 29 либ показывает» - а это не только, это именно все зависимости, включая зависимости QtCore, и, повторюсь, считать их в целом глупо, у меня только libGL тянет еще 12 системных библиотек, но это не зависимости Qt

wota ★★
()

Что за недостающие приложения, автор так и не сказал, поэтому тему можно закрывать. Скорее всего автор виндузятник и просто не осилил man.

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

точно так-же, как и глупо считать ЗАВИСИМОСТИ от cairo недостатком gtk только на том основании, что в qt внутри свой некислый велосипед

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

точно так-же, как и глупо считать ЗАВИСИМОСТИ от cairo недостатком gtk только на том основании, что в qt внутри свой некислый велосипед

а вот потому я и привел только прямые зависимости libgtk-3, а не ссылался на ldd

wota ★★
()

Qt - это не toolkit, по этому дальше не читал.

а) ты явно у себя смотришь Qt4, а я приводил (и это было видно) данные про Qt5

О, сразу вспоминаю как после портирования проекта на Qt5 размер распакованного архива программы вырос с 60мб, до 100мб. Под вендуз естественно, особено доставляет библиотека icudt51.dll размером в 22мб.

bhfq ★★★★★
()
Последнее исправление: bhfq (всего исправлений: 2)
Ответ на: комментарий от wota

передергиваешь. и qtcore, и qtgui идут в одном архиве (qtbase). так что и учитывай все прямые зависимости, необходимые для qtbase

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

Не рекомендую ни под каким предлогом ввязываться в количество-so-файлов-срач. Совершенно ничего не значащий параметр

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

Совершенно ничего не значащий параметр

доо, один из наших проектов работает даже на пятом centos, а теперь попробуй завернуть gtk3 со всеми зависимостями, чтоб он там заработал

wota ★★
()
Последнее исправление: wota (всего исправлений: 1)
Ответ на: комментарий от ananas

передергиваешь. и qtcore, и qtgui идут в одном архиве (qtbase). так что и учитывай все прямые зависимости, необходимые для qtbase

а тут всего два варианта:

а) Qt нужной версии есть в репе - пофиг на зависимости
б) ты таскаешь Qt с собой, значит смотрим только зависимости того, что лично нам надо

wota ★★
()

Да чего тут обсуждать, GTK умер вместе с второгномом.

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

особено доставляет библиотека icudt51.dll размером в 22мб.

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

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

в случае б надо учитывать ВСЕ косвенные зависимости

libnvidia-tls.so.319.32 => /usr/lib/nvidia-319/tls/libnvidia-tls.so.319.32 (0x00007f15da472000)
libnvidia-glcore.so.319.32 => /usr/lib/nvidia-319/libnvidia-glcore.so.319.32 (0x00007f15d7f1a000)

ну да - без них никуда, да и вдруг человек попробует запустить прогу на системе без иксов, надо обязательно их с собой таскать

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

ldd, sed, xargs, cp?

максимум, что таким способом можно получить, - сообщение о том, что libgtk-3 etc. с твоей системы не может отрезолвиться на старой системе, так что - только сборка с нуля, только десятки библиотек из тарболов, только радость от того, что оказывается для сборки нужны новые autotools, а в centos говно мамонта и т.д.

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

Не, бинарь собрать, поверг ядра, libc и иксов. Все остальные so тащить с собой

окей, возьмем первую попавшуюся зависимость:

~$ objdump -x /lib/x86_64-linux-gnu/libglib-2.0.so.0 | grep GLIBC_
    0x09691973 0x00 13 GLIBC_2.3.3
    0x09691972 0x00 06 GLIBC_2.3.2
    0x09691a75 0x00 05 GLIBC_2.2.5
    0x0d696917 0x00 16 GLIBC_2.7
    0x0d696919 0x00 15 GLIBC_2.9
    0x09691973 0x00 14 GLIBC_2.3.3
    0x0d696918 0x00 12 GLIBC_2.8
    0x06969194 0x00 11 GLIBC_2.14
    0x06969190 0x00 10 GLIBC_2.10
    0x06969195 0x00 09 GLIBC_2.15
    0x0d696914 0x00 08 GLIBC_2.4
    0x06969197 0x00 07 GLIBC_2.17
    0x09691974 0x00 04 GLIBC_2.3.4
    0x09691a75 0x00 03 GLIBC_2.2.5
    0x0d696913 0x00 02 GLIBC_2.3

ни о чем не говорит?

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

Тут как раз наоборот, GTK няшка, а Qt - какашка, особенно дефолтный Razor-Qt, выглядит уныло, чуть менее чем полностью (

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

На скрине тема Qt5 хороша, такую же можно сделать и для GTK3. На втором скриншоте походу движок темы не установлен, либо тема такая.

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

KDE не нужен, мне он не нравится, у меня Gnome2/XFCE головного мозга )

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

если ты таскаешь qt с собой, и они у тебя с libnvidia-tls слинкованы - таки никуда

о том и речь - не слинкованы, они слинкованы на libGL, а она уже в системе у каждого своя и тянет, что ей надо на каждом конкретном железе

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

На скрине тема Qt5 хороша
На втором скриншоте походу движок темы не установлен, либо тема такая.

это дефолты

такую же можно сделать и для GTK3

можно

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

Язык Си - отличный для описания каких-то железо-зависимых вещей. ABI есть только на Си. Транслировать можно в Си (хотя где-то в соседнем треде уже обижались, что из Си ассемблер так себе, из-за goto, например).

Но предлагать писать прикладнуху на Си _человеку_ в наше время звучит как-то подозрительно. Для 1972ого года Си был шикарной штукой. Для 1995ого года отличной штукой была Java. Но сейчас 2013, всё, поезд уехал. Хватит доставать трупы из морозильника.

Отдельная шутка про С++, который вообще ни для чего не пригоден: ни для системного программирования, ни для прикладного, ни для ынтерпрайза, ни для науки, только для игор (для них тоже не годится, но выбора нет) и для 3,5 хайлоад-гиперкластеров, которые к вопросу выбора гуя относятся чуть менее чем никак, и которых наверняка никто из участников этого треда не видел и не увидит.

Какие проблемы сейчас решает написатор гуя?
Из того что сразу пришло в голову:
- Быстрое прототипирование графики («рисование формочек»)
- Быстрое прототипирование функциональности (заглушки, тесты, документация для заказчика или opensource community)
- Поддержка автоматических тулзов и IDE
- Поддержка интеропа с другими языками и технологиями (разнотипными: ruby - бинарно, html - логически)

-- Что требует удобной интроспекции как минимум
-- А по-хорошему еще и возможности подстаривать синтаксис под задачу, со всеми плюшками типа обратной совместимости

- Возможность править работающий (собранный, развернутый) гуй как с целью отладки/прототипирования, так и в продакшене
- Возможность внешнего (по отношению к собранному/оптимизированному коду) расширения и настройки

-- Что требует управляемой динамики на разных уровнях. slang - это не смешно.

- Система событий, актеров, «система гуевых типов» (правильно настроенные дефолты множественного наследования, например)
- Асинхронный, многопоточный и неблокирующий вызов обработчиков событий (без необходимости разбираться как в точности это работает - это дело рантайма, сделать чтобы всё работало)

-- Которые для нормальной работы требуют прямой поддержки в языке, виртуальной машине и рантайме
-- Ну async await из C# хотя бы

- Быстрое время сборки/компиляции и интеграции/деплоймента
-- С++ с его шаблонами в пролете. Как с этим у Vala?

- Система высокоуровневой диагностики ошибок
-- в C89 исключений нету, а в C++ любой версии ими невозможно пользоваться, какая уж тут диагностика

- Возможность прозрачно перекладывать логику на кластеры/облака/your_bazzword_here
- Если логика сервер-сайд - гарантия что это не положит сервер
- Если логика сервер-сайд или распределенная - гарантия корректности, корректности всяких map/reduce, безопасности и что логика не положит ноды -- Что кроме непосредственной поддержки рантаймом требует специальной инфраструктуры, deployment targets

===

Какие из этих вопросов решает Си? Да никаких не решает. Оно на другом уровне абстракции работает, и разрыв между уровнями абстракции - бесконечность.

Си-для-машин - это круто.
Си-для-людей - это криокамера.
Хватит насиловать труп!

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

ну нихренасе у вас написаторы гуя. и не жалко вам пользователей этого гуя?

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

XULrunner/Firefox/Chromium/QtWebKit + из одного мира: JVM:Java/Scala/Clojure (если совсем всё плохо - то Erlang), из другого мира: C#,F# (про mono впечатления исключительно на хэлловорлдах и правке багов, пусть лучше кто-нибудь в теме типа mono поделится)

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

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

Говорить о смерти си и с++ очень преждевременно.

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

XULrunner/Firefox/Chromium

Монстры, которые умеют рисовать гуй после ХЗ какого апгрейда над рендерилкой текстовых страничек. При попытке дрилить что-то свое приходится юзать тот самы «некро» АПИ.

QtWebKit

Ты же вроде против Qt?

JVM:Java/Scala/Clojure

А библиотеки гуевые какие?

из другого мира: C#,F#

Ты сам все сказал про другой мир.

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

При попытке дрилить что-то свое приходится юзать тот самы «некро» АПИ.

поделись историей успеха, что же ты там ковырял в некро-апи хромиума чтобы нарисовать гуй?

Ты же вроде против Qt?

я против того, чтобы технологии для программирования железок смешивались с абстрактной бизнес-логикой. Как связан гуй (формочка, кнопочки, бизнес-логика) с RAII в крестовом исполнении? Ну кроме обычной отмазки про священные крестопроблемы, из которых может следовать всё что угодно.

А библиотеки гуевые какие?

В технологиях типа Clojure решено столько проблем, что никаких библиотек не надо. Оно by design такое, незачем прикручивать библиотеками костыли, оно само ходить умеет.

Чтобы рендерить непосредственно виджеты - юзай что хочешь на JS/Coffescript. Dojo/Dijit, jQuery/jQueryUI, ExtJS. Это настолько просто, что и «библиотек»-то никаких особо не надо. Ну, видео ты JSом вряд ли отрендеришь, но видео есть в самой низкоуровневой платформе (HTML5, Flash). Если совсем извращенец, тут кто-то рекламировал asm.js, оно и без native client (которого еще нет) кое-что умеет. Мое самое первое тестовое задание на первой «настоящей» работе было написать новый виджет для Dojo - и как оказалось, это действительно может сделать человек, ну совсем ничерта не смыслящий ни в чем, за несколько дней. А чтобы похачить Qt так, чтобы это не привело к каким-то инфернальным последствиям, кажется, нужно удаляться в горы на 5 лет, начиная с чтения Страуструпа, Саттера, продолжая «дизайном и эволюцией Qt» (кажется, такой книжки еще нет) и заканчивая... да хз чем заканчивая, я до этого момента не дотерпел :3

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

LXDE слились с Razor-Qt лишь из-за чуть большего потребления ресурсов у Gtk3 по сравнению с Qt5

Ты походу не читал, что они писали по этому поводу.

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

Плюсую этого товарища. ТС, новости погляди - люди уходят с Gtk. Да, Gtk был крут, но Qt хорошо развивается, перетягивая одеяло на себя.

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

поделись историей успеха, что же ты там ковырял в некро-апи хромиума чтобы нарисовать гуй?

Я ничего не ковырял, это мне как то на ЛОРе советовали.

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

Я про железки и логику нечего не спрашивал. Но насчет разделение лучше соглашусь.

видео есть в самой низкоуровневой платформе (HTML5, Flash)

Вот я не знаю, после слова Flash мне плкать или смеятся?

А чем QML не угодил?

AF ★★★
()
Последнее исправление: AF (всего исправлений: 1)
Ответ на: комментарий от KendovNorok

Ага, если GTK выглядят по уродски, то про Qt даже слово чтобы выразить весь ужас внешнего вида подобрать сложно.

Polugnom ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 →
Development