Выбрать всех

[Racheengel]

Я бы сделал так: само приложение ничего не знает про пункты меню.
Когда конкретное окно активируется, оно само добавляет в меню свои экшены (Select All etc).
Пока окно активно, оно имеет доступ к экшенам и может их модифицировать при необходимости.
При деактивации окна, оно подчищает экшены из меню.
Таким образом можно реализовать очень гибкое поведение.

[Old]

Я бы сделал так: само приложение ничего не знает про пункты меню.
Когда конкретное окно активируется, оно само добавляет в меню свои экшены (Select All etc).
Пока окно активно, оно имеет доступ к экшенам и может их модифицировать при необходимости.
При деактивации окна, оно подчищает экшены из меню.
Таким образом можно реализовать очень гибкое поведение.

IMHO, лучше все таки, что бы меню формировалось централизовано, например, главным окном приложения. А активное окно отдавало бы указатели на свои QAction, которыми и управляло самостоятельно (дизаблило, изменяло текст и т.д.). Тогда одни и те-же экшены можно было бы использовать при формировании менюбара, настройки тулбара, формировании контекстных меню.

[Igors]

Да нет, вполне норм. Надо только методу переделать название на более логичное.

Код:

std::tuple<bool /*can select*/, QString /*text*/, QVariant /*hint*/> MyBaseWindow::selectionInfo() const;
void MyBaseWindow::DoSelectAll( const QVariant & hint );

Можно вместо тупеля структурку передавать.

Да, такого можно нагородить много. Но меня смущает что вся эта арматура заряжается на один-единственный частный случай с Select, Вряд ли тут будет какая-то движуха в течение неск лет. Зато в др айтемах она возможна (напр CanCopy, CanPaste и др) - там очень хорошо показать чего копируем/пастим

Я бы сделал так: само приложение ничего не знает про пункты меню.
Когда конкретное окно активируется, оно само добавляет в меню свои экшены (Select All etc).
Пока окно активно, оно имеет доступ к экшенам и может их модифицировать при необходимости.
При деактивации окна, оно подчищает экшены из меню.
Таким образом можно реализовать очень гибкое поведение.

Окно может всяко-разно менять текущие данные, напр тот же select, вот он был - и уже нет. Поэтому порешать все в момент активации окна не удается. А бегать всякий раз апдейтить меню - нереально. Да и действия могут быть перекрыты напр floating окном или вообще модальным диалогом. 

[Igors]

Да, забыл напомнить: вызовы CanSelectAll и DoSelectAll разорваны по времени. Получить какие-то данные от CanSelectAll можно, но их придется где-то хранить, а главное - обеспечить их "релевантность". В моем варианте QString - текст самого пункта меню

[panAlexey]

Ну и что? Увидит 2 пункта выбора - чем это мешает? По крайней мере не надо будет ему додумывать, что "а тут же еще альт нада зажать..."

А вообще в меню 99% населения мышом лазят, без альтов и шифтов

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

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

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

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

сморим на firefox, пункт меню дополнения и делаем так для всех платформ.
там список плагинов с кнопками управления.

[Igors]

сморим на firefox, пункт меню дополнения и делаем так для всех платформ.
там список плагинов с кнопками управления.

Плагины всякие бывают, не всегда это что-то типа "службы". У меня это просто "объект" (напр сфера) который создается на ходу (а не грузится из файла). Юзер добавит его 5 раз - получит 5 новых сфер. Что ж он, 5 раз должен окно открыть? И включить-выключить никакого нет, удалит все созданные сферы, ну dll'ка и выгрузится.

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

[Авварон]

Окно может всяко-разно менять текущие данные, напр тот же select, вот он был - и уже нет. Поэтому порешать все в момент активации окна не удается. А бегать всякий раз апдейтить меню - нереально. Да и действия могут быть перекрыты напр floating окном или вообще модальным диалогом. 

Йа писал в свое время манагер экшнов. Вкратце, идея была такая - есть построенное меню в экшонами. Все экшоны имеют ид (например, "copy", "selectAll").
Некоторые виджеты имеют добавленные в них экшоны (QWidget::addAction). Если нам нужен функционал копипасты, добавляем в виджет 2 экшона "copy", "paste".
Далее, при смене фокуса пробегаемся от текущего виджета в фокусе в верх по дереву и соединяем экшоны из виджетов с экшонами в меню. Те экшоны, которые в меню остались без соединения "гасим" (дизейблим или прячем (setVisible(false)).
Ваш функционал реализуется следующим образом - пихаем в меню два экшона - "selectAll","selectAllAlt". И в виджет два экшона. При показе меню проверяем флажок что экшон "альтернативный" и прячем или показываем.
Но это много кода писать.

[Igors]

Если нам нужен функционал копипасты, добавляем в виджет 2 экшона "copy", "paste"...
...И в виджет два экшона.

Ой нет, такой хоккей нам не нужен

Йа писал...

- Ванька!
- Я!
- Это ты костер развел?
- Я..
- Туши быстро, немцы увидят, прилетят
- Йа-Йа