Поддержка системы плагинов для меню включена в Qt 4.8

Да, действительно. Я наврал.

4 дня назад, в понедельник.

Извините. Кто-нибудь может исправить?

да пофик) на характер новости не влияет, а 99.9% прочитавших поверят наслово)

Так привычнее, но зачем тогда слово «Menu»?

Кстати, в таком случае нельзя открыть контекстное меню окна левой кнопкой по значку? (то меню, в котором есть, например, параметр «Поддерживать поверх других»)

Круто, рад за qt.

Отлично!

Хорошая новость. Есть где-нибудь how-to как всё это сделать в текущих версиях?

надо взять патч и пересобрать с ним Qt.

Если убунта, то там Qt сразу с ним.

Если openSUSE, то пакет есть в этом репозитории.

Если Arch, то пакет есть в aur.

Плюсую.

А что, еще пару релизов и попробую снова КДЕ. выглядит как торт

Фу. Фанаты макоси;/

Кстати, в таком случае нельзя открыть контекстное меню окна левой кнопкой по значку? (то меню, в котором есть, например, параметр «Поддерживать поверх других»)

Правой кнопкой на любом месте заголовка окна.

> Appmenu работает через dbus

Как обычно, распространение получило какое-то говно от каноникал. Вместо того, чтобы допилить модулей к globalemenu, который архитектурно намного прямее, т.к. работает через свойства иксового окна.

>т.к. работает через свойства иксового окна.

Нельзя завязываться на иксы. Это тупик.

ЗЫ

Что никак не отменяет ненужности глобального меню.

Это dbus тупик. А иксам еще пахать и пахать.

а что же Вы предлагаете вместо D-Bus (и что вы по существу имеете против?)? у Вас, наверное, имеются собственные наработки высокоуровневого IPC?

> высокоуровневого IPC

Во-первых, нахрен не нужен высокоуровневый IPC, при помощи которого я не могу послать команду программе руками. Прообразом нормальной программной шины, при помощи которой можно рулить агентами шины из скриптов, консоли и вообще как угодно, был dcop, который успешно закопали.

Во-вторых, нахрен не нужна сеансовая шина сообщений, прибитая гвоздями к локальной машине. Мой сеанс работы в общем случае может состоять из множества приложений на нескольких разных машинах. Напрашивается очевидное (всем, кроме идиотов из fd.o) решение — использовать иксовый протокол как транспорт для шины. За одно, упрощается и доступ — нужен только порт для иксов, других портов открывать не потребуется.

В-третьих, гонять туда-сюда и парсить xml — очень хороший способ жрать электричество, нихрена не делая.

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

>Мой сеанс работы в общем случае может состоять из множества приложений на нескольких разных машинах

И часто такое требуется?

> И часто такое требуется?

Мне — редко. А кому-то — постоянно.

>Вместо того, чтобы допилить модулей к globalemenu, который архитектурно намного прямее, т.к. работает через свойства иксового окна.
A Client is a Window with menu context. It receives XPropertyNotify notifications for _NET_GLOBALMENU_MENU_EVENT, and changes _NET_GLOBALMENU_MENU_CONTEXT. To support the specification more efficiently, a map from Path to real actions should be implementated

Лучше dbus. С ним можно, например, перекинуть меню во что-нибудь вроде dmenu.

>Во-первых, нахрен не нужен высокоуровневый IPC, при помощи которого я не могу послать команду программе руками.
Не осилил dbus-send?

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

Не прибита. У гномеров dbus обладает сетевой прозрачностью. Сделанной через одно место, впрочем.

В-третьих, гонять туда-сюда и парсить xml — очень хороший способ жрать электричество, нихрена не делая.

Ты уверен, что через иксы будет быстрее?

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

Ага. Но это решается перетаскиванием части dbus в ядро, к примеру. А с иксами масштабирование отсутствует в принципе (попробуй запустить >256 клиентов на один X.org-сервер)

я был уверен, что в итоге Вы предложите иксовый протокол в качестве транспорта... Вы порете попросту откровенную чушь.
в целях ликбеза:
* D-Bus может быть использован для проброса сообщений между машинами;
* протокол D-Bus не использует xml - там бинарный формат, который в частности поддерживает прозрачную упаковку/распаковку потока данных. xml используется лишь для описания интерфейсов (понятия не имею почему выбрали именно xml, но вижу как минусы данного выбора, так и плюсы). формат данных по эффективности не уступает gProtobuf, но поддерживает только простые типы, тогда как комплексные типы описываются в xml (иной подход к «версионингу» интерфейсов и типов данных).

з.ы. dcop не закопали - именно он и стал прародителем и вдохновителем идеи D-Bus

>Напрашивается очевидное (всем, кроме идиотов из fd.o) решение — использовать иксовый протокол как транспорт для шины.

угу, прибить обмен сообщениями между программами к иксам. ура.

ну, общаться TLW'шками ведь модно (и неважно, что у тебя консольное приложение) ;)

куте? они извращенцы.

а при чём тут кьют? это был тонкий намёк на венду, но, видимо, черезчур тонкий...

> угу, прибить обмен сообщениями между программами к иксам. ура.

У меня что, где-то написано, что иксы должны быть _единственным_ возможным транспортом для шины?

И по факту: сообщения, который относятся к GUI и нужно (логично и правильно) транслировать через иксы. Например, сабж треда.

угу, прибить обмен сообщениями между программами к иксам. ура.

У меня что, где-то написано, что иксы должны быть _единственным_ возможным транспортом для шины?

И по факту: сообщения, который относятся к GUI и нужно (логично и правильно) транслировать через иксы. Например, сабж треда.

это не по факту. далеко не по факту... )