Добрый день

Простенькая задачка, но не удалось сделать "чисто" (пришлось прибегать к dynamic_cast).

Есть пункт меню "Select All" который должен срабатывать по стандартной комбинации Cmd+A (Ctl+A на Вындоуз). Если действие не имеет эффекта - этот пункт должен быть задизаблен. Ну вроде без проблем, сделал так

C++ (Qt)
// virtual
bool MyBaseWindow::CanSelectAll( void ) const
{
// возвращает true если QLineEdit, QTreeWidget или еще что в фокусе
} 
 
// virtual
void MyBaseWindow::DoSelectAll( void ) 
{
// применяет к текущему фокусу 
} 

Ну и зову эти методы когда обновляю меню. Но, как всегда, нашлось  маааленькое но мерзкое исключение. Для одного окна нужна доп возможность - если нажато Alt то должны выбираться все айтемы в дереве, иначе - только те кто не имеет флажка Locked. Необязательно что в фокусе будет дерево - другие контролы там тоже есть. Ну и если Alt нажат то надо в меню поменять текст "Select All + Locked". Как быстро развалилась моя стройная система из 2 виртуалов   Наверное я что-то не так делаю?  

Спасибо

Он имеет смысл только для одного окна, для десятков других никаких locked нет. Хотя в официальной доке apple (якобы) "не рекомендует" модифицировать меню по клавишам - это делают все, и Finder первый

На каждой платформе существует стандартная практика, и лучше ее придерживаться (а не велосипедить). Уверяю Вас что пользователь Мас сразу же облапает меню со всеми Cmd, Alt, Shift - и всеми их комбинациями. Я же не спрашиваю (и не выражаю неудовольствия) почему в линуксе надо чего-то долбить в командной строке - ну значит там так надо.

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

Ну и вообще-то вопрос был о взаимодействии классов 

Ладно, толку все равно не будет (с ответом на изначальный вопрос), давайте покалякаем о принципах ГУЯ  

Пример: в меню есть пункт Plugins в нем "Plugin 1", "Plugin 2"... "Plugin N"  (сколько нашли на диске). Юзер выбрал плагин из меню - он подключился. Возможно плагин открыл свое окно, но может и нет. Все хорошо. Но вот начинаются мелкие пакости: нужно не подключать плагин, а посмотреть его "About". Плагин имеет интерфейс типа GetInformation возвращающий строку описания, но об UI он может и ничего не знать. Понятно что то "About" нужно в году раз - но нужно.

Решение в духе Mac: открываем меню с зажатой клавишей, теперь уже там "About Plugin 1", "About Plugin 2"... "About Plugin N", выбираем, смотрим About. Лаконично и изящно.

Решение в духе Вындоуз.... а затрудняюсь указать Придется наверное тащить "корову на баню" - делать отдельное окно в котором будет список плагинов (чтобы там иметь кнопку About) или вообще отказаться от размещения плагинов в меню. Зато мы точно знаем что делает 99% юзеров    

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

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

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

Злополучное окно-исключение проверило и вернуло true в CanSelectAll, а толку? Tекст в меню меняет не оно само, а вызывающий CanSelectAll. А когда меню открылось - Alt может быть и отпущен до выбора пункта.

"Вызываюший" у меня наследник QApplication. Все изменения в меню выполняются когда юзер нажал в меню бар. Полемика "а нужно ли их менять" беспердметна, по меньшей мере их надо enabled/disabled. Суетиться с этим до открытия меню (всякий раз на изменение данных) явно плохо. С шорткатами там тоже интересно - но то уже др тема.

Рассматривал такой вариант

C++ (Qt)
bool MyBaseWindow::CanSelectAll( QString * txt ) const;
void MyBaseWindow::DoSelectAll( const QString & txt );
 

Ну типа окно может сказать какой текст в меню, а потом его же и использовать. Ну не знаю, как-то смотрится не очень...

Можно добавить еще один метод:

C++ (Qt)
QString itemName() const;

возвращающий строку для пункта меню.