Набор патчей для Chromium с поддержкой Qt

А вот вопрос почти в тему. Кто нибудь может четко сказать что сейчас с лицензий на QT ? Есть же какая то коммерческая лицензия. А то вот напишешь программу с QT а тебе завтра выкатят что ты кучу денег должен …

Смущает приписка DO NOT LAND. К чему бы это…

хз. тут обсуждают https://www.opennet.ru/opennews/art.shtml?num=57020 , значит и нам можно.

Ну вообще, это в форум. Но отвечу.
Во-первых, не QT, а Qt. QT — это Apple QuickTime.
Во-вторых, ты можешь использовать Qt под одной из трёх лицензий:

• коммерческая;
• GPL;
• LGPL (не все модули). Если ты выбрал GPL, пишешь СПО и соблюдаешь её условия — о коммерческой версии тебе не нужно знать ничего. Совсем.
  Под LGPL можно писать проприетарщину на условиях LGPL же.

Единственный загон — ты не можешь смешивать эти лицензии. Т.е. если ты писал на LGPL, а потом тебе (тебе, не кутешникам) потребовалась коммерческая лицензия (например, потребовалось пропатчить сами кутешные модули, а выложить патчи под LGPL ты почему-то не можешь), то так просто купить лицензию и использовать при этом старый код нельзя. Ну или надо объяснить кутешникам свою проблему и получить добро. Я считаю, это крайне дебильное ограничение — но уж какое есть.

я ничего не понял, но и не хочу сейчас вникать. просто перенеси в токсы и дело с концом.

Поздно пить боржоми, я уже подтвердил.

https://www.opennet.ru/opennews/art.shtml?num=57020

Томас Андерсон (Thomas Anderson) из компании Google

Это же Neo!!!

ЛОЛ, точно

позволяют выбирать между GTK и Qt

Не просто выбирать, а выбирать в рантайме.

Насколько ужасной в Qt должна быть поддержка GTK3/GTK4 - приложений, что пилят хром под Qt? Или дело в GTK?

Мотив этого мне пока непонятен

потребовалась коммерческая лицензия (например, потребовалось пропатчить сами кутешные модули, а выложить патчи под LGPL ты почему-то не можешь),

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

Вероятный мотив: любой gtk-тор для qt, равно как и qt-ер для gtk, вызывает неадекватное поведения в соответствующей нативной среде. Например, задумали вы установить кеды и мате рядом, включили gtk-тор, все в мяте оформление помято. Верно и обратное. Поэтому лучше будет, если для каждого тулкита будет свой хромиум.

Это не может не радовать. Но файерфокс или вивальди на qt был бы лучше.

А мне очень даже понятен. ГТК3 == проблемы.

Мотив этого мне пока непонятен

Пусть MozillaFirefox поправит, но вроде в свое время в Mozilla предпринимались попытки добавить возможность собрать Firefox и на Qt, чтобы браузер выглядел нативно в KDE… Зачем это Chrome с его самопальным интерфейсом - не очень понятно

Но файерфокс или вивальди на qt был бы лучше.

Mozilla не осилила, хотя и пыталась, увы.

Для Haiku будет полезно, там поддержка Qt намного лучше чем GTK.

файерфокс на qt

Фу-фу-фу!

Поэтому лучше будет, если для каждого тулкита будет свой хромиум.

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

Наличие чего ? Вот у меня и Gtk и Qt есть в системе для разных приложений …

Вот только gtk это самая глючная и проблемная часть файерфокса. Например как поведёт себя меню загрузок при нажатии «открыть папку» вообще лотерея в каждом новом окружении.

В целом, нормально все работает.

Я поставил на новый комп манжару «на попробовать» (в убунту были какие-то странности с поддержкой железа, потом оказалось, что дело не в убунту). Но манжара так и осталась. Особым эстетом себя не мню, тулкитофобом тоже, каких-то прямо ужасных проблем см функционированием GTK-приложений в среде KDE не увидел.

Пожалуй, больше всего пришлось потанцевать с адекватным масштабированием шрифтов на HiDPI в Intellij Idea, но установка Идеи из снапа, а не из aur решила вопрос сама собой. Был, конечно, удивлен такому исходу, но разбираться в причинах не стал, работает-глаза не ломает - и ладно.

Хм, оно же, по идее, xdg-open дёргает.

В общем, в (современной) плазме (в манжаре) все функционирует вполне адекватно

См. LibreOffice По переменным окружения пытается определить сеанс, и потом подбирает соответствующий бэкенд VCL.

Кому не нравится, могут заенфорсить определенный (KDE/QT-шный до определенного момента обладал некоторыми обидными багами, и рекомендовалось использовать GTK-шный даже в KDE)

Ну, где то в процессе дёграния что то идёт не так в xfce, mate, lxde+kwin и xfce+kwin на дебианах 8-11.

Не. Кутешники против ситуации когда контора начала использовать Qt в своей проприетарщине на условиях LGPL, а позже конторе захотелось перейти на коммерческую лицензию (например проект выстрелил и захотелось коммерческих модулей или поддержки).

О, точно, вот такое я уже слышал. Ну, да, «упущенную» прибыль должны будут компенсировать.

Ладно спрошу по другому. В системе есть GTK и Qt, юзается к примеру какой нибудь icewm. И что будет использоваться ?

Насколько ужасной в Qt должна быть поддержка GTK3/GTK4 - приложений, что пилят хром под Qt? Или дело в GTK?
Мотив этого мне пока непонятен

«Motif этого мне пока непонятен»

Хех, попробую объяснить подробно. В качестве примера — LibreOffice, но, думаю, принцип схож для всех.

1. Факт установки Qt, GTK или вообще любого другого тулкита совершенно не важен. Вот, то есть, абсолютно не важен.
2. У LibreOffice есть довольно большой набор «рисовательных драйверов») — прокладок между общим рисовательным движком и конкретным тулкитом/способом отрисовки. Драйверы эти иногда довольно причудливые, например, gtk3_kde5 — GTK3 support with KDE5 file pickers (alternative to native kf5 one). Однако, даже наличие установленного драйвера — это не самый главный фактор при выборе способа отрисовки.
3. Что действительно важно, так это сеанс, окружение, под которым запущена программа. При старте программа пытается определить, под каким сеансом она запущена. В простейшем случае, это заглядывание в переменные окружения XDG_SESSION_DESKTOP и DESKTOP_SESSION. Но, на самом деле, магия чуть более магическая, см. например здесь. Зачем такое понадобилось, я наверняка сказать не могу, но, думаю, что можно проследить по истории изменений и соответствующим багам в трекере.
4. Пользователь может отменить всю эту … нетривиальную логику путем выставления переменных окружения, для LibreOffice это SAL_USE_VCLPLUGIN и OOO_FORCE_DESKTOP

Я понимаю что пишите Вы но наотрез хотите понимать что пишу я. Я могу понять когда пишут gnome и kde (и подобное) тут понятно что нужно юзать. Но есть ВМ которым по фигу эти всяие GTK и Qt. В этом случае что ?

Когда я ставлю transmission-gtk то понятно что он притащит в систему. А эта их фигня с автопределеним чего нет в системе, что притащит ?

Вы немного переформулировали вопрос. Теперь он касается установки, а не выбора бэкенда при старте.

Что «притащит эта фигня» зависит, в первую очередь, от пакетировщиков, как они нарежут и какие жесткие зависимости проставят. В предельном случае может притащить и Qt, и GTK. Но, надеюсь, редко кто из пакетировщиков так делает.

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

• libreoffice-gtk3 с очень скромным набором зависимостей на собственно GTK3-шные компоненты
• libreoffice-gnome (добавляет поддержку GIO)

Есть и пакеты libreoffice-qt5, libreoffice-kf5 и libreoffice-plasma с соответствующим набором зависимостей.

В Арче все бэкенды складываются прямо в единый пакет (например, libreoffice-fresh). Но, зато, все зависимости на тулкиты являются опциональными, так что, «не притащит вообще ничего».

А XDG-шные настройки разумные? Их можно попробовать подергать при помощи xdg-utils, там, как правило, становится понятно, что нужно донастраивать.

Я переформулировал потому что до сих пор не понимаю как там что то можно автоматом определить если в системе вообще нет ни gtk ни Qt и вм не тащит это в систему. И внезапно бывают всякие xdm и подобное … Т.е. я хочу chromium с конкретным гуем, я должен за место обычного yum install chromium-qt должен прочитать ховту и натыкать ручками в какой то там конфиг :(

И еще целый гимор мантейнеру пакета.

Не представляю. Туда лезть вообще реально, или проще свой браузер написать?

Возможно, я нашел ответ: https://bugzilla.mozilla.org/show_bug.cgi?id=1106916

Если это оно, и Вы используете файловый менеджер, не предоставляющий DBus FileManagerInterface, то, возможно, самым правильным решением было бы запилить DBus-сервис (хоть, хех, на питоне), который бы реализовывал интерфейс и проксировал вызовы к настоящему файловому менеджеру. Сам сервис — это практически копипаста такого, но с вызовом того же самого xdg-open в качестве пэйлоада.

Если проблема не в этом, то я бы попробовал все-таки посмотреть на настройки XDG посредством xdg-utils. Кое-что удаётся настроить там.

Но вообще, конечно, наслоений в этом вашем фридесктопе…

Я же показал код, который занимается этим в LibreOffice-е. Там всё просто и понятно по-сиплюсплюсному.

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

О, а вот и новость подъехала:

«Особенности выпуска:

В файловом менеджере (PCManFM-Qt) предоставлен DBus-интерфейс org.freedesktop.FileManager1 , который может использоваться в сторонних приложениях, таких как Firefox и Chromium...»