Re: [MiNT] wind_set(WF_TOPMOST)

[Odd Skancke <ozk@atari.org>]

fre, 14,.04.2006 kl. 14.47 +0200, skrev arnaud.bercegeay@free.fr:
> Hello,
> 
> >  I agree. Not very good to have that kind of thing. Therefore TOPMOST
> > should be used by system-apps only.
> 
> I don't understand very well *why* this should be reserved to system-apps. If i
> don't like an application look'n feel, i just don't use it. I don't want the
> AES to forbid this application for me. Let's take the example of an application
> that uses its own widget rendering in place of the AES rendering (EZEdit for
> example). If i want a text editor to have windows with real AES widget, i just
> chose another editor.

 This is where we differ the most. While I think that GEM app should
NEVER EVER render their own widgets/AES objects under any circumstance,
you think this is perfectly OK. This undermines the work I've done on
Theme handling lately, because there are no restrictions as to what the
applications are allowed to do. Discussing further when our opinions
differ to this degree is almost useless because we want different goals.
I want every GEM app to look the same depending on what Theme the user
wants, while you seem to be OK with total anarchy where no rules apply.
I hope to god I'm wrong about this, tho ;-)

Am I the only one who wants consitency across GEM applications?

> 
> I understand that you may prefer to limit the usage of TOPMOST windows to
> system-apps only on your setup, but then you just have to NOT install standard
> app that uses
> TOPMOST windows... Is there any security reason (?) to limit the usage of
> TOPMOST windows to system-apps ? Or is it just a preference (and then, no
> really reason to impose that choice to everyone).

 There are no security issues related to topmost windows, ofcourse. But
the limitations suggested on topmost windows are not good either. The
argument that topmost windows never gets kbd focus will severly limit
the use of such windows even for system applications. I put a lot of
work into keyboard navigation, and any window which have anything
selectable via mouse should be reachable via kbd too. Then we might as
well go with the exnteded alerts I suggested.

 The real use for topmost windows may be for example the possibility to
put the menubar/taskbar/tasklists etc. anywhere without having to reduce
the workarea of the desktop (one may want to hide both the menu/taskbar,
for exaple). And those will need kbd input too. The focus rules are
different from normal windows ofcourse, but focus should not be
excluded.

> 
> Don't get me wrong, i just want to understand the motivation of that choice. I
> don't say it's a bad choice.

 Now if we can agree on the fact that topmost windows also should be
accessible via keyboard, we are back to what I mentioned before; If apps
use topmost windows whenever authors see fit, we may end up with two
layers of windows. I just dont get why topmost is necessary when there
are other better ways to solve this?

> 
> >  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.
> 
> ... and to be without BUTTON, and to have a total control of the rendering (not
> only a string + icon), and to change the rendering of the "alert" from time to
> time (evolution in real time of the message by alert_draw() ?), and to close the
> "alert" when it is no more usefull (alert_close() ?)... well this is exactly the
> definition of a window set on TOPMOST without focus, i mean the initial proposal
> of Olivier.

 Again, rendering should always be done by the AES. Any form of
application specific window contents (that is, what the application
shows in the work area) should be done in normal windows!

> 
> > Besides, I dont agree that TOPMOST windows never
> > should have focus.
> 
> So we are not talking of the same thing, and it's natural that we cannot find a
> common solution ;)

 Well, I think understand what you want :-) While I very much agree that
these would be very nice, I disagree on using topmost to gain them. You
want topmost windows which never get focus, but have a normal work-area
for applications to display any kind of .. yeah, alert ;-) .. while I
want these to be handled by AES alerts, giving us consistency across the
different applications when it comes to looks/themes. I would agree that
these alerts can contain a normal AES object tree where progdefs are not
allowed.

> 
> You consider the TOPMOST window as a "standard" window wich is just displayed in
> top of other (introduction of a 2nd layer of windows)... and in that case, i
> agree with most of what you post here, and i disagree with what i post here.

 Yes. This is what I think a topmost window should be, but without
application awareness; these should be controlled by the user via
window-context popup, like on KDE.

> 
> In Olivier's idea (and what i consider useful for applications), the "topmost"
> layer of windows cannot give the focus to the application, and it fit very well
> to the usage i tried to describe. And no, this is not alert. This is a kind of
> "user window that contain a high priority message". For example, teatime may
> open a small TOPMOST window somewhere on the screen that show the countdown in
> real time... displayed over the QED full sized window where you are typing a
> text.  Aniplayer may display the title of the next OGG file to be played with a
> small image of the the CD-cover in the TOPMOST window. A destop utility may
> display a "disk near full" message in a TOPMOST window, with the progression of
> the disk free memory in real time... and the TOPMOST window will be closed as
> soon as the amount of free memory on the disk is ok. No timeout to close this
> "alert" window.

 These still look like alerts to me. As a matter of fact, "a user window
that contain a high priority message" sound very much like the very
definition of an alert :-) It looks to me that the only thing stopping
us from agreeing here is that you want the application to be able to
render the contents of these on their own, while I want such messages to
be consistent across the applications.



 Best Regards,
Odd Skancke