Когда там GIMP перепишут на GTK3?

прям из клозета за шкирку вытащил!

Нет, я разочарован в людях, которые за двадцать лет так и не смогли прийти к одному нормальному тулкиту, имея при этом все возможности. Даже с 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, и ещё сто пудово кто-нибудь свое напишет. То есть зоопарк станет еще больше.

Apple’овцы поддержку Carbon’а дропнули только в этом десятилетии, хотя создан он был хрен знает когда, наверное раньше иксов.

«Carbon was introduced in incomplete form in 2000, as a shared library backward-compatible with 1997's Mac OS 8.1.»

«X originated at the Massachusetts Institute of Technology (MIT) in 1984. The X protocol has been version 11 (hence „X11“) since September 1987.»

Карбон это такое shim, который реализовывал существовавший до него API. Просто до него это вроде какая-то дичь чуть ли не на паскале была. То есть карбоновый API уходит настолько далеко в глубину времен, что там ещё на паскале писали.

Те надо было года 2-3 назад подарить ему монитор? Ну написали бы!

Те надо было года 2-3 назад подарить ему монитор? Ну написали бы!

Да, это как в том анекдоте с коровой — сначала нужно сделать хуже.

Вообще до смешного доходит — в swaywm на полном серьезе обсуждают DPMS. Ну типа в иксах i3 только окошки раскидывает. Но не в wayland. В wayland композитор делает ВСЕ. Поэтому каждый дурак, который пилит свой dwm, теперь должен думать про DPMS %)

Господи, я надеюсь что wlroots убьет все остальные библиотеки, иначе это будет очень, очень больно.

Но в итоге опять получится зоопарк из weston, gnome shell, wlroots, и ещё сто пудово кто-нибудь свое напишет.

+Kwin. И опять же всё это нихрена не стандартизировано, всё упирается в идиотизм навроде: https://gitlab.gnome.org/GNOME/mutter/issues/217#note_263617

Видать только 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 есть что-то подобное?

Tk?

Вообще это вроде как делается через QT_SCREEN_SCALE_FACTORS=2.

Неа, шрифт не масштабируется, иконки — тоже.

fullscreen-shell-v1: initial protocol implementation #1452

В 2019 году в Wayland запиливают fullscreen extension. Спустя десять лет после начала разработки. Вот примерно о таком уровне продуманности мы тут говорим.

Неа, шрифт не масштабируется, иконки — тоже.

У меня именно так и работает. Покажи env | grep QT_. У меня дня три заняло свести все воедино и пропатчить нужный софт :D

http://doc.qt.io/qt-5/highdpi.html

QT_SCALE_FACTOR=2.0 ./qt-app ?

При этом, насколько я помню, приложение должно быть собрано с поддержкой фичи.

Эта опция не скалирует шрифты, её не нужно.

У них там свои внутренние срачи. Они годами не могли договориться про full-screen color management. Как мне пару лет назад рассказывал Хьюс (автор gnome color manager и colord), было две спеки: одна — сложная, развесистая лапша, вторая — простая как тапок. Пересрались и не приняли ни одну.

Как это не скалирует? Оно у меня иконки и шрифты масштабирует, всё норм.

У меня так https://i.paste.pics/4HRRW.png

Слева без QT_* вообще. Справа с QT_SCREEN_SCALE_FACTORS=2. Важно чтобы не была установлена QT_AUTO_SCREEN_SCALE_FACTOR=1.

Как это не скалирует? Оно у меня иконки и шрифты масштабирует, всё норм.

Я ошибся, дважды скалирует: https://i.paste.pics/4HRS6.png

Слева QT_SCALE_FACTOR=2, справа QT_SCREEN_SCALE_FACTORS=2.

При этом, насколько я помню, приложение должно быть собрано с поддержкой фичи.

Именно что. Где-то получается нормально, где-то — говняшка. А главное — ХЗ, как задать один раз и больше не трогать (и дальше уже патчить каждое кривое приложение).

Я вот с таким сижу:

$ cat .zprofile
...
# Set the scaling factor for GTK3/Qt5 applications
export GDK_SCALE=2
export QT_SCREEN_SCALE_FACTORS=2
...
$ cat .xsession
#!/bin/zsh -l
# Configure X11 session for this user

# Set the keyboard repeat rate
xset r rate 200 40

# Set the keyboard layout
setxkbmap \
	-layout us,ru \
	-option grp:toggle \
	-option grp_led:scroll \
	-option compose:menu

# Prepare the X root window
feh --bg-center ~/.config/i3/wallpaper.jpg

# Run the screen locker
setsid -f xidle

# Start the WM
exec i3

В начале там у них была переменная QT_DEVICE_PIXEL_RATIO, но потом они решили что это неправильно и всё переписали: https://blog.qt.io/blog/2016/01/26/high-dpi-support-in-qt-5-6/

А главное — ХЗ, как задать один раз и больше не трогать (и дальше уже патчить каждое кривое приложение).

По идее что-то вроде 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 (если многомониторная конфигурация) должны помочь.

qml это декларативка для интерфейса.

Императивно на ней тоже можно писать. Значит отказ от всего остального остаётся возможным.

Императивно на ней тоже можно писать. Значит отказ от всего остального остаётся возможным.

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

Судя по документации, как раз твоя переменная окружения не увеличивает шрифты.

QT_SCREEN_SCALE_FACTORS=2:
http://esxi.z-lab.me:666/~exl_lab/screens/QT_SCREEN_SCALE_FACTORS.png

QT_SCALE_FACTOR=2:
http://esxi.z-lab.me:666/~exl_lab/screens/QT_SCALE_FACTOR.png

Похоже размер шрифта у тебя увеличен где-то в настройках.

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).

Нет, у меня десятка. Алсо, у меня Qt5.11.

Я посмотрел, KDE скалирует через QT_SCREEN_SCALE_FACTORS. Скорее всего, в какой-то момент Qt начал скалировать шрифты без специальных переменных, поэтому QT_SCALE_FACTOR по сути скалирует два раза.