и обладатели «классических» разрешений вдруг стали васянами, которые всем должны… Ты часьто бываешь адекватен, но, блин, иногда я удивляюсь, ты ли это?

Ты потерял нить обсуждения. У обладателей классических дисплеев все прекрасно масштабируется «вниз» до минимальной единицы (пиксель 1:1), я говорил лишь про масштабирование «вниз» ниже размеров физического пикселя. Которое, как видишь, не оправдано.

На втором скрине ещё бы границы вокруг выпадающего Konsole обжать, чтобы стал вровень с пунктами в материнском меню. Была бы вообще красота.

И это доказывает неадекватность, на которую указывает Жамес Холдэ́н. Правильнее было бы масштабировать сверху вниз. Картинка чётче, проблем меньше. А масштабирование вверх всегда будет мылить и все будут говорить «фууу... говенство!!!». И говорить, что «когда же уже здохнут обладатели маленьких разрешений из-за которых мы тут все страдаем...». А надо всего-то взять 200% от имеющегося экрана, и даунскейлить.

Виртуалка меняет разрешение под размер окна автоматически. Гостевые дополнения ОС какбэ. Так что она не может не влазить никак.

Виртуалка меняет разрешение под размер окна автоматически. Гостевые дополнения ОС какбэ.

Как бы:

1. Пока ты эти дополнения не поствишь, у тебя окно не влазит в экран.
2. Не для всех OS имеются гостевые дополнения. Не во всех OS гостевые дополнения умеют изменять разрешение экрана.

Правильнее было бы масштабировать сверху вниз.

А потом ты будешь создавать треды на ЛОРе: почему отрисовка в Qt так тормозит??

P.S. Скейлинг сверху вниз тоже дает мыло, я об этом выше писал.

Каким образом ты пришел к этому выводу? Вайланд получает событие от ядра, определяет, какому окну оно предназначено и отправляет обработанное событие клиенту. Вайланд не открывает никому непосредственный доступ к железу.

Не будет тормозить.

Ты потерял нить обсуждения

Нет ты!!!

Я обладатель классических 1280х800, про которые ты говоришь, что на них без проблем. Так вот, на них с проблем. Это я тебе как нетеоретик говорю.

И вообще, при чём тут нити и смысл?

Сделай

$ QT_SCALE_FACTOR=4 kate -style breeze

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

И да, Qt рисует QtWidgets под иксами на процессоре через XCB.

Я обладатель классических 1280х800, про которые ты говоришь, что на них без проблем. Так вот, на них с проблем.

Вот видишь, даже их уже не хватает для комфорта, а тут про 768p. Потому что ~70% используют 1920x1080 и все затачивают под них,

проданные 2-5 лет назад никуда не исчезли

Парни, там за день до релиза в гит прибежала переводчица из Росы и залила обновление перевода, которое раздуло диалог настроек, панель параметров инструментов и ещё всякое. Я часть успел исправить, а часть — не успел (там тысячекилометровый патч). Вот и вся история.

Ну что? Жди теперь флуда на 20+ страниц про резиновые строки и грамотный ellipsis в тулкитах.

marquee добавлять по вкусу.

Вайланд получает событие от ядра

Через libastral?

Ты почти угадал. Через libinput.

Что мешает любому приложению читать весь ввод через libinput?

Совесть.

Совесть.

Даже root не требуется? Тогда защита Wayland от кейлоггеров - это всё байки и элементарно обходится.

A Wayland compositor typically gets its inputs from the event devices in /dev/input/. For security reasons those devices are normally not accessible by regular users (only root and members of the input group). Wayland compitors are a special case. They typically use libinput in conjunction with libsystemd or liblogind to get access to the input devices for the current session.

So in practice, that means that during a Wayland session, the compositor is the only process that is supposed to have access to the raw input devices. The compositor is responsible for dispatching the events to the relevant clients so that each window only sees the event that are relevant.

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

Но мне пытались объяснить, что из-за этого надо монитор менять. Вот и возник спор.

Кстати, по сабжу.

Поработал - и пока для своих задач не увидел проблем. Для меня готов (ну за вычетом диалога).

Значит не только совесть мешает использовать libinput кому попало.

Нет. Про Африку писал я. На самом деле, его пост ничего «по делу» не сообщает.

И это плохо. Ладно, я уехамши, вечером схлестнёмся. У меня ещё фиги остались.

в дереве. можешь протестировать ;)

$ QT_SCALE_FACTOR=4 kate -style breeze

Не, не то. Там просто огромное всё становится. А надо весь экран виртуально увеличить, а потом сжать до размера реального. В xrandr есть опции scale, scale-from и transform. Вот ими можно что-то такое изобразить. Правда, попробовал, у меня от них вся сессия падает. страный nouveau и доисторицская видяха. Но на армоплатке я такое делал, увеличиваешь, а потом опять сжимаешь. Не заметил сильной нагрузки (не сильно то и больше, чем если просто пускать всё на большом разрешении). Правда, некоторые приложения потом не понимают границ.

Но я всё равно не о том. А о чём хотел сказать, уже не важно.

QT_SCALE_FACTOR=0.8

Шрифты не меняют размер.

Для этого есть отдельная переменная, да :)

Какая?

Поддержка плагинов для Adobe PS

В gimp 2.8 была возможность запускать фотошоповские плагины. Устанавливался пакет gimp-pspi. Потом этот пакет из репозиториев поубирали. Как сейчас есть какое рабочее решение для линукса (gimp-pspi или что иное)?

в дереве. можешь протестировать ;)

Вроде живое. Хотя при моих юз-кейсах это не подвиг. :) Только Enter в диалоге экспорта png работает коряво: вместо нажатия кнопки «Export» переключает первый чекбокс (который в фокусе при открытия диалога).

Кроме PSPI ничего не придумали, а его Тор не обновлял уже очень долго. ХЗ как он щас вообще работает.

QT_FONT_DPI

Кроме

отказ мейнтейнеров GTK принимать патчи в ветку 2.х

кристально чистое нинужно :)

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

На 3dnews появилась статья, посвящённая 25-летию GIMP

Забыл сказать, спасибо.