В рамках проекта gtkplatform (https://github.com/CrimsonAS/gtkplatform) развивается (https://www.reddit.com/r/linux/comments/724ozv/gtkplatform_r.../) новый механизм для бесшовного отображения Qt-приложений в окружениях на базе GTK+. В отличие от решений, основанных на стилизации элементов оформления, в gtkplatform предлагается иной подход - к Qt подключается плагин с реализацией платформы отрисовки на базе GTK+. Иными словами оконные операции Qt-приложений транслируются в API GTK+, который используется как первичный тулкит. Код написан на языке С++ и по аналоги с Qt распространяется под лицензиями LGPLv3 и GPLv2+.
Реализованный в gtkplatform подход позволяет задействовать в Qt-приложениях родные диалоги, обработчики ввода и меню GTK+, что сводит к минимуму видимые отличия при интеграции Qt-приложений в пользовательские окружения на базе GTK+. В том числе Qt-приложения могут бесшовно вписываться в окружение GNOME, работающее поверх Wayland. Подключение плагина производится через запуск приложения с установкой переменной окружения
"QT_QPA_PLATFORM=gtk" или через указание опции "-platform gtk".На текущем этапе развития поддерживается отрисовка через GTK+ оконных компонентов, формируемых при помощи QPainter, QOpenGLContext, QOpenGLWidget и QtWebEngine, возможно использование буфера обмена, используются нативные меню и диалоги GTK+, обрабатываются события ввода от сенсорных экранов, клавиатур и мышей. Из планов отмечается подготовка вспомогательных обработчиков для задействования специфичных возможностей GTK+, таких как вынос панели инструментов в заголовок окна (GtkHeaderBar).
URL: https://www.reddit.com/r/linux/comments/724ozv/gtkplatform_r.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=47262
Замутно
нужно было Qt отрисовывать на html/js на электроне тогда бы работало а так ненужная поделка
Я хоть и ярый адепт няшной сишечки и GTK+, но это извращение.
тык ведь там там C++ а не няшная сишечка
ярый адепт няшной сишечки - пена у рта быстро сохнет, как только возникают умопомрачительные нюансы управления сложностью проекта в 100+ файлов на Cи.пена сохнет, поверьте мне. и бесшовность из новости писали в кристально ясном рассудке.
> проекта в 100+ файлов на CиЛинус как-то не жаловался.
Линусов мало
Так и хороший софт тоже не каждый первый пишет. А какое-нибудь гамно на пыхе или бидоне рапидно наляпаное левой пяткой - работает именно так как должно работать рапидное гамно. Ну то-есть хуже чем даже какая-нибудь кривая гадость на дельфях от первобытных рапидчиков.
> ярый адепт няшной сишечки - пена у рта быстро сохнет, как только возникают умопомрачительные нюансы управления сложностью проекта в 100+ файлов на Cи.
> пена сохнет, поверьте мне. и бесшовность из новости писали в кристально ясном рассудке.Я другой аноним и я не понимаю почему другие люди не могут научиться организовывать свои проекты на Си не утопая в них если я это могу. Расскажешь?
докажи что не пустомеля.
напиши на gnu inline assembly макро вызова ядра с передачей параметров через регистры.
Ещё один враппер. Чтобы внешний вид чуть меньше был похож на лоскутное одеяло. Вещь хорошая, но это не решение.
> Ещё один враппер. Чтобы внешний вид чуть меньше был похож на лоскутное
> одеяло. Вещь хорошая, но это не решение.а он точно враппер, а не лишь ЗАМЕНА одного из компонентов в стеке Qt ?
переменная QT_QPA_PLATFORM -- разве накручивает число обёрток?
С позитивной стороны: эти хотя бы не форкают, а наоборот работаю на объединение
qtplatform надеюсь тоже есть который делает тоже самое но наоборот
годно, правильный подхода нет ли плагина который позволяет запускать приложение на одном компе, а окно рендрить на другом ? (дабы минимизировать сетевой трафик)(в связке с ссш например)
зы: лично мне на гтк чихать, но такие плагины и такие возможности у Qt это круто
Такой фиче уж 20 лет в обед.
Погуглите по ключевым словам ssh x11 forwarding
Придет Вейланд, дропнут Иксы и что тогда? Альтернативы нет, пока(VNC не предлагать).
Не дропнут. В маке дропнули ещё при рождении, но народ быстро прикрутил иксы и там.
> Не дропнут. В маке дропнули ещё при рождении, но народ быстро прикрутил иксы и там.Не будет иксов на линуксе -- станут без надобности и на маке.
>>а окно рендрить на другом ? (дабы минимизировать сетевой трафик)
>ssh x11 forwardingСейчас это не помогает в смысле уменьшения трафика. Рендерят ныне сами тулкиты, а X'ам отдаётся готовая картинка.
Собственно, все "проблемы" иксов именно из-за этого
У X есть проблемы? Однако не знал.
В QT/QML недавно запилили такую фичу.
Приложение работает на сервере, - а QT/QML графика, вроде как в браузере отрисовываеться, или на хосте клиента.
а по каким словам гуглить?
Qt WebGL streaming: http://blog.qt.io/blog/2017/02/22/qt-quick-webgl-streaming/
да ну?
Отлично. Теперь можна и Firefox на Qt переделывать. :D
Нужен проект по уничтожению gtk+ и тогда никаких проблем
Только qt, и везде всё будет одинаково и без костылей
Нужен проект по уничтожению Qt. Ведь на Qt только одна малопопулярная DE -- KDE. Мир даже не заметит, если Qt исчезнет. А вот если исчезнет GTK+, то ты вряд ли сможешь написать суда хоть что-то.
Люди в кедах бьються больнее чем гномы. Акуратнее.
Хм, у меня наоборот. Я не замечу, если ГТК исчезнет, потому что давно избавился от программ, на нём написанных, ведь они нигде не смотрятся как родные: везде смотрятся как выкидыши, кроме как в родном гноме. А в гноме они как у себя в доме, полном таких же внешних уродов.
Если сравнивать QT/QML и GTK+, то в пользу GTK+ только наследие, и ничего больше. Более того, HTML тоже следует принести в жертву QML, т.к. такому костыльному монстру не место в 21 веке.
>А вот если исчезнет GTK+, то ты вряд ли сможешь написать суда хоть что-то.Наивный пионЭр, вот у меня, например, нет на компе Gtk, а я сюда пишу.
P.S. И у меня не Винда, и не МакОСь, если что.
Это он и есть. У тех, кто писал на gtk только ради внешнего вида, больше не окажется отмазок, и они уйдут на qt.
Вот практически не интересут внешний вид, т.к. не гуидрочер ни разу. Как разработчик я против QT из-за уродской архитектуры. Уродская архитектура еще и чужеродная по отношению к unix-way, так что в *nix не должно быть ее по идее. Я не понимаю сторонников QT как можно сознательно уходить в сторону уродства. Единственное вносит ясность в ситуацию - это высказывание о миллионах мух.
Quick Time действительно хреновый. Спасибо, что напомнили. А как это связано с Qt?
и сколько тулкитов с расово верной
и сколько тулкитов с расово верной архитектурой написал месье программист?
То есть теперь Qt перестанет быть вырвиглазным?
Для человека, выросшего среди квазимод, любой нормальный кажется уродом.
Вырвиглазным может быть дизайн интерфейса на Qt, но не сам Qt. И, разумеется, нет вины Qt в том, что его используют рукожопы. Qt не Python, никаких ограничений на фантазию разработчика не накладывает.
> Вырвиглазным может быть дизайн интерфейса на Qt, но не сам Qt. И, разумеется, нет вины Qt в том, что его используют рукожопы.Поменяй Qt на GTK и в смысле фразы, кроме названия тулкита, ничего не изменится. Всё тоже самое справедливо и для GTK.
Однако ведущие разработки на ГТК, ткие как ГИМП, Инкскейп и Пиджин выглядят чужеродными вне гнома, что говорит либо о некомпетентности разработчика, либо об ущербности инструментария.
Ну во-первых не только гнома, а ещё и гномопроизводных (Корицы, Крысы и т.д.).
Во-вторых это говорит о том, что, как ниже уже написали, GTK не ставит (в отличие от Qt) своей основной задачей кроссплатформенность. Странно, они вроде этого и не скрывали, но все почему-то думают иначе.
В-третьих, Qt-программы тоже в среде отличной от KDE выглядят хоть чуть и получше, но всё равно чужеродно.
Кросплатформенность здесь не причем. Насчет "чужеродности", Вы явно не писали на QML. Поясню ситуацию, - на QML разработчик сам рисует и стилизует все элементы, создает анимации и применяет шейдеры. Т.ч. итоговый дизайн и юзабилити интерфейса - заслуга только разработчика ПО. QML со своей задачей справляется на 5+, а именно предоставляет разработчику абсолютную гибкость для реализации любых фантазий. Он намного гибче HTML и GTK, и многократно превосходит их по производительности.
Как пользователь - я бы с удовольствием придушил за такой подход. Пусть разработчики засунут свою богатую фантазию куда подальше вместе с шейдерами ит анимациями, а работают, чёрт возьми, с готовыми контролами, предоставляемыми системой - и, пожалуйста, с минимальным количеством настроек, относящихся ко внешнему виду. А дефолтам и настройкам место в теме, контролируемой пользователем. Но в Qt накрутили что-то таоке печальное, что на внешний вид приложения пользователь толком повлиять не может.В этом плане идеальным в плане архитектуры был в своё время механизм XResources - настройки и адресация хоть всего сразу, хоть индивидуального виджета. Вот примерно так бы и надо.
На винде - как родные. В Гноме 2, раньше сами гномеры говорили что как родные, в третьем не знаю, я этим шлаком не пользуюсь. А вот ГТКшные везде уродливо смотрятся, а не в гноме ещё и чужеродными.
К окулисту сходи.
Попробовал этот плагин в Arch. Работает, но сырой еще. Если Qt-приложение имеет собственный интерфейс, отличный от "стандартного", gtkplatform с ним конфликтует. Например, проигрыватель QMMP перестает запускаться, если у него в настройках указан интерфейс с поддержкой обложек (winamp-подобный). Так что покамест посижу на qt5gtk2.
Чо люди ни придумают, лишь бы FLTK не юзать
Позёр! Motif вещь.
Он, таки, прав, FLTK представляет собой OO API, в отличие от. Даже тот же Gtk, и тот более ОО, по сравнению с никаким в этом отношении Motif.
теперь надо на qt gtk эмулировать и сравнить кто лучший гном и наоборот, глядишь фаны ченьчж оформят.
Зачем на непонятном нечто, которое некоторые используют вместо тулкита, эмулировать тулкит? Тем более, что в няшных кедах и так всё выглядит и работает единообразно.
О, левитирующие макароны на скриншотах, найс.
АКА "рожки"
Никогда не понимал этого стремления к мимикрии друг в друга. Что плохого если Qt-программа будет выглядеть как Qt-программа, а GTK, соответственно, как GTK?
в данном случае не мимикрирование под GTK, а реализация отрисовки на GTK
Но результат аналогичный. Тем более, что такой подход не избавляет от необходимости иметь Qt в системе.
> Тем более, что такой подход не избавляет от необходимости иметь Qt в системе.ну малоли какие дурааки софт пишут.
некоторые не хотят писать под линукс (то есть -- писать сразу на GTK), а компилируют для линукса -- только подачки получаемые ввиде сборки кросплатформенного кода (Qt, wxWidgets, Java, ...)..
находятся даже и те которые вообще пишут софт на C# под расчёт на Mono, и для них тоже требуется держать в системе кучу гоовна..
в целом довольно много существуют людей кто не видит очевидного факта о том что кросплатформенные программы ведут себя как кусок гоовна, в отличии от программ под конкретную ОС.
приходится с этими людьми как-то жить, и тоже совержать жертвы
>Что плохого если Qt-программа будет выглядеть как Qt-программа, а GTK, соответственно, как GTK?Любитель лёхких WM? Ну что уж там, пусть тогда каждое приложение свою собственную прибитую к нему тему запиливает. Красота будет на арене s/цирка/экране.
шютка про замену была бы смешнее, если б не было очевидным, что ты подобное сочетание букв набираешь только в комментах
Вместо того, чтобы свои родные GTK-ные приложения на GTK3+ красиво отобразить на Qt, они предлагают изуродовать все родные Qt-ные приложения.
Нет уж, заберите этот кусок кала себе!
потомучто GTK не ставит кросплатформенность -- своей осноаной целью.GTK главным образом это мэйнстрим GUI в линукс-ос.
а вот Qt сразу позиционировали себя кросплатформенным, с набором кросплатформенных костылей как неотъемлемая часть себя.
таким образом вполне логично что Qt должен уметь отрисовывать себя через GTK (то есть через стандартный линуксовский GUI-тулкит) :-) .. а наоборот -- вовсе не обязательно
> с набором кросплатформенных костылейПо крайней мере один человек с вами не согласен.
Такой мейнстрим, что куча проектов с него на Qt мигрироваала.
> Такой мейнстрим, что куча проектов с него на Qt мигрироваала.не бзди! линуксовские программы -- не мигрировали на Qt.
а мигрировали только те программы, которые были сделаны для Windows и имели Linux-версию просто как очередной свой порт.
> а мигрировали только те программы, которые были сделаны для Windows и имели Linux-версию просто как очередной свой порт.А пацаны в LXDE, Budgie, GCompris, SubSurface, Audacious, Wireshark ... и не знали! А оно вот как оказывается — на самом деле все для Окошек делалось!
> ...GCompris, SubSurface, Audacious, Wireshark ... и не знали! А оно вот как оказывается — на самом деле все для Окошек делалось!лол! ты так удивляешься будто я сделал для тебя не весть какой открытие...
да, для окошек! а что?
а почему тебе это кажется странным? очевидно авторы *этих* программ щитают Окошки более приоритетным направоением, и наверняка сами зачастую сидят на ноутбуках с Windows..
(а бывают такие люди-программисты, которые и вообще не загружаются в Linux ос никогда, и всегда сидят только на окошках)
Wireshark существует как Qt-версия (сделанная ОЧЕВИДНО для Windows, и это не скрывается.. хотя любой извращениц может и на Linux это установить) и Gtk-версия (сделання для Linux), но возможно авторы откажутся от Gtk , если пощитают что существование Windows-версии уже достаточно (с возможностью кривенькой сборки на Linux, которым например если не будут пользоваться сами авторы то вообще наасрать, как они пощитают)
# P.S. из перечисленного тобой только в LXDE и Budgie -- ситуация не ясная. LXDE имеет и Qt и Gtk версии, а Budgie вообще только Gtk и их фантазии по поводу Qt основаны на каком-то бреде типа "у нас лёгкая оболочка не утяжелённая ни чем, но мы хотим добавить видео-эффекты и прочие многочисленные плюшки, хрен знает как их сделать не внеся утяжелений. наверно в Qt всё получиться, ведь хорошо всегда там где нас нет"
>> ...GCompris, SubSurface, Audacious, Wireshark ... и не знали! А оно вот как оказывается — на самом деле все для Окошек делалось!
> лол! ты так удивляешься будто я сделал для тебя не весть какой открытие...
> да, для окошек! а что?
> а почему тебе это кажется странным? очевидно авторы *этих* программ щитают Окошки
> более приоритетным направоением, и наверняка сами зачастую сидят на ноутбуках с
> Windows..Cколько жЫра^W пафоса.
https://github.com/torvalds/subsurface-for-dirk/graphs/contr...
torvalds
> 802 commits / 336,250 ++ / 14,768 --Известнейший фанат Окошек, ага. С фирменным одобрительным жестом.
https://www.opennet.dev/opennews/art.shtml?num=40067
> 24.06.2014 04:02 Audacious возвращается на GTK2, в перспективе переход на Qt
> Решение объясняется несогласием с методами развития последних выпусков GTK3+ и продвижением изменений,
> усложняющих разработку традиционных интерфейсов для настольных систем.В общем — худей.
Мигрировали немногие. Питонисты не мигрировали точно. Сейчас мало людей, способных здраво и объективно производить оценку ситуации. Везде фанатизм. Поэтому жив Python, поэтому жив HTML, поэтому будет жить GTK.
Только PyGtk не очень жив
> Питонисты не мигрировали точно.Рождённый ползать мигрировать не может.
Изобрели wxWidgets
Плюс в карму Qt за удачную архитектуру, позволяющую такое. Чего не скажешь о ГТК! Но получается нехорошая ситуация: худший фреймворк становится основой системы (gtk), а лучший - всего лишь настройкой.
> Плюс в карму Qt за удачную архитектуру, позволяющую такое.[сарказм]позваляющее аж такое?! ну и чюдеса![/сарказм]
а больше ничего другого они там не позволяют?
например чтобы не только форма/цвет кнопочек менялась, но ещё и автоматически Human Interface Guidelines подхватывалось от той операционной системы под которую производится компилирование?
или разработчики Qt об этом решили тихонько умолчать? мол -- "пусть эти фанаты кросплатформенности сидят себе в РАДОСТНОМ неведении о том, что мало скомпилировать программу под конкретную ос, но ещё и нужно бы уважать способ размещения контроллов управления ИМЕННО ТАК как принято в этой конкретной ОС..."
# P.S.: а ещё больший эпик фэйл -- это у кросплатформенных идиоотов на Java! они зачастую ещё глупее -- и даже не то что про H.I.G. не знают, но и даже банально не догадываются что каталог /tmp/ это оперативная память (и что нельзя туда срать десятками гигобайтов файлов, скачанных из интернета)
# P.P.S.: вам хоть 500 раз повтори что у каждой операционной системы свои нюансы, которые нужно учитывать (если хотите сделать качественную пограмму), а вы всё равно вы за своё -- "хочу чтобы коммпилятор мне сделал бы кросплатформенность за меня сам, и сам разрулил бы все нюансы".. ТФУ!
> или разработчики Qt об этом решили тихонько умолчать? мол -- "пусть эти фанаты
> кросплатформенности сидят себе в РАДОСТНОМ неведении о том, что мало
> скомпилировать программу под конкретную ос, но ещё и нужно бы уважать способ
> размещения контроллов управления ИМЕННО ТАК как принято в этой конкретной ОС..."В QML контроллы размещает сам программист. Причем здесь Qt?
>> или разработчики Qt об этом решили тихонько умолчать? мол -- "пусть эти фанаты
>> кросплатформенности сидят себе в РАДОСТНОМ неведении о том, что мало
>> скомпилировать программу под конкретную ос, но ещё и нужно бы уважать способ
>> размещения контроллов управления ИМЕННО ТАК как принято в этой конкретной ОС..."
> В QML контроллы размещает сам программист. Причем здесь Qt?при том что в зависимости от того под какую операционную систему компилируешь свой софт -- в таком порядке (и в общем случае в способе-компоновки) нужно размещать контролы
вот тебе HIG паттерн для Линукса (GNOME) -- https://developer.gnome.org/hig/stable/patterns.html.en
в Windows размещение должно быть совершенно другим (а также другое ожидается Windows-пользователями количество цветных пиктограмм).
как это решает Qt? ни как? ну и нафига тогда было городить эти все слои совместимости? для производства КЛОУНСКОГО софта?
Это не для линукса, это для гнома HIG. Судя по результату - совершенно чудовищный. Опять же - это ж не мобила, где приложение состоит из трёх кнопок и открыватеся на 10 секунд. На ПК в софте работают. И то, насколько продуман гуй относительно рабочего процесса на порядок важнее, чем его соответствие отчередному локальному окружению.Как по мне - надо вообще наплевать на идентичнй look & feel и делать так, как оптимально для конкретного случая. Не забыв, конечно, дать пользователю как можно больше ручек чтобы всё это подкрутить при нужде.
> как это решает Qt? ни как?Это решает не Qt, а программист. И в общем случае это правильный подход. Хороший тому пример - X.Org, мультикомбайн, который делает всё и делает кое как. Qt решает одну конкретную задачу и делает это хорошо. На базе Qt программист может без проблем сделать любое размещение кнопок.
Я лично не вижу вообще в этом никакой проблемы. Но если Вас заботят такие мелочи -
напишите разработчику программы, и он наверняка поправит данный момент.
Qt - одну конкретную задачу? Вы его вообще видели?P.S. X.org, кстати, решает таки одну задачу - реализует протокол X11.
>P.S. X.org, кстати, решает таки одну задачу - реализует протокол X11.очевидно, qt решает таки одну задачу - реализует кроссплатформенный тулкит
> но и даже банально не догадываются что каталог /tmp/ это оперативная память/tmp/ - не оперативная память, это память для временных объектов, разных кэшей.
>> но и даже банально не догадываются что каталог /tmp/ это оперативная память
> /tmp/ - не оперативная память, это память для временных объектов, разных кэшей.можешь абстрагироваться как хочешь -- а суть реализации всё равно не поменяется -- /tmp/ это оперативная память.
для кэшей которые НЕ в оперативной памяти есть ~/.cache/ и /var/ ( /var/cache/ и /var/lib/ )
> можешь абстрагироваться как хочешь -- а суть реализации всё равно не поменяется -- /tmp/ это оперативная память.Можешь думать чё хочешь, каталог tmp (от слова temporary - временный) на многих системах находится на жестком диске (или ssd). Основная его суть - размещение временных файлов. Никаких стандартов и законов, что он должен находиться в оперативной памяти нет.
Абстрагироваться куда, откуда, о чем вы болезный? /dev/shm - в оперативной памяти, а /tmp - на диске.
> Абстрагироваться куда, откуда, о чем вы болезный? /dev/shm - в оперативной памяти, а /tmp - на диске.вот тебе фрагмент кода отечающий за то что /tmp/ в итоге идёд в оперативную память:
https://github.com/systemd/systemd/blob/v234/units/tmp.mount.m4
что на это скажешь? съел?
скажешь что лично у тебя какая-то другая нестандартная раскладка файловых систем?
или скажешь что исходны код systemd это якобы не показатель линуксовских ос?
> /dev/shm - в оперативной памяти
и это тоже (но предназначено для более специализированной цели -- межпроцессоного взаимодействия).
>> Абстрагироваться куда, откуда, о чем вы болезный? /dev/shm - в оперативной памяти, а /tmp - на диске.
> вот тебе фрагмент кода отечающий за то что /tmp/ в итоге идёдman hier
https://manpages.debian.org/stretch/manpages/hier.7.en.html
/tmp
This directory contains temporary files which may be deleted with no notice, such as by a regular job or at system boot up.> в оперативную память:
> https://github.com/systemd/systemd/blob/v234/units/tmp.mount.m4
> или скажешь что исходны код systemd это якобы не показатель линуксовских ос?systemctl enable tmp.mount уже делать не надо?
Кстати:
https://www.freedesktop.org/software/systemd/man/systemd.mou...
> Mount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details).
> ...
> In general, configuring mount points through /etc/fstab is the preferred approach
> systemctl enable tmp.mount уже делать не надо?верно -- делать enable не требуется! это уже есть соответствующий Wants в basic.target:
https://github.com/systemd/systemd/blob/v234/units/basic.target
может хватит придуриться? :-) может просто установишь какой-нибудь Linux и увидишь своими глазами?
> вам хоть 500 раз повтори что у каждой операционной системы свои нюансы.От тех нюансов, которые Вы описали, следовало бы вообще избавиться, придти к какому-то единообразию. Распихивать контроллы в разном порядке в разные углы окон для каждой ОС просто потому что кто-то сказал так делать - это глупость, рудимент, в котором нет никакого смысла. По себе могу сказать, я постоянно переключаюсь между виндой и линем, и не замечаю что порядок расположения кнопок меняется. У вас же целая истерика по этому пустяку, может проблем в чем-то другом?
> От тех нюансов, которые Вы описали, следовало бы вообще избавиться, придти к какому-то единообразию.ну щитай что уже пришли. просто используй Linux без Windows и тогда будет у тебя единообразие :-) без нюансов кросплатформенности...
в чужой манастырь со своим уставом не ходят.
если ты решил писать под Windows -- то будь добр уважай Вендусовые стандарты оформления. (и вендусовые лучшие практики программирования -- для реализации слоя логики)
а если хочешь программировать под Linux -- то извините но у Linux тоже есть стандарты оформления и свои лучшие практики.. например ни один нормальный человек не будет биндить слушающий сетевой порт выше 32000 на Linux (чтобы не залезть в динамическую зону выделения сетевых портов) -- а для Windows быть может это и нормально было бы. в каждой операционной системе полно таких мелких вещей, которые тебе кросплатформенный компилятор не сделает
> в чужой манастырь со своим уставом не ходят.Чужой монастырь? ПО пользуются пользователи, а программисты его только пишут и компилируют под разные ОС. Каждый программист вправе сделать такой GUI, какой желает и собрать под любую ОС. И есть простое негласное правило: не устраивает, - не используй. А если хочешь что-то изменить, напиши в баг-трекер того ПО, которое не устраивает, может быть тебе пойдут навстречу и закостыляют другое расположение кнопок. А нытье здесь точно ничего не изменит.
> Каждый программист вправе сделать такой GUI, какой желает и собрать под любую ОСно это не отменяет того факта что потом каждый пользователь этого GUI останется недоволен -- и вполне тоже *имеет_право* написать эту *правду* на любом форуме...
...дабы предупредить других начинающих программистов (которые тоже "...вправе сделать такой GUI, какой желает и собрать под любую ОС") *заранее* предупредить -- не заниматься созданием гоовна.
> А если хочешь что-то изменить, напиши в баг-трекер того ПО
архитекрурные проблемы -- записью в багтрекер не исправишь.
тебе просто у виска покрутят пальцем и всё.. status:CLOSED solution:WONTFIX
Виджеты в 2017м году... Перспективненько)
А что? HTML5+JS?
+1. Осталось притащить Electron/NodeJS -> успех гарантирован.
Ё-моё, QMl же!
JSON+JS
> задействовать в Qt-приложениях родные диалоги, обработчики ввода и меню GTK+Новость отличная, поздравляю гномеров.
Но вот когда же уже для gtk+ сделают нормальные диалоги. Не эти убогие обрубки, лишённые всяческих возможностей, а нормальные диалоги, как в kde, qt и даже в винде.
Это же позор линукса продолжительностью с десяток лет.
> Это же позор линукса продолжительностью с десяток лет.Не-не-не, ты ваш гномосековский позор на линукс не перекладывай.
Есть QML. А позору линукса пора на покой.
Самое гнусное, что эта штука ест только Qt темы (Adwaita-Qt и Fusion-Qt). Т.е. это никак не замена QGtkStyle. А жаль... Хотелось бы QGtkStyle с поддержкой GTK3 тем.