qt приложения в гномощели

В сторону export QT_STYLE_OVERRIDE=gtk

Дело в том, что аналог Лёни в The Qt Company сказал, что qt-config больше не нужен и в официальной поставке с Qt 5 его не будет.

Потому Qt 5 приложения и не могут нормально определить тему в GTK+ окружениях. А твой qBittorent 3.3.1, как раз на Qt 5, а не Qt 4.

Короче, Qt-девелоперы сломали в Qt 5 настройку внешнего вида.

Есть костыль qt5ct, поищи его по ЛОРу.

Спасибо, заработало. Правда по сравнению с qt4-версией все равно как-то коряво выглядит, придется опять пердолингом заниматься.

Ну да, Qt 5 на порядок глючнее, медленнее, вырвиглазнее и раздутее Qt 4 и до сих пор не готов для серьёзного продакшена.

Если не ошибаюсь, то в qBittorent оставил поддержку Qt 4 в проекте, и можно попробовать собрать его версию, работающую на Qt 4.

Зачет, попробую.

Шта? А как же platformthemes? У меня Qt5 проги в убунте выглядят очень даже нативно.

Qt 5 на порядок глючнее

Нет.

вырвиглазнее

Только в гноме. Как и GTK+ в кедах.

и раздутее Qt 4

Нет.

и до сих пор не готов для серьёзного продакшена.

Qt4 мёртв. Qt5 в продакшене.

А вообще, куда бежать? gtk3 тоже не радует.

На macOS разве что. В GNU/Linux постоянный разброд и шатание в плане графических тулкитов и ситуация постоянно только усугубляется.

Qt 5 на порядок глючнее

Нет.

Очень аргументированно. Шрифты когда пофиксили? Только год назад где-то. Сколько лет приложения на Qt 5 сверкали блёклыми шрифтами? Года три.

А сколько фиксят «горячие клавиши» в кириллической раскладке? До сих пор не пофиксили.

вырвиглазнее

Только в гноме. Как и GTK+ в кедах.

Смотри-ка, Qt 4 в GNOME смотрится нормально без всяких новомодных platformthemes, а Qt 5 ИТТ обкакунькался. А виноват почему-то GNOME.

и раздутее Qt 4

Нет.

А я вот не только отрицаниями могу кидаться, но и аргументами:

1. Абсолютно все Qt 5 приложения почему-то зависят от OpenGL: qt 5.3 и qt 5.5 (комментарий)

2. Qt 4 приложения не тянут ICU на 30 МБ, а Qt 5 приложения тянут.

3. Простейшее Qt 4 приложение зависит от двух библиотек: QtGui и QtCore, приложение на Qt 5 — от четырёх: QtGui, QtWidgets, QtCore, и того плагина qxcb.so в platforms/, который лежит где-то в дебрях /usr. В общем случае двукнопочное Qt 4 приложение весит 9МБ, а Qt 5 — 19 МБ (если без ICU).

И у тебя ещё хватает смелости утверждать, что Qt 5 не жирнее? Да оно даже запускается в три раза медленнее, пока все эти библиотеки ICU и OpenGL в память развернутся.

Очень аргументированно.

Кто-бы говорил. Шрифты пофиксили уже 100 лет назад.

Смотри-ка, Qt в KDE смотрится нормально без всяких новомодных platformthemes, а GTK+ ИТТ обкакунькался. А виноват почему-то KDE.

fixed

1. Абсолютно все Qt 5 приложения почему-то зависят от OpenGL:

% ldd ./myapp | grep Qt5 
        libQt5Widgets.so.5 => /usr/lib64/libQt5Widgets.so.5 (0x00007f255fb97000)
        libQt5Gui.so.5 => /usr/lib64/libQt5Gui.so.5 (0x00007f255f69a000)
        libQt5Core.so.5 => /usr/lib64/libQt5Core.so.5 (0x00007f255f20e000)

2. Qt 4 приложения не тянут ICU на 30 МБ, а Qt 5 приложения тянут.

Только на винде, и то опционально. Qt4 c icu тоже можно собрать.

3. Простейшее Qt 4 приложение зависит от двух библиотек: QtGui и QtCore, приложение на Qt 5 — от четырёх: QtGui, QtWidgets, QtCore

Что за бред. QtWidget отпочковался от QtGui. Это не новая либа.

% du -h /usr/lib/libQt5Core.so.5.6.1
4.6M    /usr/lib/libQt5Core.so.5.6.1
% du -h /usr/lib/libQt5Gui.so.5.6.1
5.0M    /usr/lib/libQt5Gui.so.5.6.1
% du -h /usr/lib/libQt5Widgets.so.5.6.1
6.6M    /usr/lib/libQt5Widgets.so.5.6.1
% du -h /usr/lib/qt4/libQtCore.so.4.8.6 
3.0M    /usr/lib/qt4/libQtCore.so.4.8.6
% du -h /usr/lib/qt4/libQtGui.so.4.8.6
11M     /usr/lib/qt4/libQtGui.so.4.8.6

Да оно даже запускается в три раза медленнее

Без бенчей - балабол. icu используют почти все проги, а значит он уже в ОЗУ.

sudo dnf install qgnomeplatform

Сам не тыкал (нет у меня Qt5 приложений, которыми я прям так пользуюсь), но обещает исправить большинство проблем.

На крайняк есть adwaita-qt5.

1. Абсолютно все Qt 5 приложения почему-то зависят от OpenGL:

Зависит то сам Qt, а не приложение написанное на Qt.

% ldd ./myapp | grep Qt5

А теперь выхлоп с грепом «GL» давай.
И вперёд пересобирать Qt 5 с -disable opengl

Только на винде, и то опционально.

Во всех популярных дистрибутивах.

Итого: Qt4 - 14.0M, Qt5 - 16.2M.

А где платформс-плагины? А поддержки форматов изображений? Попробуй переименуй /usr/lib/qt/plugins/platforms/libqxcb.so во что-нибудь другое и все твои Qt 5 приложения превратятся в тыкву.

Без бенчей - балабол. icu используют почти все проги, а значит он уже в ОЗУ.

Аксиомы не требуют доказательств. Если для тебя программа, использующая:

$ ldd untitled 
        linux-vdso.so.1 (0x00007ffc75934000)
        libQt5Widgets.so.5 => /usr/lib/libQt5Widgets.so.5 (0x00007f734025e000)
        libQt5Core.so.5 => /usr/lib/libQt5Core.so.5 (0x00007f733fd89000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f733fa07000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f733f7f1000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f733f44d000)
        libQt5Gui.so.5 => /usr/lib/libQt5Gui.so.5 (0x00007f733ef04000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f733ece7000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f733ea95000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f733e787000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f733e445000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f733e147000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f733df31000)
        libicui18n.so.56 => /usr/lib/libicui18n.so.56 (0x00007f733dab5000)
        libicuuc.so.56 => /usr/lib/libicuuc.so.56 (0x00007f733d71e000)
        libpcre16.so.0 => /usr/lib/libpcre16.so.0 (0x00007f733d4b8000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f733d2b4000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007f733d0ac000)
        libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x00007f7340a4d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f73408ed000)
        libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007f733ce77000)
        libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x00007f733cc12000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f733c979000)
        libffi.so.6 => /usr/lib/libffi.so.6 (0x00007f733c770000)
        libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f733c500000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f733c2dd000)
        libicudata.so.56 => /usr/lib/libicudata.so.56 (0x00007f733a8fa000)
        libcap.so.2 => /usr/lib/libcap.so.2 (0x00007f733a6f6000)
        libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007f733a4df000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f733a2b9000)
        liblz4.so.1 => /usr/lib/liblz4.so.1 (0x00007f733a0a7000)
        libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x00007f7339dc5000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00007f7339bb1000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f73398e9000)
        libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x00007f73396be000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f7339494000)
        libxcb-dri3.so.0 => /usr/lib/libxcb-dri3.so.0 (0x00007f7339291000)
        libxcb-present.so.0 => /usr/lib/libxcb-present.so.0 (0x00007f733908e000)
        libxcb-randr.so.0 => /usr/lib/libxcb-randr.so.0 (0x00007f7338e80000)
        libxcb-xfixes.so.0 => /usr/lib/libxcb-xfixes.so.0 (0x00007f7338c78000)
        libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x00007f7338a6e000)
        libxcb-shape.so.0 => /usr/lib/libxcb-shape.so.0 (0x00007f733886a000)
        libxcb-sync.so.1 => /usr/lib/libxcb-sync.so.1 (0x00007f7338663000)
        libxshmfence.so.1 => /usr/lib/libxshmfence.so.1 (0x00007f7338460000)
        libglapi.so.0 => /usr/lib/libglapi.so.0 (0x00007f7338232000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f7338020000)
        libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007f7337e1d000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f7337c17000)
        libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0x00007f7337a15000)
        libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0x00007f73377fb000)
        libxcb-dri2.so.0 => /usr/lib/libxcb-dri2.so.0 (0x00007f73375f6000)
        libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00007f73373f0000)
        libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007f73371e1000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f7336fdd000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f7336dd7000)
        libattr.so.1 => /usr/lib/libattr.so.1 (0x00007f7336bd2000)
        libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007f73369c2000)

И это ещё без всяких не очевидных DLOPEN-зависимостей, вроде того же (platforms/libqxcb.so). Разворачивается в память так же быстро, как:

$ ldd untitled 
        linux-vdso.so.1 (0x00007fff6a75f000)
        libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0x00007fa35ea75000)
        libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0x00007fa35e56d000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa35e1eb000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fa35dfd5000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fa35dc31000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fa35da14000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007fa35d706000)
        libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007fa35d4d1000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007fa35d2bb000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007fa35cff3000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007fa35cda1000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0x00007fa35cb99000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0x00007fa35c97c000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007fa35c772000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007fa35c52e000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fa35c31c000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fa35bfda000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007fa35bcdc000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fa35bad8000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007fa35b8d0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa35f7ae000)
        libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007fa35b660000)
        libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007fa35b450000)
        libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x00007fa35b1eb000)
        libffi.so.6 => /usr/lib/libffi.so.6 (0x00007fa35afe2000)
        libuuid.so.1 => /usr/lib/libuuid.so.1 (0x00007fa35addd000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007fa35abb3000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fa35a990000)
        libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x00007fa35a765000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fa35a561000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fa35a35b000)

То либо ты болен заболеванием, из-за которого не можешь признать свою неправоту, либо просто фанатик.

fixed

Ни слова про KDE я не говорил. Зачем ты его вообще сюда притянул, одному Лёне известно.

И в каждой теме про Qt или KDE этот психованый хейтер-затычка.

В GNU/Linux постоянный разброд и шатание в плане графических тулкитов и ситуация постоянно только усугубляется.

В винду давно заглядывал, умник?

И в каждой теме про Qt или KDE этот психованый хейтер-затычка.

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

В винду давно заглядывал, умник?

А причём тут винда? Или если там разброд и шатание, то и в GNU/Linux оно тоже должно быть?

А теперь выхлоп с грепом «GL» давай.

Дык это libqxcb тянет GL для создания окон. Само приложение с GL, напрямую не линкуется. Но если мы о любых зависимостях - то ок, соглашусь.

Во всех популярных дистрибутивах.

И? Во всех популярных дистрибутивах и так icu из коробки. Какие проблемы?

А где платформс-плагины?

% du -h /usr/lib/qt4/plugins           
2.4M    /usr/lib/qt4/plugins

Для Qt5 сложнее посчитать, так как всё забито KDE плагинами.

% cd /usr/lib/qt5/plugins/
% du -ch audio bearer designer iconengines imageformats mediaservice platforminputcontexts platforms platformthemes playlistformats qmltooling qtwebengine sqldrivers xcbglintegrations 
72K     audio
84K     bearer
196K    designer
44K     iconengines
640K    imageformats
680K    mediaservice
52K     platforminputcontexts
708K    platforms
204K    platformthemes
28K     playlistformats
564K    qmltooling
1.4M    qtwebengine
64K     sqldrivers
76K     xcbglintegrations
4.7M    total

Аксиомы не требуют доказательств. Если для тебя программа, использующая:

И что это должно доказать? То что прога на Qt линкуется с кучей либ и поэтому долго стартует? Ну ок, вот «Hello World» на GTK+3:

gtktest % du -h example
16K     example
gtktest % ldd ./example
        linux-vdso.so.1 (0x00007fff53545000)
        libgtk-3.so.0 => /usr/lib64/libgtk-3.so.0 (0x00007fc9fb079000)
        libgdk-3.so.0 => /usr/lib64/libgdk-3.so.0 (0x00007fc9fb8fa000)
        libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007fc9fb8ec000)
        libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007fc9fb8a1000)
        libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00007fc9fb87a000)
        libcairo-gobject.so.2 => /usr/lib64/libcairo-gobject.so.2 (0x00007fc9fb870000)
        libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007fc9faf79000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007fc9fb84e000)
        libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007fc9fadf5000)
        libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007fc9fb7fa000)
        libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fc9facbb000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc9faa9f000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fc9fa703000)
        libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007fc9fb7f5000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fc9fa3c1000)
        libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007fc9fa1b1000)
        libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007fc9f9fab000)
        libatk-bridge-2.0.so.0 => /usr/lib64/libatk-bridge-2.0.so.0 (0x00007fc9f9f7b000)
        libepoxy.so.0 => /usr/lib64/libepoxy.so.0 (0x00007fc9f9e86000)
        libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00007fc9fb7de000)
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fc9f9e48000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fc9f9b51000)
        libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007fc9f9946000)
        libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007fc9fb7d1000)
        libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x00007fc9f9943000)
        libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007fc9f9740000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fc9f952e000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fc9f9264000)
        libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x00007fc9f8fbf000)
        libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007fc9f8f8d000)
        libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007fc9f8d83000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fc9f8b6c000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fc9f8964000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fc9f874d000)
        libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007fc9f8744000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc9fb7ad000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fc9f8540000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fc9f831c000)
        libatspi.so.0 => /usr/lib64/libatspi.so.0 (0x00007fc9f82eb000)
        libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007fc9f82a5000)
        libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 (0x00007fc9f8222000)
        libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007fc9f7ff8000)
        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fc9f7fe6000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fc9f7de2000)
        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fc9f7bdb000)
        libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 (0x00007fc9f79ad000)

То либо ты болен заболеванием, из-за которого не можешь признать свою неправоту, либо просто фанатик.

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

У меня хотя бы нет проблем с юношеским максимализмом.

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

Научись понимать разницу между критикой и 4.2

А причём тут винда? Или если там разброд и шатание, то и в GNU/Linux оно тоже должно быть?

По сравнению с тем, что творится в винде - в GNU/Linux чистота и строгий порядок. Но никто же не бежит от Винды, пишут под неё софт, жуют кактус. А тут всего 2 популярных тулкита - и сразу разброд и шатание. При чём кроссплатформенных тулкита, а не завендорлоченная Cocoa. То что в GTK постоянно ломают API тем и совместимость с Qt - это ничего, но стоило немного поломать оформление Qt5-софта в GTK 3 - как у свидетелей Гнома бомбануло.

Дык это libqxcb тянет GL для создания окон.

И опять у тебя неверная информация. Посмотри:

ldd /usr/lib/libQt5Gui.so.5.5.1 | grep GL

И тянет он GL вовсе не для создания окна. Ведь в Qt 4, GTK+3 и GTK+2 окно создаётся без всякой OpenGL'овской мишуры. Тянет он OpenGL приблизительно для этого: https://habrahabr.ru/post/272423/

И мы ещё забыли о нескольких библиотеках, от которых зависит ЛЮБОЕ приложение на Qt 5. Я про libQt5XcbQpa.so.5 и его зависимость libQt5DBus.so.5 как раз от этого самого плагина platforms/libqxcb.so :)

В два раза больше?

Да. Если использовать статическую линковку, то приложение на Qt 4 получается в два раза меньше, чем на Qt 5. Это, конечно, если не брать во внимание 30 МБ от ICU.

Ура! GTK+ прекрасен, ибо зависимостей от GL нет, значит всё ок.

Заметь, зависимости от ICU там тоже нет и при этом локализация нормально работает.

То что прога на Qt линкуется с кучей либ и поэтому долго стартует?

То что Qt 5 прога стартует дольше из-за большего количества зависимостей:

ldd untitled-qt5 > /tmp/dependencies.txt
ldd /usr/lib/qt/plugins/platforms/libqxcb.so >> /tmp/dependencies.txt
cat /tmp/dependencies.txt | sort -u | uniq -w 20 | wc -l
74

ldd untitled-qt4 | wc -l
32

В этом треде мне пишут 4.2, а я опровергаю аргументами. А ты почему-то считаешь, что наоборот.

Очевидно, потому что розовые очки фанатика защищают тебя от здравого и трезвого взгляда на вещи. Надеюсь, хоть ты не будешь спорить о том, что Qt 5 более раздут в зависимостях в сравнении с Qt 4.

То что в GTK постоянно ломают API тем и совместимость с Qt - это ничего, но стоило немного поломать оформление Qt5-софта в GTK 3 - как у свидетелей Гнома бомбануло.

Ну вот видишь, получилось так, что оба тулкита ломают темы. А это плохо сказывается на юзабилити десктопного GNU/Linux, не так ли?

Если использовать статическую линковку

Латентный проприетарщик, штоле?

Скорее ленивый и юный максималист.

Лень мучаться со сборкой всяких ebuild, deb, pkgbuild, rpm и иже с ними.

К счастью сейчас есть AppImage и FlatPack.

Дело в том, что аналог Лёни в The Qt Company сказал, что qt-config больше не нужен и в официальной поставке с Qt 5 его не будет.

Назови более прямой путь? Вот хочу я в KDE иметь тему breeze, а в Gnome тему GTK+, расскажи как сделать правильно.

Очевидно, потому что розовые очки фанатика защищают тебя от здравого и трезвого взгляда на вещи. Надеюсь, хоть ты не будешь спорить о том, что Qt 5 более раздут в зависимостях в сравнении с Qt 4.

Не вижу в нём ничего раздутого. Кроме твоих ничем не обоснованных высеров.

А это плохо сказывается на юзабилити десктопного GNU/Linux, не так ли?

Не так ли. Я пользуюсь программами а не фапаю на их интерфейс или то, как отображается Qt-софт в GTK-окружениях. И наоборот.

Лень мучаться со сборкой всяких ebuild, deb, pkgbuild, rpm и иже с ними.

К счастью сейчас есть AppImage и FlatPack.

И этот человек будет мне что-то говорить про раздутость и большой размер программы?

Я про libQt5XcbQpa.so.5 и его зависимость libQt5DBus.so.5 как раз от этого самого плагина platforms/libqxcb.so

Конечно. Абстракции не нужны, иксы будут жить вечно. Да и поддержка платформ тоже никому не нужна - свет сошёлся клином на x11 и венде.

А вот то, что поддержка Wayland для галочки - нет нормальной кастомизации CSD (ни через переменные окружения, ни через конфиг-файл, ни как ещё нельзя заставить эти омерзительные синие рамки окошек выглядеть не так омерзительно) прискорбно.

Также если возжелать унифицированный look&feel для всей системы, то очень огорчает отсутствие плагина-платформы для рендеринга гуёв через gtk3.

Qt Creator в Wayland нормально работает только на третьегноме (на weston и большинстве других композиторов не работает автодополнение, в sway неадекватные вспомогательные окна). Приплыли. Гном и Qt - теперь лучшие друзья.

Также если возжелать унифицированный look&feel для всей системы, то очень огорчает отсутствие плагина-платформы для рендеринга гуёв через gtk3.

Он уже в разработке.

А это плохо сказывается на юзабилити десктопного GNU/Linux, не так ли?

То есть гнилой графический стек урезающий производительность рендеринга, ограничивающий поддержку железа (привет, multi-gpu) и заросший костылями - это норм. К чертям инфраструктуру - даёшь красивые кнопочки уже вчера!

Уррррраааааа!

И этот человек будет мне что-то говорить про раздутость и большой размер программы?

Ну так от зависимостей отказались - всё своё ношу с собой. При таком подходе Qt 5 очень даже жирный ;)

Только 2 пользователя с разными конфигами, только хардкор.

Ведь в Qt 4, GTK+3 и GTK+2 окно создаётся без всякой OpenGL'овской мишуры.

Ок. Хорошо. Qt5 использует GL. В чём проблема? На что это влияет? На одну строку в ldd?

Простая проверка показывает, что этот самый GL дёргается только из QXcbWindow::create(). Всё. Это настолько страшно? Какие реальный проблемы это вызывает?

Я про libQt5XcbQpa.so.5 и его зависимость libQt5DBus.so.5 как раз от этого самого плагина platforms/libqxcb.so
ЛЮБОЕ приложение на Qt 5 под Linux.

Fixed

И? Ну использует приложение DBus. GTK+ тоже использует. Как минимум для трея и глобального меню нужен dbus, без него никак. Вот и зависимости.

% du -h /usr/lib/libQt5XcbQpa.so.5.6.1  
972K    /usr/lib/libQt5XcbQpa.so.5.6.1
% du -h /usr/lib/libQt5DBus.so.5.6.1 
524K    /usr/lib/libQt5DBus.so.5.6.1

Полтора метра абстракций, какой ужас.

Заметь, зависимости от ICU там тоже нет и при этом локализация нормально работает.

И? Qt тоже можно собрать без icu и он тоже будет прекрасно работать.

А icu всё равно придётся использовать для маломальской работы с текcтом:

% ldd /usr/bin/inkscape | grep icu
        libicuuc.so.57 => /usr/lib64/libicuuc.so.57 (0x00007f4e273f6000)
        libicudata.so.57 => /usr/lib64/libicudata.so.57 (0x00007f4e24cd3000)

То что Qt 5 прога стартует дольше из-за большего количества зависимостей:

Вы это вычислили по количеству либ? Замечательно. А я вот запустил valgrind, и посмотрел, что в проге с пустым QMainWindow _dl_runtime_resolve занимает 2.75% времени/инструкций. Сомневаюсь, что это катастрофически влияет за время запуска.

macos

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

А как ты делал это в Qt 4?

Не вижу в нём ничего раздутого. Кроме твоих ничем не обоснованных высеров.

Ну мои высеры вполне обоснованы выше. Размер бинаря увеличился? Увеличился. Размер всех подгружаемых библиотек увеличился? Увеличился в несколько раз. Появились либы, доступ к которым разрешается с помощью dlopen? — Появились. Деплой усложнился? Усложнился.

Любому адекватному человеку без фанатизма в голове понятно, что Qt 5 раздулся.

Я пользуюсь программами а не фапаю на их интерфейс или то, как отображается Qt-софт в GTK-окружениях.

И при этом плачешься насчёт поломанных тем в Firefox, который перешёл на GTK+3 и у которого внезапно сломался look-and-feel под KDE-окружениями.

А вот то, что поддержка Wayland для галочки - нет нормальной кастомизации CSD (ни через переменные окружения, ни через конфиг-файл, ни как ещё нельзя заставить эти омерзительные синие рамки окошек выглядеть не так омерзительно) прискорбно.

А всё почему? Потому что вместо доработки QtWayland параллельно пилится что? Правильно, KWayland!

То есть текущая ситуация с графическими тулкитами в GNU/Linux идеальна и тебе не хочется ничего изменить? (:

Простая проверка показывает, что этот самый GL дёргается только из QXcbWindow::create(). Всё. Это настолько страшно? Какие реальный проблемы это вызывает?

А почему дёргается это ускорение? Ведь на других тулкитах никакой GL не дёргается, поскольку не используется. А в Qt 5 он не используется (QtOpenGL и QtQuick-приложения отбрасываем, там используется) и всё равно дёргается. Если машинка будет без GPU, то чтобы запустить ЛЮБОЕ Qt 5 приложение, придётся возиться со всякими программными эмуляторами GL типа mesa->llvmpipe или пересобирать Qt 5.

Полтора метра абстракций, какой ужас.

Там 1.5 метра, тут в два раза увеличилось, здесь 30 МБ icu и в итоге не раздулся?

Qt тоже можно собрать без icu и он тоже будет прекрасно работать.

Можно, но все собирают с icu, потому что лень править дефолтные флажки в скрипте конфигурации. Даже в винде. Миллионы мух не могут ошибаться, да.

Почти весь серьезный софт использует libxml2, который зависит от icu.

Вот не надо, libxml2 это маленькая библиотека и в дистрибутивах её собирают без громоздкого icu:

$ ldd /usr/lib/libxml2.so.2.9.3 
        linux-vdso.so.1 (0x00007ffd67ede000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007faa28d46000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007faa28b30000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007faa2890a000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007faa2860b000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007faa28267000)
        /usr/lib64/ld-linux-x86-64.so.2 (0x000055c243525000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007faa2804a000)

И при этом плачешься насчёт поломанных тем в Firefox, который перешёл на GTK+3 и у которого внезапно сломался look-and-feel под KDE-окружениями.

Да насрать мне на его look and feel. Фанатик здесь только ты. Вместо реальных аргументов приводишь какой-то детский лепет, который вообще никак не усложняет пользование программами людьми.

Любому адекватному человеку без фанатизма в голове понятно, что Qt 5 раздулся.

Прям GTK 3 - эталон минимализма. При том что ещё и затачивается под Гном.

А всё почему? Потому что вместо доработки QtWayland параллельно пилится что? Правильно, KWayland!

Он пилится для KDE, но может быть использован и другими приложениями. Что тут плохого?

Прям GTK 3 - эталон минимализма. При том что ещё и затачивается под Гном.

GTK+3 не такой раздутый, ибо никак не зависит от ICU и OpenGL.

При том что ещё и затачивается под Гном.

Вот это минус, конечно.

Он пилится для KDE, но может быть использован и другими приложениями. Что тут плохого?

Не вижу тут абсолютно ничего плохого. Проблема в другом: QtWayland практически не пилится.

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

Ага. А Krita, я так понимаю, из-за избытка пользователей начала отказываться от раздутых и монструозных зависимостей KDE и переходить на KF 5 Tier Only. Уже как полгода перешла, а репутация программы с километровыми зависимостями за ней так и осталась. Обидно даже как-то.

И поменьше экспрессии, пожалуйста.

А почему дёргается это ускорение?

Хрен его знает. Не нравиться - пиши багрепорт.

Там 1.5 метра, тут в два раза увеличилось, здесь 30 МБ icu и в итоге не раздулся?

Уже выше объяснил, что это ваши фантазии.

Даже в винде

Еще раз: в винде нет прямой зависимости от icu.

libxml2 это маленькая библиотека

% equery s libxml2             
 * dev-libs/libxml2-2.9.4
         Total files : 157
         Total size  : 9.37 MiB

в дистрибутивах её собирают без громоздкого icu

В каких? Tiny Core Linux и прочих обрубках?

GTK+3 не такой раздутый, ибо никак не зависит от ICU и OpenGL.

Сами создали проблему и сами ее решили. Замечательно.

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

Дооооооо... Многиговый фотошоп - это фигня, а вот сотня метров либ у криты - это трагедия.

переходить на KF 5 Tier Only

Потому, что они не завязаны на лине и KDE.

Ага. А Krita, я так понимаю, из-за избытка пользователей начала отказываться от раздутых и монструозных зависимостей KDE и переходить на KF 5 Tier Only

Это и так естественный и логичный шаг. Тем более что Крита кроссплатформенна.

GTK+3 не такой раздутый, ибо никак не зависит от ICU и OpenGL.

У него других минусов тонна, а зависимость от ICU и OpenGL - преступление? Как это влияет на использование программы?

Если машинка будет без GPU

То называться будет эльбрус.

Там 1.5 метра, тут в два раза увеличилось, здесь 30 МБ icu и в итоге не раздулся?

У Qt 4 нет поддержки Wayland и вменяемого OpenGL. Qt Quick 1 тоже тот ещё подарочек. Классы коллекций сильно ускорились. Сигналы и слоты тоже были сильно улучшены.

Но нет. Продолжаем юзать устаревшее г мамонта. Там зависимости от icu нет.

Вы это вычислили по количеству либ? Замечательно.

Да это даже видно по простейшему «бенчмарку»:

$ ls .
main.cpp  untitled.pro

#-------------------------------------------------
#
# Project created by QtCreator 2016-08-07T16:25:38
#
#-------------------------------------------------

QT       += core gui

greaterThan(QT_MAJOR_VERSION, 4): QT += widgets

TARGET = untitled
TEMPLATE = app

HEADERS += main.cpp
SOURCES += main.cpp

#include <QMainWindow>
#include <QApplication>
#include <QDebug>

class MainWindow : public QMainWindow
{
    Q_OBJECT

public:
    MainWindow(QWidget *parent = 0) : QMainWindow(parent) { }
private slots:
    void paintEvent(QPaintEvent *) {
        qApp->exit();
    }
};

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    MainWindow w;
    w.show();

    return a.exec();
}

#include "moc_main.cpp"

$ qmake-qt4 untitled.pro 
$ make
/usr/lib/qt4/bin/moc -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. main.cpp -o moc_main.cpp
g++ -c -pipe -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -o main.o main.cpp
g++ -Wl,-O1,--sort-common,--as-needed,-z,relro -Wl,-O1 -o untitled main.o    -L/usr/lib -lQtGui -lQtCore -lpthread 
$ time ./untitled

real    0m0.109s
user    0m0.070s
sys     0m0.017s

$ qmake-qt5 untitled.pro 
$ make
/opt/toolkits/QtSDK/Qt5.5.1/5.5/gcc_64/bin/moc -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/opt/toolkits/QtSDK/Qt5.5.1/5.5/gcc_64/mkspecs/linux-g++ -I/home/exl/Projects/untitled -I/opt/toolkits/QtSDK/Qt5.5.1/5.5/gcc_64/include -I/opt/toolkits/QtSDK/Qt5.5.1/5.5/gcc_64/include/QtWidgets -I/opt/toolkits/QtSDK/Qt5.5.1/5.5/gcc_64/include/QtGui -I/opt/toolkits/QtSDK/Qt5.5.1/5.5/gcc_64/include/QtCore main.cpp -o moc_main.cpp
g++ -c -pipe -O2 -Wall -W -D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -I/opt/toolkits/QtSDK/Qt5.5.1/5.5/gcc_64/include -I/opt/toolkits/QtSDK/Qt5.5.1/5.5/gcc_64/include/QtWidgets -I/opt/toolkits/QtSDK/Qt5.5.1/5.5/gcc_64/include/QtGui -I/opt/toolkits/QtSDK/Qt5.5.1/5.5/gcc_64/include/QtCore -I. -I/opt/toolkits/QtSDK/Qt5.5.1/5.5/gcc_64/mkspecs/linux-g++ -o main.o main.cpp
g++ -Wl,-O1 -Wl,-rpath,/opt/toolkits/QtSDK/Qt5.5.1/5.5/gcc_64 -Wl,-rpath,/opt/toolkits/QtSDK/Qt5.5.1/5.5/gcc_64/lib -o untitled main.o   -L/opt/toolkits/QtSDK/Qt5.5.1/5.5/gcc_64/lib -lQt5Widgets -L/usr/lib64 -lQt5Gui -lQt5Core -lGL -lpthread 
$ time ./untitled 

real    0m1.143s
user    0m0.023s
sys     0m0.033s

Вот они эти самые 30 МБ ICU на холодном старте разворачиваются секунду аж.

Хрен его знает. Не нравиться - пиши багрепорт.

Ты срываешься и начинаешь делать ошибки.

Уже выше объяснил, что это ваши фантазии.

Это что же получается, дополнительные метры есть, увеличение объёма в два раза (без ICU) есть, а раздутость — мои фантазии?

В каких? Tiny Core Linux и прочих обрубках?

Debian: https://packages.debian.org/en/wheezy/libxml2
Arch Linux: https://www.archlinux.org/packages/extra/x86_64/libxml2/
Fedora/CentOS: http://rpmfind.net/linux/RPM/fedora/24/x86_64/l/libxml2-2.9.3-3.fc24.x86_64.html

Нету ICU у этой либы.

Если бы эти либы сидели себе спокойно и никого не мучали, но там ведь каша из пол-KDE:

Krita на Kickstarter (комментарий)

После установки всего этого буйства в какой-нибудь GNOME/XFCE/Unity уши кед начинают торчать отовсюду.

А как ты делал это в Qt 4?

Точно уже не скажу, но помню, что и с Qt4 и GTK2 бывали проблемы, если в нескольких местах настроить стиль/шрифты. Вплоть до того, что настройки в DE переставали работать, а такого быть просто не должно в нормально продуманной системе.

После установки всего этого буйства в какой-нибудь GNOME/XFCE/Unity уши кед начинают торчать отовсюду.

Поставил это «буйство», где мне в Unity искать эти уши?

% time ./test4
./test  0.03s user 0.00s system 62% cpu 0.048 total
% time ./test5
./test  0.03s user 0.01s system 73% cpu 0.081 total

И? На уровне стат. погрешности. То что у вас обрубок, вместо дистра, с выпиленным icu - не проблемы Qt.

увеличение объёма в два раза (без ICU)

Перечитайте сообщения. Там 30% в прыжке.

Нету ICU у этой либы.

https://www.archlinux.org/packages/extra/x86_64/icu/

У этой может и нет, а у десятков других - есть.

Required By (68)
qt5-base
kdelibs

А вот и RAM: http://wstaw.org/m/2016/08/07/Screenshot_20160807_212416.png

Обещали оптимизацию, почему стало больше ЖРАТ RAM и занимать памяти? Обещали разбить, чтобы было всё модульно. В итоге модули для приложения-кнопки стали весить (хорошо) на 30% больше, чем было изначально.

Вот как с тобой разговаривать? С начала ты утверждаешь:

использует libxml2, который зависит от icu.

А потом

У этой может и нет

Вот они, ушки: http://imgur.com/VqlGohX

Подробней в удалённых тут: Релиз графического редактора Krita 3.0