Re: [MiNT] wind_set(WF_TOPMOST)

[Odd Skancke <ozk@atari.org>]

fre, 14,.04.2006 kl. 22.26 +0200, skrev arnaud.bercegeay@free.fr:
> Hello,
> 
> >  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,
> 
> oooh... calm down please :) You misread my sentence (or i miswrote it ?).

 :)

> 
> > Am I the only one who wants consitency across GEM applications?
> 
> No ! I am too !

 Ok, that releaves me somewhat.

> 
> I was just asking about the "filter" feature.
> 
> I retry: we state that GEM applications should use AES widgets. Now, if an
> application (EZedit) tries to open a window with no attribute, the AES may
> think it is because that application will use built-in widget instead of AES
> widgets... and so, the AES should refuse to open such window ? This is an
> illustration of filtering to introduce in AES if we follow the "filter against
> dirty apps" path.

 No, this is ofcourse not controllable by the AES. But such programming
shows a lack of respect for the system it runs on, and the users of the
system on which it runs. Such applications break the defined behavour of
GEM windows, leaving the user confused because the
themes/windows/behaviour adjustments he made dont apply. I think such
programming should be forbidden. Ofcourse, the next argument I'll hear
now is "If you dont want to run it, use something else"...

 Sure you want consistency across GEM applications? Because talking
about ezedit as a valid example to get a point across shows the total
opposite opinion.

> 
> >  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 see. We still speak  about 2 (or 3) different types of stuff here.
> 
> I'll try to summary what i understood.
> 
> the 3 uses-case i see are :
> 
> 1. private system windows (for popup, menus...), internally managed by the AES.
> For me, it's something private to the AES and it's out of the scope of this
> discussion (which is related to public API between AES and applications)
> 
> 2. window of special application to be always rendered on the top of the screen
> (task bar).
 And windows the user wants to 'float' via window context popup.

> 
> 3. "high priority information window".
 Nothing but a fancy collection of words describing Alerts ;-)

> 
> 
> For me, cases 2. and 3. are well done by Olivier proposal: a window always drawn
> on top, without kbd focus.

 Class 3 windows are normal windows being TOPMOST that never gets
keyboard focus, right? You never answer me explaining what I thought you
wanted in the previous post :)

> 
> > I put a lot of
> > work into keyboard navigation, and any window which have anything
> > selectable via mouse should be reachable via kbd too.
> 
> I understand, but taskbar is mostly a window with no attribute (only a work
> area), no with nothing controlable thru kbd by the AES.

 Yes that is still true. But that will change. You can navigate
taskbar's on other GUIs, and you will on XaAES soon too.

> 
> For the "high priority information window" (i think it's the good name -- alert
> is not good because "alert" requires a response from the user), it's only for
> information. There is no special control over that kind of window. So no need
> to have a kbd navigation for this kind of window.

 Alerts do not necessarily need response from the user. That depends on
the level of the alert, and I already made a proposal as to how that can
be solved.

> 
> >  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;
> 
> When Olivier made its proposal, i immediatly thought of the benefit for "high
> priority information" windows for applications.
> 
> If we change the definition of the TOPMOST window to allow the kbd focus of the
> application when this window is topped, then the TOPMOST feature doesn't fit
> anymore to my whish. But it still fits good for taskbar, and internal AES
> popup/menus.

 Any window the user clicks on should be accessible. Else it would break
the normal 'flow of window usage'.

> 
> > I just dont get why topmost is necessary when there
> > are other better ways to solve this?
> 
> At the moment, there are no way to create "high priority information" windows in
> AES as described in the initial proposal (display the information on top of the
> screen, and let's the focus to the current application).

 Why cant alerts with a timeout be used for this? These are alerts,
nothing but alerts (as in alerting the user of high priority
information), no need for the application to make those look special. So
this is what it all boils down to, having fancy eyecandy in alerts?
Furthermore, normal windows being TOPMOST should still get keyboard
focus when topped. Ofcourse, your windows look like such, but never
receiving kbd focus.

> 
> > > >  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!
> 
> This is exactly what i said: the "high priority information" windows is just a
> window, and all the information are drawn on the work area of the window. And
> as this window doesn't require interactivity, in most cases it will be a window
> without any attribute (only a work area).

 Explain in detail why such high priority information cannot be
classified in the alert category? Dont say that alerts dont fit because
they require user interaction.

> 
> By the way, the main subject is TOPMOST feature for a taskbar. We should focus
> on this. The "high priority information" windows feature is secondary.

 Ok, I was assuming correctly above, you want "A normal window being
TOPMOST and never get keyboard focus"?

> 
> With the initial proposal, the TOPMOST feature fits very well to the "high
> priority information" windows i'd like, and that's why i was happy to have this
> new feature.
> 
> Now, if we agree to change the definition of TOPMOST windows to give the kbd
> focus to the application, then... it's ok. This won't fit to the "high priority

 I want to let the user decide which window he wants to be TOPMOST. I
think this should be transparent to the applications, ie., no extra
attributes that lets application programmers mess around with this
themselves. You brought up ez_edit, I regard that as prime example of
how NOT TO program GEM apps. What do you think happens when such a
programmer goes amok with this?

> information" window feature i dreamt of, and again: form_alert (even very
> extended form_alert) are not the "high priority information" windows feature.

 And why not? I have not got a decent answer, apart from the eyecandy
considerations, as to why form_alert() given one extra parameter (a
timeout) can return immediately while the AES handles the rest? Much
easier for application programmers even. Looks follow the theme of the
system.


 Best Regards,
Odd Skancke