Re: [MiNT] XaAES, TosWin2 closed and wrong active window

[Vincent Rivière <vincent.riviere@freesbee.fr>]

On 12/02/2013 10:34, Eero Tamminen wrote:
> > 1. You want toswin to untop when it's last window is closed.
> >
> > 2. You want toswin to not untop when it's last window is closed, but it
> > is a dialog.
> >
> > What do you want to do with the still topped toswin after you closed the
> > dialog?
>
> Although 2) is a less common case, I think it's actually a valid use-case,
> regardless of a program.
>
> One may want to set/change some options before opening a window which
> contents those options concern.

Actually, there are 2 scenarios.

1) The "usage" scenario.
- The user double-clicks on a .tos program
- The program runs in a TosWin2 window
- The program exits
- The user is back to the desktop
- Then the user can run another .tos program, use the dekstop, etc.
This scenario is identical to normal desktop usage on single TOS.

2) The "configuration" scenario
- The user swiches to TosWin2
- Then he navigates in the various menus and dialog boxes to configure 
TosWin2 the right way (ex: switch tw52/tw100 mode, etc).

With the current configuration, 1) is OK, but 2) is not.
I think that 1) is more important, so the current default configuration 
is probably good.
To solve 2), the solution of keeping a shell opened while navigating in 
the dialog boxes is not very user friendly, but it works.

> This is even worse with programs that show (potentially windowed) dialogs
> at startup, which need to be OKed before they open any windows.  Clicking
> through a startup dialog shouldn't untop the program...

Very true.
For example, when running XaAES with the EmuTOS VDI, at startup QED 
displays a dialog box complaining about missing font selector, etc. I 
some cases, I saw QED losing the focus when clicking OK in that initial 
dialog. I'm not sure how it behaves now with the default configuration, 
though.

--
Vincent Rivière