Re: [MiNT] wind_set(WF_TOPMOST)

["olivier.landemarre@utbm.fr" <Olivier.Landemarre@utbm.fr>]

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

I not implement it yet, but I don't know the usefull of it, if a program simply
wan't to do an WF_TOPMOST it just do before an appl_control(), and I don't know
how we could restrict it.

>
> >
> > >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?
Actually I have only one stack and not plan to add one, there is no more
restriction in number than the totaly windows 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.
>
But alert and popup are not funny for display, you can't manage window as you
wan't, can't put gem object on it, can't simply display a message for a short
time (because you wait alway's for clos something) etc...
ex anyplayer play a list of music, it change of title, it could for 3 second the
title of the song, some software write time in hard in menu, probably it could
be better to be above menu bar, bubble could be display, a lot of softawre open
a window in top, to inform of the load of the software (not in our world!) 
etc... Most of time for a short time.

regards
Olivier
>
>
>
>  Best Regards,
> Odd Skancke
>
>
>
>
>
>


--