Re: [MiNT] wind_set(WF_TOPMOST)

[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 !

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.

>  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).

3. "high priority information window".


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

> 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.

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.

>  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.

> 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).

> > >  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).

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.

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
information" window feature i dreamt of, and again: form_alert (even very
extended form_alert) are not the "high priority information" windows feature.

Best regards,
Arnaud.