Выходит X.Org Server 26.1 RC1 с новыми возможностями

Я правда не знаю как это сделать в Qt, но знаю как в [старом] GTK. Там тоже можно переопределять реакцию на клавиши но тоже будет громоздко, хотя и проще чем в Qt, ибо всё-таки обычный Си, а не плюсы.

Это уже субъективщина. Мне вот например, проще читать методы классов, чем имитацию ООП с помощью глобальных функций и указателей. Но если понадобится – сделаю и на обычном Си, по большому счёту, что коллбэк подсунуть, что метод перекрыть, разница невелика. В целом же подозреваю, что на Qt, что на GTK, трудоёмкость будет плюс-минус одинакова.

Но дело-то даже не в этом.

Стрелки перемещают фокус ввода, а курсор в поле появляется только когда начинаешь в него что-нибудь вводить. Далее - enter для подтверждения введенного в воле содержимого или esc в случае отмены - и тогда стрелки снова перемещают фокус.

А если мне надо в уже введённом поправить пару символов, для чего стрелками подогнать курсор в середину поля? Тоже Enter жать? А с выпадающими списками ещё хлеще, они явно встречаются чаще спинбоксов, и если на каждый придётся жать Enter, чтобы поменять значение? Тут далеко не очевидно, что проще и быстрее – жать серии Tab вперёд и Shift+Tab назад или постоянно переключать в голове контекст «вот сейчас у меня стрелки работают по одному, а сейчас по-другому, вот сейчас для подтверждения достаточно Enter, а тут нужен Ctrl+Enter». Хотя вимерам, наверное, зайдёт. Я вот не вимер, хотя заочно их уважаю. :)

А ещё есть подсвечиваемые горячие клавиши (с альтом), они сильно облегчают клавиатурную навигацию.

Снимать руку с клавиатуры, хвататься за мышь и тыкать в поле ввода чтобы ввести в него текст

Не занимаюсь таким. :)

В общем, это точно не вина и не особенность Qt. Qt здесь просто следует устоявшейся методике. Можно, думаю, и для Qt налабать библиотечку для «навигации с режимами», просто мало кто этим вопросом задавался.

Кстати, прямо сейчас в линуксе стрелки используются для перемещения между полями ввода в Midnight Commander

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

Аналогично формы ввода работали во многих коммерческих продуктах фирмы Borland.

Ну на Turbo Vision я когда-то писал довольно много :))) но что-то не помню, чтобы мне там приходилось контекст стрелок переключать и от обычного Enter-а как подтверждения всего окна отказываться. Впрочем, сильно не настаиваю, больше 30 лет всё-таки прошло. :) И я думаю, что текстовый режим всё-таки накладывает свою специфику, некоторые вещи там делаются проще, чем в графике, некоторые наоборот.

но судя по неудобности интерфейса очень многих любительских программ - что-то таки мешает

Ок, давайте смотреть профессиональные программы, например qbittorrent. Такой же интерфейс повторить несложно без большого опыта в Qt.

А вы лепите интерфейс как получится из готовых кусков, которые или не оптимальны именно в силу универсальности

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

Снимать руку с клавиатуры, хвататься за мышь и тыкать в поле ввода чтобы ввести в него текст - это абсурд с точки зрения эргономики

Да не надо никакой мыши — tab/shift-tab работают везде.

В целом же подозреваю, что на Qt, что на GTK, трудоёмкость будет плюс-минус одинакова.

Согласен. Одинаково монстрообразно и разбираться как это сделать придется долго.

А если мне надо в уже введённом поправить пару символов, для чего стрелками подогнать курсор в середину поля? Тоже Enter жать?

Да, редактирование поля - после enter. Появляется курсор и редактируйте.

что проще и быстрее – жать серии Tab вперёд и Shift+Tab назад или постоянно переключать в голове контекст

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

А ещё есть подсвечиваемые горячие клавиши (с альтом), они сильно облегчают клавиатурную навигацию.

Да, это тоже удобная штука, но только если пользуешься программой чуть ли не ежедневно и их помнишь. Да еще в каждой форме они свои. Прикол: однажды у ментов видел программу где в меню был пункт «ДокуМент»:) По Alt-M и срабатывал.

Qt здесь просто следует устоявшейся методике. Можно, думаю, и для Qt налабать библиотечку для «навигации с режимами», просто мало кто этим вопросом задавался.

Эргономикой пользовательского интерфейса перестали задаваться с середины 90х. Основной упор был сделан на «красивость» и более-менее понятность для полных и абсолютных чайников, каковых было большинство во времена начала массовой компьютеризации. Сейчас на рынок труда уже выходят дети тех чайников, а интерфейсы «по инерции» делаются под чайников. Исключения есть но не частые.

Ну на Turbo Vision я когда-то писал довольно много

В турбовижн как раз эргономику интерфейса уже изрядно испортили. Я не просто так назвал Turbo C 2.0 (саму IDE, уж не знаю на чем она написана ибо закрытая).

А у упомянутого tab/shift-tab ноги растут из очередного гениального творения корпоратов - IBM Common User Access. Эти гении решили что интерфейс всех программ должен быть одинаковым независимо от их предназначения и родили некий «стандарт» который начали пропихивать абсолютно также как systemd и wayland сейчас. И программ с эргономичным интерфейсом стало меньше. Более того, те кто пришел в IT позже - уже и не знали что может быть иначе чем с некоторого момента было объявлено «общепринятым». Да не «обще-» , а конкретно IBM. А так как в те времена IBM и MS плотно сотрудничали - то эти идеи проникли в винды и стали считаться «общепринятыми».

И я думаю, что текстовый режим всё-таки накладывает свою специфику, некоторые вещи там делаются проще, чем в графике, некоторые наоборот.

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

давайте смотреть профессиональные программы, например qbittorrent.

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

они глубоко кастомизируемы

Только кастомизация непомерно сложна для непрофессионала, а умолчания антиэргономичны в большинстве случаев. Так-то да, я не спорю, что профи может сделать эргономичный интерфейс. Но и профи в большинстве случаев не заморачиваются ибо следуют общепризнанной идеологии «тяп-ляп и в продакшн». Им за качественную кастомизацию под задачу - не доплачивают, они и не заморачиваются.

tab/shift-tab работают везде.

И везде это дико неудобно. Ну допустим если полей ввода три-пять штук это еще можно потерпеть. А если два-три десятка еще и в несоклько столбцов - проклянешь разработчиков пока до какого-нибудь предпоследнего дощелкаешь так.

Я бы не назвал ее интерфейс сильно удобным для управления с клавиатуры

В Qt хватает инструментов для клавиатурно-ориентированного UX: всякие QShortCut/QAction, настройка фокуса, порядка переключения виджетов и т.д.

В любом случае, я не пытаюсь продать вам корову, просто из крупных гуи-библиотек я пробовал еще GTK3, и Qt на голову удобнее с точки зрения непрофессионала. Тем более, там помимо гуи еще куча всего есть.

Сейчас на рынок труда уже выходят дети тех чайников, а интерфейсы «по инерции» делаются под чайников.

Так это ещё большие чайники, которые только тыкать пальцем в экран умеют. Так что ждём ещё большей деградации итерфейсов. Хотя чо там ждать, можно и сейчас заметить как гуи искалечено под пальцетыкалок.

Так это ещё большие чайники, которые только тыкать пальцем в экран умеют. Так что ждём ещё большей деградации итерфейсов

К сожалению, вы вполне можете оказаться отчасти правы :( Но всё же сенсорный экран - это в какой-то степени совмещение экрана именно с клавиатурой. Нет такой уж большой разницы какие кнопки нажимать - физические или нарисованые. Разве что для работы (а не развлечений) экран надо делать нормальных размеров, а не смартфонных.

В Qt хватает инструментов для клавиатурно-ориентированного UX

Ничуть в этом не сомневаюсь. Но вы сами выше написали «сделать можно но будет громоздко».

Увы - уровень сложности и Qt и GTK такой, что непрофессионал будет очень долго разбираться с тем как сделать именно нужный ему интерфейс, а не «как получится». Если вообще разберется. Особенно учитывая что Qt это еще и плюсы. В GTK хотябы достаточно обычный Си.

В GTK хотябы достаточно обычный Си.

У GTK (ну если быть точным, то GObject/GIO) API поэтому и кажется на первый взгляд страшноватым, потому что проектировался изначально под написание привязок к нему. Соответственно GTK приложения можно писать на дофига языках. Причём, исключая очевидный Си, в то что умеет генерировать GIR на основе интроспекции вообще привязки создаются в автоматическом режиме (Vala, Python, Lua, JS, Go, Rust) и ни от кого ничего не требуется.

привязки создаются в автоматическом режиме

Пытался смотреть такую автоматически нагенерированную привязку GTK к Ada так как это мой любимый язык программирования. Увы - автоматика эта получается плохо из-за существенного отличия подходов к стилю написания кода в Си и Аде.

Что-то не помню я, чтобы GIR генерировал для Ada. Опять-же, насколько я смог наяндексить, кто-то вручную их пишет, они не автоматические.

GIR - прикольная, на мой взгляд, штука, которая позволяет с нулевыми затратами создавать привязки для языков, которые она поддерживает. Ест-но для всего стека она это умеет (иначе какбы GNOME писали на JS). Мне например, дико нравится, что написав либу на Сишке и заюзав GIR, я могу сразу (вот вообще без затрат), вокруг неё построить UI на Vala(ну или на чём там нравится) или апплеты на JS для GNOME, интегрировать с прогой на Rust-е и т.д.

Понимаю, что GNOME стек хейтить модно, но ИМХО вот именно GIR - это как-раз очень удобная его киллер-фича.

Читаю новость.

удалена поддержка системы сборки autoconf/automake

«Неужели сделали человеческий make!!! Неужели человечность ещё есть?»

теперь используется meson

*Мем с кричащей чайкой*

Не знал про xforms, спасибо!

В портах FreeBSD и OpenBSD есть, а также в SlackBuild.

Что-то не помню я, чтобы GIR генерировал для Ada. Опять-же, насколько я смог наяндексить, кто-то вручную их пишет, они не автоматические.

Я вовсе не утверждаю что виденную мной привязку GTK к Ada генерировал GIR, но производила она впечатление именно «нагенерированной».

Понимаю, что GNOME стек хейтить модно

Не скажу про весь «стек», а конкретно GTK на лично мой взгляд всё же более человекообразно чем Qt. Правда я пытался разобраться в GTK почти два десятка лет назад, вполне может быть что с тех пор хуже стало. В итоге я тогда сделал свою программу на этом http://xforms-toolkit.org и успокоился.

Библиотек для написания гуя существенно больше чем думают те кто не пытался искать. Есть например это: https://github.com/Immediate-Mode-UI/Nuklear Тоже весьма простое. Вот еще один гуй - бразильцы сделали: https://www.tecgraf.puc-rio.br/iup/

Так как оно всё небольшое то можно прилинковать к своей программе и избавиться от необходимости отдельной установки разделяемой библиотеки в систему. Заодно и кастомизировать как угодно не боясь наехать на какую-нибудь несовместимость с апстримом.

Еще гуи:

https://github.com/rxi/microui https://nappgui.com/en/home/web/home.html https://github.com/nakst/luigi

https://github.com/Immediate-Mode-UI/Nuklear

Выглядит неплохо, но если копнуть глубже, то как-то грустненько. В Makefile строка на 600 знакомест, в самом коде с ходу ничего такого вопиющего не нашёл. Плюс, сделал «Written in C89 (ANSI C)», а в сборку затащили зависимость от python – отвратительно.

https://www.tecgraf.puc-rio.br/iup/

Судя по всему частично проприетарщина, в исходниках много бинарников.

https://github.com/rxi/microui

Поверх sdl2 сделан, плюс, opengl2, как я понимаю обязательно нужен. ИМХО, для виджетов оверхэд. Но может ошибаюсь.

https://nappgui.com/en/home/web/home.htm

Фу, cmake так ещё и gtk.

https://github.com/nakst/luigi

Кажись недоделано и заброшено. Но зато по зависимостям не такая катастрофа. :^)

Понятно что свои недостатки есть везде. В xforms они тоже есть.