Re: [MiNT] XaAES doesn't deliver button events with evnt_multi()

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On tiistai 11 syyskuu 2012, Helmut Karlowski wrote:
> Eero Tamminen wrote:
> > > I could imagine adding the menubar-option to app-options (sould be
> > > easy) - and also exporting the app-options to the application, so it
> > > can set them itself (maybe not so easy).
> > 
> > Why not window WM_FULLSCREEN option?
> 
> Would also be little effort I guess, in case the menu is not set to be
> permanently on. But what if the user accidentally starts your app and
> don't know how to exit it, and also only can communicate with the mouse
> to the computer?
>
> I won't be responsible for losing life-savind data.

There are so few new Atari applications that I find it extremely
unlikely that user:
* has installed a new application that he doesn't know how to use
  * that application automatically goes to fullscreen on start
* user accidentally starts it while having some unsaved critical data
* and does all that when he doesn't have a working keyboard

How do you even get "life-saving" unsaved data without a keyboard? :-)

In most (all?) non-game apps fullscreen can be toggled only from
keyboard or from some menu entry.  It's not something you can do
by accident, especially when you don't have a keyboard.


> > Fullscreen is a window properly, not menubar a properly.
> 
> The menubar is a also window, when set switchable, so this is no
> difference.
> 
> > App might even have some windows that are fullscreen (image viewing
> > window) and some which aren't (image info window).
> 
> The only change would be to let a window override the menubar wich is
> already possible with
> 
> menu_ontop=0

According to the XaAES wiki page, that's xaaes.cnf file setting
i.e. it:
* cannot be changed at run-time
* must be set by user, app cannot have fullscreen shortcut

XaAES itself having shortcut for fullscreening current window would
otherwise be fine, but many apps already have that partially broken
fullscreen support, that would then be redundant...


> but it will reappear after some time.

Does that send window resize/redraw event to the application so that
it knows e.g. to resize the image it's showing?

While menu/panel autohide may be useful for desktop, for full
windows, I think that's just an annoyance to the user due to
window resizing.


> > I'm not completely sure what should happen if fullscreen window isn't
> > the one on top, but you could either:
> > - make WM_FULLSCREEN window hidden when it's not the topmost one, or
> > - just other windows and menubar on top of it based on the stacking
> > 
> >   order and with the implied clipping.  E.g. desktop is typically
> >   something like that on the bottom of the stack
> > 
> > As it comes to fullscreen windows, as long as user can switch to
> > another window/application (for which AES would then enable menu and
> > show the windows if that window isn't in fullscreen) everything is
> > fine from the user perspective.
> 
> As long as he knows how to use the keyboard.

Fullscreen should be toggled off with the same key users turns it
on, and any menu entry for fullscreen should also show the key used
to toggle it on/off.

Only possible real problem is some game (like mine) that starts in
fullscreen.  For those it should be made clear how to exit from
the program and they shouldn't crash.  Both quite obvious
requirements. :-)

AES should naturally also have some way to switch between applications,
even in fullscreen.  On the other OSes, (Shift-)Alt-TAB is used for
that.


	- Eero