Version: unknown (using 4.2.90 (KDE 4.2.90 (KDE 4.3 Beta2)), Gentoo) Compiler: x86_64-pc-linux-gnu-gcc OS: Linux (x86_64) release 2.6.30-rc8-dirty IIRC there once was an option to automatically move the mouse pointer over the default button in modal dialogs (at least in win this option was provided by certain mouse drivers).. This helps reducing unnecessary mouse movement already but there might be an even better way: place the appearing dialog in such a way that the default operation button is centered below the mouse cursor. If you happen to f.e. want to download a couple of links in your home dir, to click save as then ok, that becomes tedious quickly. Of course you could just press return twice but this would be a nice innovative way and perhaps less subjectively interruptive. Furthermore, i personally prefer to have a direct visual connection between operation text and action engagement... comments ne1?
and kwin knows where the default button in a dialog is, because...? this can be done from within the app (i.e. the dialog can request to move itself to some position) however i remember i recently tried that and the disappointing result was that the dialog (a modal one, though) didn't make it up to the top of the window stack (some stealing prevention? don't know) if there's no serious reason for this, maybe kwin could treat dialogs that requested a specific mapping position as if they did not?
Well i wouldn't know how - but there surely must be some way to find the pixel position of the initially selected button and force move the window there?
yes, but /only/ from within the application (which then doesn't need to do some querky heuristics but of course knows which button is marked "default") - KWin related payoff (inoperative raise) as mentioned above. The WM has /absolutely/ NO idea about the window content. Overmore this should really be handled by the application, as it can easily lead to accidental clicks (user clicks into a window, but in this moment a dialog pops up and moves the "format my HD no" button right under the mouse - ouch! So this needed to be accomplished with a timer that keeps the button disabled for a while to ensure the user knows what he's about to click or the dialog must be absolutely sure that an accidental click won't do anything (in which case the default button could have been spared... ;-) Anyway, that's an app design issue: What you really want is to DnD the link into your filebrowser. Konqueror and Dolphin support this. If you want to use another Browser/FM combination, that doesn't support this right now, you'll have to file a bug there :-( (I'll mark this bug INVALID, as what you want is not achievable from KWin (or any WM) - by no means. This does not mean you don't have a valid wish for a better workflow, but you'll have to redirect this bug - to some app or kdelibs/kfile for the filedialog - to get it done, sorry)