Re: [MiNT] wind_set(WF_TOPMOST)

[Odd Skancke <ozk@atari.org>]

fre, 14,.04.2006 kl. 11.37 +0200, skrev arnaud.bercegeay@free.fr:
> Hello,
> 
> First, I don't think the TOPMOST feature described by Olivier needs a control by
> the AES (to authorise or not this feature).
> 
> There is a major restriction for TOPMOST windows: they don't give the focus to
> the application. So, i'm sure standard applications won't use TOPMOST windows in
> place of standard windows. In other words, TOPMOST windows will only be used
> when applications really need TOPMOST windows (very particular and rare uses).
> 
> Second, i don't think this is a feature related to system-application vs
> not-system-application.
> 
> For example, the "list of task" window of a task manager may use a TOPMOST
> window, but other windows of a task manager (for example the "about..." window,
> or the "config" window) should not be a TOPMOST window.
> 
> Another example: a great ;) application like teatime may use TOPMOST window.
> First, teatime open a standard window, here you choose your kind of tea ("green
> tea / 3mn" for example), and hit the "GO" button. Teatime then starts a 3mn
> countdown, and when the countdown reaches 0 (tea is ready), i'd like teatime to
> display a TOPMOST window with the message "your tea is ready" inside. This
> window will be automatically closed by teatime after some seconds (without any
> action of the user), or when the user click in this window.

 you just described an alert :) We currently have x number of alert
icons (lets regard those as alert types). We can extend these existing
alert types to include one where focus isnt changed when the application
sets a close-window-timeout for example.

> 
> For that example, the TOPMOST window is the best choice, because if you are
> editing some text in QED for example, when teatime opens its TOPMOST window,
> the focus stays on QED, and you may keep typing your text without any trouble.
> A standard window doesn't fit to this need (QED lost the focus). A form_alert
> doesn't fit to this need (QED lost the focus).

 No alerts as we have now. But for this exact example, alerts should be
used. If this is not an alert, I dont know what is :) As a matter of
fact, only one more parameter is neede to the existing form-alert call
is needed, a timeout value. When set, focus dont change. If timeout is
0, normal alert window is performed.

> 
> And as a user, i don't want the AES to ask me if teatime may open a TOPMOST
> window when teatime opens its TOPMOST window, because QED will lost the focus
> which is exactly what i don't want... and i don't want to put all the
> applications that may use TOPMOST windows in aes.cnf file (that doesn't make
> sense to put there *all* my applications).

 I agree. Not very good to have that kind of thing. Therefore TOPMOST
should be used by system-apps only. In the case a system-app, which is
not authorized by the user (lets say he's testing another taskbar than
he ususally uses), the AES asks to authorize it. I think that ONLY
'system-apps' need to know of and use TOPMOST. If the user wants to make
a normal window TOPMOST, he can do so via the window-context popup.

> 
> To sum up, the TOPMOST feature should not be reserved to system applications
> (this is not the right criteria), and i don't think we need to limit the usage
> of TOPMOST windows because there is a major restriction (don't give the focus)
> that guaranties that developpers won't use TOPMOST windows in place of standard
> windows. TOPMOST window are not "super" windows, it's just another kind of
> windows.

 Here I do not agree. I think the examples I've seen so far belong to
the 'alert' group of windows, or situations where the user would choose
it to be TOPMOST. Besides, I dont agree that TOPMOST windows never
should have focus. I think they should have focus along the lines of
normal windows when the user chooses to bring it to the top. That is,
click on it to change focus. TOPMOST windows should just 'float', and
not _change_ focus when opened. But it should be able to have focus when
the user wishes it to.


 Best Regards,
Odd Skancke