GlobalMenu и KDE необходимо доработать

Красивые кеды? Скинь пруфпик.

Там дефолтный дефолт, просто панель сверху и глобальное меню.

Если вы пропихнёте это в KDE - то да, полезно. Иначе - нет.

MenuModel - что это такое? Ткни в... или сам объясни пожалуйста.

https://developer.gnome.org/gio/stable/GMenuModel.html

Про MenuModel от разработчиков. Вкратце - протокол для глобального меню в GTK.

хуита ненужно

Интересно, почему это глобальное меню считается удобным?

Немножко поздновато обнаружил, но, я думаю, если предложить помощь гражданам в https://github.com/kotelnik/plasma-applet-active-window-control , многие будут рады.

Потому что место не жрет «ни для чего».

Есть пакет libdbusmenu-gtk (в Gentoo dev-libs/libdbusmenu с флагами gtk и/или gtk3), но с ним ничего не работает. Если можно реализовать поддержку DBusMenu для GTK 2 и 3 плагином, то это, наверное, будет лучше всего. Потому в случае использования транслятора нужны костыли для работы с Wayland.

По крайней мере я был бы очень признателен!

Зачем, если есть appmenu? Скорее, appmenu для qt надо, но мне лень его писать.

Оно отжирает целую панель, даже тогда когда это совсем не нужно. Из приложений, которым всё ещё нужно меню могу вспомнить только гимп и либру. Ради них двоих держать панель? ЦЕЛУЮ ПАНЕЛЬ?

Панель, а точнее, её часть, обычно отжирает заголовок максимизированного окна. А глобальное меню показывается, только, когда пользователю оно понадобилось. По mouse hover, ага.

Что же касается приложений, то любое сколько-нибудь сложное приложение (либру и гимп уже помянули, есть ещё приложения для разработки: Idea, Eclipse, KDevelop..., — и тонны других) использует меню. Даже писанный в строгом соответствии с гномовским HIG'ом Builder постоянно сбивается на menu-like элементы, хоть меню вроде как объявлено пережитком прошлого и вообще негуманным.

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

Чо-та у меня ощущение, что я участвую в том анекдоте про Карузо и телефон.

Но панель в KDE, да, скрывается любая. Там, правда, как топикстартер и отметил, есть проблемы с не Qt-шными приложениями, потому что реализованы две разные модели.

Скорее, appmenu для qt надо, но мне лень его писать.

Хм, appmenu-qt5 ?

Всякому, кто попытается реализовать через модуль для Gtk и dbus, нужно помнить о https://bugzilla.gnome.org/show_bug.cgi?id=784188

Хотя да, казалось, что отправлять меню через dbus — это самый дешевый способ получить решения для всех оконных сред.

Нам надо поддержку меню для GTK приложений в KDE. Про баг знаю, думаю варианты обхода кроме LD_PRELOAD

скинь хоть скриншот. я кде уже лет 5не видел

Из ченджлога KDE Frameworks 5.42:

KWayland

• <…>
• Add explicit AppMenu protocol
• <…>

Из ченджлога Plasma 5.12:

For those who know their Wayland internals the protocols we added are:

• <…>
• appmenu
• <…>

Что это означает для нас?

Даже писанный в строгом соответствии с гномовским HIG'ом Builder постоянно сбивается на menu-like элементы, хоть меню вроде как объявлено пережитком прошлого и вообще негуманным.

Хорош приписывать гномовскому HIG'у то, что тут набрасываешь на вентилятор. Почитай сначала: https://developer.gnome.org/hig/stable/menu-bars.html.ru

Ну, по факту, у них уже была поддержка appmenu, но протокол её ещё улучшит) Кстати, я хочу попробовать сделать в вяленом глобальное меню без композитора, и будет вообще гуд.

Ну, по факту, у них уже была поддержка appmenu, но протокол её ещё улучшит

А что за протокол? Свой внутренний?

Кстати, я хочу попробовать сделать в вяленом глобальное меню без композитора, и будет вообще гуд.

Как я понимаю, единственное, что нужно от графической системы (иксов или Wayland-композитора) — это давать информацию о том, какое окно сейчас активно. Если же приложения научатся сами посылать прослойке сигналы при получении и потере фокуса, то можно будет сделать реализацию глобального меню, не зависящую от композитора; однако в таком случае нужно научить тулкиты новому протоколу. (А, я уже подобное писал в другом треде.)

Тык, давайте разберемся, какое из утверждений кажется Вам некорректным.

1. Множество сложных приложений (примеры в сообщении выше) используют меню
2. Гномий HIG, в целом, не одобряет использование меню, хотя и не запрещает его явно, оговаривая несколько возможных применений
3. В Builder широко используется механизм popovers, который в некоторых случаях (скриншот выше) слабо отличим от настоящего меню.

По первому пункту возражения есть? Я список привел.

По второму имею сказать следующее:

Menu bars increase the vertical footprint of an application’s user interface, introduce a large number of disclosure points, and function as a fixed set of inflexible options. For these reasons, header bars and header bar menus are generally recommended over menu bars, along with other design patterns for exposing controls on demand, such as selection mode, action bars, and popovers.

At the same time, it can be appropriate for complex applications that already include a menu bar to retain it. Additionally, some platforms also incorporate space for a menu bar in their user environment, and a menu model can be desirable for cross-platform integration purposes.

По-моему, все слова про нежелательность меню-баров сказаны совсем недвусмысленно, и нужные части я подчеркнул.

По третьему пункту: расскажите, как описанные проблемы с меню-баром решает подход с хидер-бар, принятый в Билдере. В этот хидер-бар напиханы все те же самые элементы, которые были бы в меню-баре. Но, да, согласен, места стало занимать почти так же мало, как в случае переноса меню-бара в заголовок (кнопки с иконками занимают чуть больше места по вертикали, чем соответствующие текстовые меню), и чуть больше, чем с глобальным меню для распахнутого окна: header bar + upper panel против upper panel.

Я так и хочу (и протокол kde так делает)

А к GTK и Qt это можно прикрутить плагинами? Или только через апстрим?

Гномий HIG, в целом, не одобряет использование меню, хотя и не запрещает его явно, оговаривая несколько возможных применений.

Во-первых, HIG ничего не «не одобряет», это [отсебятина]/[нлп]/[подмнена понятий].
Во-вторых, подмена понятия «меню-бар» на «меню».

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

По третьему пункту: расскажите, как описанные проблемы с меню-баром решает подход с хидер-бар, принятый в Билдере.

Не очень понимаю о каких проблемах идет речь. Но, главная задача хидер-бара предоставить контекст для содержимого окна, решается. При открытии в хидербаре три кнопки: Создать, Открыть, Клонировать. Очевидно, что это удобно и никакой меню-бар тут ненужен и неуместен.
При создании/открытии/клонировании проекта в хидер-баре находятся кнопки быстрого доступа к наиболее востребованным операциям: Сборка, Выполнить, Поиск, скрыть дерево проекта, скрыть терминал. Остальные возможности, доступ к которым требуется не часто, скрыты в сотвествующих группах меню. Очевидно, что это значительно удобнее чем меню-бар, альтернативу тут может составить только tool bar.

Для GTK я буду пилить, а для qt уже сделали разработчики KDE

Ну, а что мешает совместить global menu и такой header bar?

Не представляю как это будет выглядеть. Так?: https://s9.postimg.org/txvuw5ffz/2018-01-24_16-26-18.png

Меню на панели, а headerbar в окне.

Основные операции, это Build, Run и Hide panels. Т.е. по факту будут использоваться только кнопки из header bar или горячии клавиши. Смысл в Меню на панели?

https://s9.postimg.org/wt8y2tgtb/2018-01-24_16-35-32.png

То есть будет реализация DBusMenu для GTK?

Нафига (хотя их уже пруд пруди, и даже две моих)? Не его надо, он только описывает элементы меню. Надо протокол org.kde.kappmenu.

Смысл - красота и чтоб редко используемое не искать.

Нафига (хотя их уже пруд пруди, и даже две моих)? Не его надо, он только описывает элементы меню. Надо протокол org.kde.kappmenu.

Я думал, что там просто DBusMenu. Спасибо за объяснение.

https://phabricator.kde.org/D10461

Гуд. Только к иксам зря привязали.

Может, напишешь им, что собираешься модуль для GTK делать (если ещё не передумал), чтобы они силы попусту не тратили и лучше, если возможно, помогали тебе его пилить?

Не, я такое и собирался писать, но они почти правильно делают. На GTK это геморрой делать.