Apache OpenOffice (AOO) Bugzilla – Issue 105676
Pass app-wide shortcuts on, also in open dialogs
Last modified: 2011-03-15 16:03:59 UTC
let ctrl-<keycode> stuff pass dlg keyboard handling, to permit global application-wide shortcuts also in open dialogs. This was added specifically for Impress, as the animation tool pane is internally implemented as a dialog - if that got focus, e.g. ctrl-s just silently doesn't work (and yeah, sometimes even Impress saves quick enough that I did _not_ notice there was no save happening at all).
Created attachment 65200 [details] Proposed fix
@fl: consider adding this to your renaissance query, too. We're coming from Impress here.
fl: could you please comment on this patch ? Go or no go ?
@fl: ping ? you're ruining gsl's IIT statistic.
adding mba,nn,cl on CC the consequence of this would of course be that e.g. saving can be done during an open dialog. This and similar actions might produce yet unknown reentrance problems which would have to be fixed; what's the application developer's general take on this ?
We allow "global" application-wide shortcuts to work in non-modal GUI elements like ModelessDialogs or FloatingWindows. If it required special code in Impress to make that work then probably because Impress didn't use the sfx classes that implemented that feature. IMHO we shouldn't allow that in modal dialogs. In case a dialog is modal by intent it can be a disaster to allow for global shortcut processing. If the dialog is just modal because of laziness, perhaps the best fix for the problem would be to convert the dialog into a modeless one. Once we have got rid of all modal dialogs that don't need to stay modal, this issue will be fixed in passing. In short words: "modal" is "modal" and processing shortcuts in application code will be a tunnel through this modality.
mba's argument seams reasonable to me. So that would mean this patch is not the desired solution for the problem at hand. Agreed ?
which sfx class implement that feature? -1 for the patch. A application wide shortcut could be any combination, not only ctr-<keycode>
Here's the implementation for the class SfxDockingWindows: long SfxDockingWindow::Notify( NotifyEvent& rEvt ) { if ( rEvt.GetType() == EVENT_GETFOCUS ) { // snip code } else if( rEvt.GetType() == EVENT_KEYINPUT ) { if ( !DockingWindow::Notify( rEvt ) && SfxViewShell::Current() ) return SfxViewShell::Current()->GlobalKeyInput_Impl(*rEvt.GetKeyEvent()); return TRUE; } // snip more code return DockingWindow::Notify( rEvt ); } While checking this code I discovered that nowadays it handles *all* accelerators. It seems that the behavior has been changed quite some time ago (perhaps OOo2.0 when SFX lost control over accelerator configuration).
@mba: yep, good point - so e.g. sd/source/ui/animations/CustomAnimationPane.src sets DialogControl = TRUE, and parent windows don't, to make vcl handle focus/tab travelling in that pane, presumably. Unfortunately that leads to the described behaviour of eaten global shortcuts - is there an easy filter I could use in one of the parent windows' Notify method, to weed out app shortcuts (and only those)?
removing patch flag
As I wrote, I opt for not hacking something into modal dialogs but instead of that converting them to modeless ones. In that case it seems that there is no *basic* problem with allowing to handle all shortcuts. But allowing for shortcuts while a modal dialog is executed is asking for troubles. The problem is not the dialog itself, it's the code stack calling execute().