Hi, first let me state, that I do not wish KDE to be changed, nor discuss what approach is better. I simply want to disable the menu accelerators or at least take their precedence over shortcuts away. I know why that can be bad, but I really don't care.

Now I have already tried editing kxmlguibuilder, kaction and kaccelerator manager, but to no avail. I think the best place for my change would be somewhere in code where the Alt-press is handled, maybe on the same place that can show the underscores if you have them show only when the alt is pressed (by oxygen settings).

If someone could point me to the best place to make a little change to the source of kdelibs (I guess that's the right package), I would be really thankful.

You'd have to filter events for QMenu's and suck keyPressEvent for anything that might trigger an accelerator. (ie, return true in the event filter for anything that's not up, down, left, right, enter, etc.)

So I tried your suggestion. Returning in KMenu::keyPressEvent does prevent key presses once I have activate the menu.

But IT does not prevent the first activation - i.e. I am in the main window, press Alt-F and the "File" menu is opened. The keypress blocking only applies after this, once the menu is actually in focus.

Ah, that's different - I thought you referred to the accelerators in the (popup)menu, not the menubar.
Traverse the menubar actions and try re/setting shortcuts (to eg. invalid)
You may need to listen to ActionAdded events on the menubar to do this.

I tried the following

Code: Select all

bool KMenuBar::eventFilter(QObject *obj, QEvent *ev)
{
if (ev->type() == QEvent::ActionAdded) {
         QActionEvent* aev = (QActionEvent*)ev;
         aev->action()->setShortcut(0);
}


I am not sure about the argument of setShortcut, but I could not find any constant for no shortcut. Does not even remove shortcuts from menus.

Anyway, are you sure about this approach? Because I do not want to change shortcuts (i.e. those written next to menu items ), I want to disable menu accelerators, i.e. "underlined character" ones.

The accelerator of the QMenuBar actions are "just" the (window) shortcuts on the QAction for the resp. QMenu.

This is NOT the same as with the accelerators in the QMenu (the popups)
The shortcuts listed there are window or application wide action shortcuts (to this action) just as the QMenu::menuAction() is the window wide shortcut to the (popup) QMenu with the action being (randomly) added to a menubar.

Just listening to QEvent::ActionAdded will however likely not do - esp. not if you install the eventfilter after the GUI has been constructed.
You'll vermy most likely have to initially traverse the windows menubar to kill all action shortcuts.

To do this, you can either (likely)
QAction::setShortcutContext(Qt::WidgetShortcut); // only when the menubar has the focus, ie. never.
or
QAction::setShortcut(QKeySequence::UnknownKey); // equals QAction::setShortcut(0) but is more explicit

So if the monitoring of ActionAdded is not the place, then where to do this? Since I want to do this in kdelibs globally, I cannot just calla function to traverse the menu actions, I need some injection point for it...

Well, if that is actually KMenuBar, you do not want to use an event filter, but reimplement ::event() instead (you could install the eventfilter on the object itself, but that's silly unless you wanted to kill another eventfilter)

Reimplementing the event should however be sufficient.

luebking wrote:Well, if that is actually KMenuBar, you do not want to use an event filter, but reimplement ::event() instead (you could install the eventfilter on the object itself, but that's silly unless you wanted to kill another eventfilter)

Reimplementing the event should however be sufficient.

That worked!

However, this only disables the actual menu action, but the "Shortcut is ambiguous" dialog is still there
So I still cannot use Alt+ shortcuts properly.

If you can, delay assigning "your" shortcuts until the menu has been build (eg. wait for the show event or so)

No idea what you're doing there, but maybe keep in mind that users might be confused if "Alt+F" or "Alt+E" do not behave in the (harmless) way they expect and could be PrettyPissed™ if they just called "Alt+F(ormat Disk)" or "Alt+E(rase)" instead.

luebking wrote:If you can, delay assigning "your" shortcuts until the menu has been build (eg. wait for the show event or so)

No idea what you're doing there, but maybe keep in mind that users might be confused if "Alt+F" or "Alt+E" do not behave in the (harmless) way they expect and could be PrettyPissed™ if they just called "Alt+F(ormat Disk)" or "Alt+E(rase)" instead.

I am not doing that i an application, I just want to disable it system-wide for my own purposes. That's why I am looking into changing kdelibs themselves.