Нет, я разочарован в людях, которые за двадцать лет так и не смогли прийти к одному нормальному тулкиту, имея при этом все возможности. Даже с POSIX худо-бедно справились, а эти так и продолжают страдать ерундой.
Причин этому несколько. Во-первых LSB – полная херня. Во-вторых – у прикладников нет централизации, которая есть в самом ядре Linux. В-третьих пренебрежение к GUI у большей части разработчиков прикладного ПО для Linux.
Никто не занимался развитием графики в Linux, как занимались этим в той же macOS. Вкорячили в 90-ых уже тогда устаревшие иксы под девизом: и так сойдёт и начали лепить к ним костыли, чтобы хоть как-то оно работало. Пока линуксоиды ковырялись с протухшим говнокодом иксов, в Apple сделали Quartz, доработали напильником GUI-тулкит из NeXTSTEP’а и построили стройную систему фреймворков. А вариант с переходом на иксы, который им предлагали очередные UNIX-вейцы, разработчики из Apple просто высмеяли. Как сейчас видно из 2019 года, решение разработчиков взять и написать собственный графический стек – это здоровое и правильное решение.
Потребовалось добавить в macOS поддержку Retina 5K дисплеев? Он просто взяли и поправили CocoaAPI таким образом, чтобы HiDPI появился и в старых приложениях под macOS, которые использовали нативный API.
А что в мире Linux? Выкинули и написали новое, попутно сломав всё накопленную совместимость. В итоге и создаются такие треды: чому GIMP не умеет в HiDPI? Чому Firefox в KDE начал выглядеть как говно? Тысячи их. Только сегодня какие-то подвижки в плане изменения ущербного графического стека Linux’а появились, вроде того же Wayland’а. Вот только мешанины из тулкитов и угрёбищную мимикрию одного под другое это никак не отменяет.
Отчасти из-за подобных проблем у Linux’а и будет ~1% на десктопах. Разве что если всё прикладное ПО в Web и прочие Electron’ы мигрирует – будет шанс чуть подняться.
В идеале было бы хорошо сделать так, как делает Qt на macOS и Windows: копирует системную тему и пользуется их системными API. Но на Linux’е Qt рисует всё сам, а по идее должен будет зависеть от GTK+, использовать его для того чтобы создавать привычный юзеру UX.
В полях для ввода текстов в GTK+-приложениях я могу зажать Ctrl+Shift+U и ввести код для вставки UNICODE-символа. Qt же просто кладёт хер на это Linux-овое поведение. Все эти мелкие проблемы + извечные проблемы мимикрии и несоответствия тем в итоге и создают негативное впечатление от использования десктопного Linux’а.
Если не менялось (но как минимум один раз менялось, раньше было carbon, а потом cocoa), то я не представляю, какие там костыли на костылях.
За время перехода Carbon => Cocoa в macOS, в Linux’е сменилось три мажорных и несовместимых между собой версии GTK+ и пять версий Qt с такими же проблемами. И при каждом переходе отваливались какие-либо популярные ранее приложения, вроде XMMS, Amarok и т. д.
Вот уж кому-кому, но не Linux’оиду упрекать macOS в переходе Carbon => Cocoa. Apple’овцы поддержку Carbon’а дропнули только в этом десятилетии, хотя создан он был хрен знает когда, наверное раньше иксов. Это как если бы сегодня Qt 5 имел в комплекте модуль Qt1Support. А Qt-разработчики в Qt 5 даже Qt3Support переносить не стали, скосив ещё некоторые так и неперенесённые программы.
то я не представляю, какие там костыли на костылях.
Костыли на костылях – это сабжевый тред. Это плак-плак на HiDPI Linux выглядит как говно. Это мимикрия GTK+ под Qt и Qt под GTK+. Вот где костыли на костылях, а не в CocoaAPI.
А что в мире Linux? Выкинули и написали новое, попутно сломав всё накопленную совместимость. В итоге и создаются такие треды: чому GIMP не умеет в HiDPI? Чому Firefox в KDE начал выглядеть как говно? Тысячи их. Только сегодня какие-то подвижки в плане изменения ущербного графического стека Linux’а появились, вроде того же Wayland’а. Вот только мешанины из тулкитов и угрёбищную мимикрию одного под другое это никак не отменяет.
Проблема wayland'а в том, что это не графический тулкит, не библиотека и даже не ProofOfConcept. Это спецификация на композитор. И если бы к спецификации на композитор шла в комплекте _библиотека_, с полной реализацией протокола — было бы очень, очень хорошо (несмотря на некоторые спорные решения). Но в итоге опять получится зоопарк из weston, gnome shell, wlroots, и ещё сто пудово кто-нибудь свое напишет. То есть зоопарк станет еще больше.
Карбон это такое shim, который реализовывал существовавший до него API. Просто до него это вроде какая-то дичь чуть ли не на паскале была. То есть карбоновый API уходит настолько далеко в глубину времен, что там ещё на паскале писали.
Вообще до смешного доходит — в swaywm на полном серьезе обсуждают DPMS. Ну типа в иксах i3 только окошки раскидывает. Но не в wayland. В wayland композитор делает ВСЕ. Поэтому каждый дурак, который пилит свой dwm, теперь должен думать про DPMS %)
Господи, я надеюсь что wlroots убьет все остальные библиотеки, иначе это будет очень, очень больно.
Видать только GNOME OS и KDE OS будут выходом из сложившийся ситуации.
Проблема wayland’а в том, что это не графический тулкит
Вот кстати, в иксах был графический тулкит и шрифтовый движок. А может и до сих пор есть. Развивать всё это не стали и тупо забросили. А ведь эти технологии как раз могли стать тем, чем стали WinAPI или CocoaAPI в настоящее время. И иксы может быть закапывать тогда не пришлось.
Было бы какое-нибудь теоретическое X API, к которому линковались бы GTK+, Qt, wxWidgets, FLTK, Java, C#/Mono, браузеры и т. д. и рисовали через него. Запилили поддержку HiDPI в этом X API – прикладные разработчики получили возможность использовать эту фичу в своих программах и тулкитах даже без перекомпиляции.
Вот только всё это было похерено и Linux-десктоп погряз в перманентной мимикрии одного под другое.
2-3 года назад всё равно было не до HiDPI. Ветку gtk3-port почти не трогали с 2010 что ли года, только git rebase делали, ну и по чуть-чуть подпиливали раз в пару лет. Все силы были брошены на версию 2.10.
Меня больше бесит, что софт на Qt приходится запускать в гноме из терминала с QT_FONT_DPI=140. А из документации ни черта не понять, есть ли какая-то переменная, которую можно один раз задать в общем конфиге Qt и не париться.
Меня больше бесит, что софт на Qt приходится запускать в гноме из терминала с QT_FONT_DPI=140. А из документации ни черта не понять, есть ли какая-то переменная, которую можно один раз задать в конфиге и не париться.
Вообще это вроде как делается через QT_SCREEN_SCALE_FACTORS=2. По крайней мере, это единственный способ скалировать иконки, потому что шрифты он вроде сам по себе скалирует уже.
Лулз в том, что этот способ отмечен как dev-only на их сайте :D
Ну это понятно, что Carbon это относительно «недавний» проект. Но он же реализует те API, которые юзались в ранних версиях классических Mac OS. И, насколько я помню, не только 8-9, но и совсем-совсем древнее вроде System 7 и глубже.
Даже если взять 2000 год датой условного появления Carbon’а и 2012 год как дату того, когда он официально стал устаревшим, то получается они 12 лет поддерживали уже заведомо устаревшее API-прослойку. В мире Linux есть что-то подобное?
Даже если взять 2000 год датой условного появления Carbon’а и 2012 год как дату того, когда он официально стал устаревшим, то получается они 12 лет поддерживали уже заведомо устаревшее API-прослойку. В мире Linux есть что-то подобное?
В 2019 году в Wayland запиливают fullscreen extension. Спустя десять лет после начала разработки. Вот примерно о таком уровне продуманности мы тут говорим.
У них там свои внутренние срачи. Они годами не могли договориться про full-screen color management. Как мне пару лет назад рассказывал Хьюс (автор gnome color manager и colord), было две спеки: одна — сложная, развесистая лапша, вторая — простая как тапок. Пересрались и не приняли ни одну.
При этом, насколько я помню, приложение должно быть собрано с поддержкой фичи.
Именно что. Где-то получается нормально, где-то — говняшка. А главное — ХЗ, как задать один раз и больше не трогать (и дальше уже патчить каждое кривое приложение).
А главное — ХЗ, как задать один раз и больше не трогать (и дальше уже патчить каждое кривое приложение).
По идее что-то вроде QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCALE_FACTOR=2.0 или QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCREN_SCALE_FACTORS=2.0;1.0;0.7 (если многомониторная конфигурация) должны помочь.
Похоже размер шрифта у тебя увеличен где-то в настройках.
QT_SCALE_FACTOR [numeric] defines a global scale factor for the whole application, including point sized fonts.
QT_SCREEN_SCALE_FACTORS [list] specifies scale factors for each screen. This will not change the size of point sized fonts. This environment variable is mainly useful for debugging, or to work around monitors with wrong EDID information(Extended Display Identification Data).
Я посмотрел, KDE скалирует через QT_SCREEN_SCALE_FACTORS. Скорее всего, в какой-то момент Qt начал скалировать шрифты без специальных переменных, поэтому QT_SCALE_FACTOR по сути скалирует два раза.