Re: [MiNT] wind_set(WF_TOPMOST)

[Odd Skancke <ozk@atari.org>]

tor, 13,.04.2006 kl. 17.33 +0200, skrev Olivier Landemarre:
> Hello Odd
> 
> > Hi Olivier,
> >
> >tor, 13,.04.2006 kl. 11.25 +0200, skrev Olivier Landemarre:
> >  
> >
> >>Hello Odd
> >>
> >>No restrictions, except can't have keyboard focus for this windows 
> >>(application can have focus, but for AES no focus is put for application 
> >>thanks this window). I have not put restrictions, and applications can 
> >>have more than one in the same time (of course one will be above the 
> >>other! but all this windows will be above other).
> >>    
> >>
> >
> > I dont quite agree here. I think that this feature should be reserved
> >for system-applications only, such as a taskbar/manager, etc. 
> >
> How do you define system-application? For example taskbar is a simple 
> gem application for me.

 N.AES introduced a function appl_control(). I see that XaAES have a
mode APC_SYSTEM, which lets a gem application be a AES system extension,
altho I dont know the details.

> 
> >Normal
> >applications should use normal windows, the AES provides for
> >alerts/popups already via form_popup/menu_popup/form_alert etc. A better
> >route would be to extend these calls to be non-app-blockable.
> >  
> >
> I not see relation with this feature. This is a feature existing in most 
> modern system, most of time to display some messages for a short time 
> (ex amorok on X11). I agree alerts, popup should be able to be non
> locking, but it's an other problem (should be solve with AES message as 
> some alternative file selector do (not as Magic do! I can't remember 
> name of this file selector)).

 The feature I'm aware other GUI's have are so-called 'program-modal'
windows. This would be the same as extended alert windows to us for
example. Altho these sometimes do not have keyboard focus, the focus
doesnt go to the underlying windows of the program opening such a window
either, I think. If the underlying window is of another application, you
do get keyboard input.

> 
> >  
> >
> >>wind_set(WF_TOP) or wind_set(WF_BOTTOM) have no effects at this time, 
> >>but perhaps I could change this, but window can't receive WM_TOPPED and 
> >>WM_BOTTOMED at this time, do you think it's need? I think it should be 
> >>possible change order beetween all TOPMOST windows, I have not think 
> >>about this possibility before I write this. What do you think about 
> >>this? need or not?
> >>    
> >>
> >
> > What you are proposing here is a second fully-working window-stack.
> >This is indeed necessary for this implementation, but applications must
> >not have the same access to this stack as to the normal-window-stack.
> >That would lift the whole purpose of 'floating' windows, I think, as you
> >could end up with a second 'layer' of windows only. So, no, I do not
> >think these windows should be WF_TOP/BOTTOM controllable by
> >applications. I think we need to sit down and clearly define what we
> >need these windows for, and define their use properly before rushing
> >into implementation that will bring us headache later on.
> >  
> >
> Yes. But I think actual implementation I done, let an aes, to manage in 
> the way it wan't, here this is only a flag to put a window in a specific 
> way, after you can choose or not to control TOP and BOTTOM. I can do 
> this probably, but perhaps it's not need!
> 
> 
> > The 'floating' window is, as you say, very useful for taskbars, etc.,
> >but imagine what happens if all apps can have 'floating' windows...
> >system-apps like taskbars, etc, loose again.
> >  
> >
> 
> I think near never application use it only for a very specific use, this 
> is possible on other system, and I have not see some abuse of this. In 
> the way I have implement it, application have nothing more to do than 
> the software already do. I have a way to force this mode for all windows 
> an application open and test it on Ztask, I not notice any trouble with 
> this.

 Let me get this 100% correct; You do mean that these windows are never
getting covered by 'normal' windows, they always 'float' ontop of the
'normal' ones? In which case, if more apps that absolutely necessary use
these types of windows, we end up with having two layers of windows, and
the whole idea gets lost. Plus you have to maintain two window stacks.
Are there any restrictions as to how many such windows one app can open?

> 
> > Anyone else have opinions on this matter?
> >
> >  
> >
> Yes, need opinion.

 I think we need to carefully consider what such a feature will solve.
Which application, or what situations, would need a window that isnt an
alert, a popup or a normal window? Now, alerts and popups are completely
controlled by the AES, and carefully extending these existing 'window
classes', we can make sure we get a clear and good GUI. I do agree that
'floating' windows are necessary in some cases, such as for a
taskmanager, taskbar and other AES system extensions. I also think that
when a 'normal' application have something important to tell the user,
it should use alerts. Users can then decide if they want the alerts to
'float' over all windows, or just over the alert-callers windows.




 Best Regards,
Odd Skancke