LINUX.ORG.RU

Какие тулкиты установлены у вас в системе?

 , , , ,


0

1

Сейчас это особенно актуальный вопрос для всех тулкитофобов — GNOME в стандартной поставке всё ещё требует GTK+2, Firefox переходит на GTK+3, а GIMP как-то не спешит переходить, некоторые программы переносят с Qt4 на Qt5, но многие до сих пор остаются на Qt4.
Давайте узнаем статистику, какие версии каких популярных тулкитов установлены у пользователей LOR.

  1. gtk2, gtk3, qt4, qt5664 (49%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. gtk2, gtk3, qt4197 (15%)

    **********************************************************************************************

  3. Только gtk2 и gtk3108 (8%)

    ****************************************************

  4. Только qt553 (4%)

    *************************

  5. gtk3, qt4, qt548 (4%)

    ***********************

  6. gtk2, gtk3, qt546 (3%)

    **********************

  7. gtk2 и qt436 (3%)

    *****************

  8. gtk3 и qt536 (3%)

    *****************

  9. Только gtk233 (2%)

    ***************

  10. Только gtk333 (2%)

    ***************

  11. Только qt4 и qt532 (2%)

    ***************

  12. gtk3 и qt426 (2%)

    ************

  13. gtk2, qt4, qt523 (2%)

    ***********

  14. Только qt413 (1%)

    ******

  15. gtk2 и qt57 (1%)

    ***

Всего голосов: 1355

★★★★★

Проверено: Licwin ()

У меня GTK+2 (нужен для Firefox, GIMP, KiCAD) и GTK+3 (для всего остального).

CYB3R ★★★★★ ()

Почему опрос сделан не через мультивыбор? И где всякие tk и прочее?

// Тулкитофобией не страдаю.

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

Умышленно сделал только один вариант ответа, потому что мультивыбор не даст понять различные комбинации. Я выбрал только самые популярные тулкиты.

Тулкитофобией не страдаю

gtk2, gtk3, qt4, qt5?

CYB3R ★★★★★ ()
Ответ на: комментарий от CYB3R
->  ~  % pacman -Q gtk2     
gtk2 2.24.28-1
->  ~  % pacman -Q gtk3
gtk3 3.18.2-1
->  ~  % pacman -Q qt4      
qt4 4.8.7-2
->  ~  % pacman -Q qt5-base 
qt5-base 5.5.1-1
Klymedy ★★★★★ ()

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

dogbert ★★★★★ ()

Использую в основном gtk2 и gtk3. На Qt4 разве что VLC. Пятый Qt пока нигде не потребовался.

Bbore ()

gtk2, gtk3, qt4, qt5

Тулкитофобией не страдаю. Какие нужны, такие и стоят. GTK2 и GTK3 — без них вообще никуда, Qt4 нужен для Hedgewars, Qt5 нужен для OpenShot и PokerTH. Видимо, если Hedgewars переедет на Qt5, то Qt4 удалю.

upd: ой, нет, ещё Qt4 требуется для sdlmame и instead-launcher. Так что не удалю.

Psych218 ★★★★★ ()
Последнее исправление: Psych218 (всего исправлений: 2)

Где пункт «Мне пофиг, лишь бы работало»?

Zhbert ★★★★★ ()

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

mbivanyuk ★★★★★ ()

А опрос бедноват

Где qt3???
Где gtk1?????
Где win32/gdi?????????

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

В том, что тулкиты не ограничены только гтк и кьютом. Например, я пользуюсь только консольными приложениями или парой прог в голых иксах на tcl/tk. И при этом мне пох, на чем они там работают.

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

gtk нет вообще

Ну-ну. Это Qt может не быть, а GTK+ есть по дефолту в любом десктопном дистре. Да и сам Qt зависит от GNOME'овских либ в стандартной поставке:

$ ldd /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 | grep glib
        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fdad9e4f000)

Потому что GTK+/Gnome ынтрайпрайзный стандарт и культи под него подстраиваются.

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

может, это проблема дистра?
Я не думаю, что qt5 требует glib на других платформах.
И скорее всего это просто поддержка каких-нибудь фич и она опциональна при сборке.

mittorn ★★★★★ ()

qt5/qt4. Но некоторые фуфлыжные программы тянут говнотык, поэтому пока избавиться от него окончательно невозможно.

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

Зависимость Qt 5 от GNOME'овской glib присутствует не только в пакетах собранных мейнтейнерами для определённого дистрибутива, но и в официальном пакете, распространяемым на qt.io/download

Оно, конечно, может быть отключено, но тогда Qt 5 начинает неадекватно вести себя в системе: отпадают QGtkStyle темы, перестаёт работать половина плагинов, Qt без GLib не сможет в воспроизведение видео или аудио, отпадут QtMultimedia/QtMultimedia Widgets и т. д..

Но фанатики даже не подозревают, что любое их Qt 5 приложение в MainLoop дергает GMainContext из гномовской glib.

EXL ★★★★★ ()

А вообще хороший опрос. Подобные опросы — небольшой шаг к однозначности и к единому тулкиту и DE в десктопном Linux.

А единый тулкит, даже если это будет GTK+, крайне важен и нужен. Чтобы у разработчиков не возникало вопросов, на чём писать приложения.

То, что сейчас есть, это вообще жесть, похлеще чем разноляпистые приложения в винде (к слову, эта мода прошла, сейчас стараются делать всё нативненько).

Мы же имеем кучу хреново работающих DE, кучу разных тулкитов разной степени упоротости, говномимикрию одних тулкитов под другие и, в следствии этого безобразия — 0.91% на десктопах.

Нужна сильная компания, которая бы продвигала только один тулкит и одно DE, а остальные гнобила и закапывала всеми возможными и невозможными способами. В принципе, RedHat с их GNOME и GTK+, может стать такой компанией. Нельзя, например, не поддержать решение разработчиков GTK+ сломать совместимость с KDE-темами в одностороннем порядке и отказ KDE-разработчикам в интеграции их наработок в движок тем GTK+ (GTK-приложения больше не смогут мимикрировать в KDE), что может вызвать уход пользователей с KDE в пользу DE, основанных на GTK+. Эта доктрина «интерфейсного фашизма» GTK+ — основополагающая популярности десктопного Linux.

Если у RedHat с таким агрессивным подходом получится продвинуть эту концепцию, загнобив и депрекейтнув все остальные DE и тулкиты, то мы сможем получить сбалансированный дистрибутив десктопного Linux, который будет приятен в использовании как домохозяйкам и обычным пользователям, так и программистам, системным администраторам и др. IT-специалистам. Навсегда пропадёт дурацкая мимикрия и извечный вопрос разработчиков «на каком стеке технологий мне писать приложение»? Мы получим что-то вроде системы стройных и удобных фреймворков, как в OS X.

Популярность десктопного Linux с доктриной «интерфейсного фашизма» значительно повысится.

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

Верно. В винде большинство использует winapi для win32 и стандарнный winforms для .NET и таких проблем просто нет.
Я задумывался над этим вопросом и пришла идея:
Сделать простой тулкит, по возможностям напоминающий user.dll или fltk и систему бэкендов для API.
Система бекендов постепенно бы дополнялась реализациями API того или иного тулкита и в скором времени могла бы запускать 90% простеньких программ всех тулкитов.
Для сложных же проектов обычно есть встроенные бэкенды - там проще будет добавить, к примеру, поддержку этого тулкита в firefox.
Определённую сложность в этом плане представляет связь кравического тулкита с остальными библиотеками (попробуй оторвать qt от qtgui например)
Это бы улучшило хотя бы внешнее восприятие ситуации.

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

А как связаны glib и gtk?

Таки Qt5, Qt4, Gtk2. Жду когда Qt4 можно будет выкинуть.

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

А как связаны glib и gtk?

Точно так же, как связаны Qt и glib. Одно зависит от другого. Или ты о чём-то другом? Qt не зависит от GTK+, но зависит от GNOME Lib (glib).

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

Ну, представь, что GTK+ зависел бы от kdelibs.

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

А что не так в этой зависимости?

Тут вопрос в другом. На кой хрен весь такой из себя модульный и самодостаточный Qt 5 тянет в себя вообще все системные библиотеки, аки пылесос? Тем более из конфронтационного проекта GNOME, разработчики которого «троллят» тех же KDE'шников, ломая им совместимость в их темах?

Тут недавно некоторые в шоке были, когда узнали, что в Qt 5 даже простенькое приложение-кнопка теперь, внезапно, зависит от OpenGL: qt 5.3 и qt 5.5 (комментарий)

А 30МБ-ый ICU зависимостью в QtCore зачем они прилепили?

$ cat qt.pro
TEMPLATE = app
QT += widgets
SOURCES += qt.cpp

$ cat qt.cpp
#include <QApplication>
#include <QLabel>
int main(int argc, char** argv) {
    QApplication app(argc, argv);
    QLabel lbl("Hello, World !");
    lbl.show(); app.exec();
}

$ qmake-qt5 && make
g++ -c -m64 -pipe -O2 -Wall -W -D_REENTRANT -fPIE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -o qt.o qt.cpp
g++ -m64 -Wl,-O1 -o qt qt.o   -L/usr/X11R6/lib64 -lQt5Widgets -lQt5Gui -lQt5Core -lGL -lpthread 

$ ldd qt | grep icu
        libicui18n.so.52 => /usr/lib/x86_64-linux-gnu/libicui18n.so.52 (0x00007f1034080000)
        libicuuc.so.52 => /usr/lib/x86_64-linux-gnu/libicuuc.so.52 (0x00007f1033d02000)
        libicudata.so.52 => /usr/lib/x86_64-linux-gnu/libicudata.so.52 (0x00007f10312d8000)

$ du -h /usr/lib/x86_64-linux-gnu/libicu[i,u,d][1,c,a]*.so.*.*
23M     /usr/lib/x86_64-linux-gnu/libicudata.so.52.1
2,1M    /usr/lib/x86_64-linux-gnu/libicui18n.so.52.1
1,5M    /usr/lib/x86_64-linux-gnu/libicuuc.so.52.1

$ make distclean && qmake-qt4 && make
rm -f qt.o
rm -f *~ core *.core
rm -f qt 
rm -f Makefile
g++ -c -m64 -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -o qt.o qt.cpp
g++ -m64 -Wl,-O1 -o qt qt.o    -L/usr/lib/x86_64-linux-gnu -lQtGui -lQtCore -lpthread 

$ ldd qt | grep icu
<empty>

$

А потом жалуются, почему Qt 5 приложения так долго запускаются, лол.

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

Почему опрос сделан не через мультивыбор?

Удваиваю.

И где всякие tk и прочее?

Дискриминация, однако.

r3lgar ★★★★★ ()

Коктейль из всех этих, и может что-то ещё забыл.

Dmitry_Sokolowsky ★★★★★ ()

Срочно нужен пункт «мне пофиг».

Aceler ★★★★★ ()

стоит равно всё, что нужно, а нужны все 4 тулкита

f1u77y ★★★ ()

У меня GTK2 для всего, единственное приложение на GTK3 — pavucontrol.
А на нетбуке примерно поровну GTK2 и 3, хотя, скорее всего GTK3 больше.

sudopacman ★★★★★ ()
Последнее исправление: sudopacman (всего исправлений: 1)

С великим удовольствием выкинул бы gtk2 и qt4, однако первый нужен годному диаграммеру - dia, а второй требуется для anki.

Так что установленны все 4.

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

Популярность десктопного Linux с доктриной «интерфейсного фашизма» значительно повысится.

Так, будто это что-то хорошее.

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

Скорей бы gtk2 и qt4 туда же отправились бы. Жуткое наследие менее цивилизованных времён.

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

Привет тебе, некрофил, от нас - живодёров :)

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

GTK2 вполне себе юзабельно, а главное для него темы делать проще.

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

GTK2 вполне себе юзабельно

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

а главное для него темы делать проще

Эммм.. С каких пор двигло стало писать проще, чем css?

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

Не может быть юзабельным нечто заставляющее проц заниматься отрисовкой интерфейсов и прочего стафа

Вообще разницы в использовании GTK2 и 3 не заметил.

css

Он как раз таки в GTK2, а в GTK3 какая-то непонятная фиговина.

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