Re: [MiNT] wind_set(WF_TOPMOST)

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On Thursday 13 April 2006 20:38, Odd Skancke wrote:
> > >>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.

This describes what kind of window types are defined on the Freedesktop.org
"Extended Window Manager Hints" specification:
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507144

On Linux, with the X window system, user can select which window manager he
will use.  The window manager implements a policy for managing the windows.
The policy is based on:
- the window manager hints that applications set on their windows
- user actions on the window decorations (titlebar, borders etc.)
- other user actions, e.g. last opened window gets focus, focus moves by
  clicking or to window above which the mouse is etc.

Window here means application windows, dialogs etc.

Some important window manager hints that applications can set for a window:
- Window tranciency:
  - Window manager should keep the trancient window above a window to
    which it is trancient for
     - Note that dialog modality is implemented by the application
      (by the widget set it uses).  If application handles dialog modally,
      it should set it's tranciency too so that WM knows to keep the dialog
      above window(s) which it is blocking (otherwise user could think that
      the application is frozen)
- Window type: normal, toolbar, dialog etc
  - How user can manage different window types, how they are decorated,
    where they are/can be positioned etc, is dictatated completely by the
    policy of the given window manager.  Some extreme cases here are:
    - Metacity, the Gnome window manager, quite standard
    - Matchbox, GPE and Maemo/N770 window manager, maximizes
      all application windows to fullscreen (minus panels)
    - Ion, fully keyboard driven window manager, doesn't allow windows
      to overlap and forces application windows to the sizes of the areas
     that user has reserved on screen
- Override redirect: means that the application wants to manage the window
  (stacking) itself.  Menus are usually of this type and they also take
   pointer & keyboard grabs[1] and close when user clicks anywhere on screen
   - Normal window managers do not touch these kind of windows
     (X server puts the last opened window on top)

Window manager gets to know about the windows by "trapping" all the windows
that are opened to the root window and reparenting them under its own
windows so that it can catch all events to those windows (unless
applications is using grabs).


Any application can open any types of windows, and do any kind of grabs.
X server doesn't set any policy on those. WM implements its own policy based
on the hints in the windows, but apps can use any hints they want to.

This "protocol" is intended for co-operation.  If application misbehaves,
user just doesn't use it.


"System windows" like screenlocks etc are often "override redirect" and take
keyboard/mouse/server grab i.e. they are not managed.  None of the panels
(status, task, window etc. bars) are "system windows".  They are just
"normal" managed windows that have set the "dock" type and do not take
focus.


[1] X has several times "frozen" on me because an application that had
a menu open froze.  Only way to deal with that is to switch to another
virtual terminal and kill the frozen application.  X server releases the
grabs an application is keeping when it disconnects (i.e. when its killed).
IMHO grabs are evil.


	- Eero