Re: [MiNT] XaAES Bug: Toolbar attached to window eats all keyboard events

[Jo Even Skarstein <joska@online.no>]

On Sun, 2013-12-29 at 22:10 +0000, Helmut Karlowski wrote:

> > software. Because if the toolbar really is a dialog it will also eat the
> > cursor/tab/space/undo keys due to keyboard navigation.
> 
> Sure it does. The possibility to unfocus the toolbar by mouse needs to be  
> implemented (and maybe vice versa focus the toolbar by keyboard somehow).  
> I guess there is no way for the client to do this itself.

But wouldn't this problem almost exclusively affect future applications?
I don't know of any current applications that combines XaAES dialog-type
toolbars with a work area. So for maximum flexibility I think that
(un)focusing the work area (we're talking about keyboard events only,
right?) should be left to the application. Because it might not be
correct to automatically move keyboard focus from the toolbar in all
cases where the user click inside the work area.

Two simple examples:

1. A text editor with a toolbar in each text window. In this case it
would be correct to move keyboard focus to the work area whenever the
user clicks inside it.
2. A draw program with a toolbar in each image window. It would probably
not make sense to move keyboard focus from the toolbar whenever the user
draws something in the work area. It would be more user friendly to keep
keyboard focus in the toolbar constantly to allow fast and easy access
via keyboard navigation.

I suggest a simple extension to wind_set() to either move keyboard focus
"manually" or to specify how the focus should be handled.

Jo Even