GNOME.org
 

[Fwd: Work in Progress: draft 1.9a]

Fwd to the list.

Mark
-- 
... GUI: WPS.
------------------------------------------------------------------------
Marko.Macek@gmx.net                 http://www.kiss.uni-lj.si/~k4fr0235/

Hi Marko,

On Mon, Jul 05, 1999 at 07:34:30AM +0200, Marko.Macek@gmx.net wrote:
> > What will happen to windows on a desktop that is deleted?
> 
> I guess they should be moved to the new current desktop.

Uh, what *new* desktop. I meant when the desktop is *deleted*
there should probably be a definition where the windows should
end up (or the statement that the WM is free to implement this).

> > > _NET_DESKTOP_GEOMETRY width,height, CARDINAL[2]/32
> > >
> > > _NET_DESKTOP_VIEWPORT x,y, CARDINAL[2]/32
> > >
> > > _NET_CURRENT_DESKTOP <desktop>, CARDINAL[1]/32
> > >
> > > _NET_DESKTOP_NAMES
> > >
> > > _NET_ACTIVE_WINDOW, WINDOW/32
> > >
> > Imagine the user wants this: When a button on the task bar is pressed
> > he want's that the window is mad fully visible (i.e. the desk and
> > viewport are switched, the window is raised, unshaded and de-iconified)
> > and the pointer is warped into the window and the window is focused.
> 
> (Personally - definatelly not warped :) )

That may depend on your focus policy. With strict MouseFocus you will
never get the focus on the desired window. Plus if you are navigating
the task bar with keys this may be an entirely different story.

> > But when the pointer simply enters the button the application window is
> > only raised and focused.
> > 
> > I don't think this can be handled by this hint alone. The hint could
> > have a parameter to indicate the degree of activation. Note that the
> > details of what is done should be configured inside the WM because
> > the user might have a keyboard shortcut that does something similar
> > in the WM already.
> 
> Do you have a suggestion for meaningful degrees of activation? 

  _NET_ACTIVATE_VISIBLE_ON_VIEWPORT:  make visible if on the active viewport
  _NET_ACTIVATE_VISIBLE_ON_DESK:      make visible if on the active desktop
  _NET_ACTIVATE_VISIBLE_EVERYWHERE:   make visible everywhere

One bit each, if multiple bits are set, EVERYWHERE take precedence over
ON_DESK, ON_DESK takes precedence over ON_VIEWPORT.

  _NET_ACTIVATE_NORMALIZE:            de-iconify and unshade

One bit, may be set independently of the other bits.

  _NET_ACTIVATE_FOCUS:                give it the focus
  _NET_ACTIVATE_FOCUS_AND_WARP:       give it the focus wnd warp into it

One bit each. If multiple bits are set, FOCUS_AND_WARP takes precedence.

> > Fvwm allows to chose between different methods of removing other clients:
> > 
> >  'Delete' requests that the application removes the window itself
> >  'Close' tries a 'Delete' first and if that fails it uses XKillClient
> >  'Destroy' always uses XKillClient.
> > 
> > It would be a good thing to have this as a parameter.
> 
> Not necessary IMO. XKillClient should only be used on windows that do
> not support WM_DELETE_WINDOW. Using it on windows that support WM_DELETE
> WINDOW is a really bad idea unless the user directly requests it. 
> 
> (Personally I think it is VERY dangerous to have Destroy without
> confirmation in the menu nearby Close. It's just too easy to hit the
> wrong one).

But why shouldn't the user decide what he wants? I for myself do not
care at all if the application crashes when I destroy its window (because
that is what I want).

> > Well, I think we can't just allow applications to resize windows
> > of other applications (managed by the wm). Applications doing this
> 
> Obviosly applications should only resize themselves.

Then why do we need this protocol? Isn't a ConfigureRequest sufficient to
inform the WM of the resize? I thought this protocol was meant to allow
some kind of tool (pager?) that allows resizing windows too.

> > would indeed try to do window manager tasks. The application can not
> > know what decoration the WM has put on the target window and thus
> > trying to guess what will fit on the screen only leads to trouble.
> 
> > Same with moving. At present GNOME menu bars move themselves. This
> 
> I really dislike this too.
> 
> > should really be handled by the WM somehow.
> 
> This message is intended for that. The app sends it whenever it wants to
> resize/move and the WM will take over.

Ah yes, now I see it. But how should the WM react to this? Should
a mouse button be pressed when taking over? And what if the user
wants to move with the keyboard?

> > > _NET_WM_DESKTOP <desktop>, CARDINAL[1]/32
> > >
> > > Cardinal to determine the desktop the window is in (or wants to be),
> > 
> > Does this mean the WM *and* the client are allowed to write this?
> > E.g.: Window is on desk 2. App. requests the window to be unmapped,
> > WM sets property to 0. App. maps its window again, WM reads the property
> > (== 0) and places the window on desk 1, now that it may do what it wants!!
> > This needs to be clarified.
> 
> The app only writes before mapping the window. Afterwards it must send
> client-messages and the WM will update the property. This allows the WM
> to have more control.
> 
> The WM could move all the dialogs when the main app window changes
> desktop, for example.

Hm, I still consider this a rich source of bugs. Only some kind of
application manager (be it a WM or a pager or whatever) can know where
the window should be. The thought that future applications may require
the user to reserve a desktop for them and automatically mapping to it
makes me shudder.

> > > A window manager honors _NET_WM_DECORATION whenever a withdrawn window
> >                    ^^^^^^
> > Or it may choose to never honour it (e.g. if the user asked it to
> > do so).
> 
> Obviously.

No, not obviously. The ICCCM authors made the mistake to not clarify
such statements. The result is that e.g. an aspect ratio of -4 to
-1265346153 is allowed by the ICCCM. Virtually no WM can handle this
however. A bit more clarity won't hurt. Let's assume we WM authors
are idiots who can't read between the lines :-)

> The Dock layer might go away when NET_WM_STRUT is finalized...
> 
> We do need:
> - DESKTOP,
> - NORMAL
> - ONTOP and for completeness BELOW.

Okay.

> > > #define _NET_WM_STATE_STICKY (1<<0) /* the window sticks on the screen
> > > even when the virtual desktop scrolls */
> > > #define _NET_WM_STATE_OMNIPRESENT (1<<1) /* the window is visible on all
> > > virtual desktops */
> > How about something less esoteric like
> > 
> >  _NET_WM_STATE_FIXED_ON_SCREEN
> > 
> > and
> > 
> >  _NET_WM_STATE_VISIBLE_ON_ALL_DESKTOPS
> > 
> > I know, it's more letters, but you could understand what it means, even
> > if you're no WM hacker. And it avoids other definitions of the term
> > 'STICKY'. Fvwm for example has a 'sticky' style that essentially means
> > 'omnipresent' and 'sticky' at the same time in above terms.
> 
> OK. (Fvwm has seriously confused some people with
> desktop/desk/page/sticky...)

Whom do you tell that ;-) It's a *mess*. These terms should be standardized too.

> icewm uses the term Workspace and Occupy All (just like CDE).

Whatever, I don't care as long as the terms can be understood
by everyone in the end.

> > > #define _NET_WM_STATE_MAXIMIZED_VERT (1<<2)  /* the window is vertically
> > > maximized */
> > > #define _NET_WM_STATE_MAXIMIZED_HORZ (1<<3)  /* the window is
> > > horizontally maximized */
> > > #define _NET_WM_STATE_SHADED (1<<4)  /* the window is shaded */
> > >
> > > A window manager honors _NET_WM_STATE whenever a withdrawn window
> > > requests to be mapped.  When being in another state (iconified or
> > > mapped), the client can request a change by sending a _NET_WM_STATE
> > > client message to the root window. (window is the respective window,
> > > type _NET_WM_STATE, format 32, l[0]=<mask>, l[1]=<new values for masked
> > > bits> )
> > 
> > I don't think it's a good idea to allow applications to control their
> > state when they are mapped. All these states are tracked by the WM
> > after the window has been mapped nad the application cannot and should
> > not know about what the WM is doing. The WM would have to inform the
> 
> It does.

Uh, what do you mean?

> > app of any state changes so that it can set the correct bits when
> > it sends its next client message. I see a number of problem that
> 
> The app should only send the bits it wants to change. (<mask>). Also:
> mask=0xFFFFFFFF state=0 should restore the window to normal state.

Okay.

> > unnecessarily add to the complexity of state handling and make it
> > very prone to bugs. It will be very hard to write a working application:
> 
> >  - What will happen if an icon is shaded/maximized? Will it de-iconify?
> >    THe application can't rely on the state it will have afterwards.
> >  - ... a maximized window is maximized again and then unmaximized?
> >    Will it have its original size or the the size of the last maximization?
> 
> It should, no?

It should what? There are two possibilities (see above).

> >  - And what if the user doesn't like to have applications that occupy
> >    *all* desktops. Perhaps he wants desk 5 reserved for something entirely
> >    different. How can he force the application not to set this hint?
> 
> omnipresent is togglable by the user in most current WMs, no?
> Also, the app should really have an option not to set this.

But if the application doesn't cooperate? Then the user will have a hard
time to make the application behave.

> >  - What is the difference between a maximized window and one that has
> >    been resized by the user? Why should the application care about
> >    this difference. The application will override the user's choice if
> >    it explicitly requests maximization when the user 'maximized' it this
> >    way.
> 
> The app should not do this. 
>  
> > Overall this introduces too many ways for applications to override
> > WM and user preferences. For the sake of simplicity and managability
> > the state hints should really be limited to the time when the window
> > is mapped. An application using this hint for a different purpose
> > than obeying user preferences (which will always be the case after it
> > has been mapped) will make things rather difficult and often surprising
> > for the user.
> 
> This will only cause the applications to map/unmap themselves when they
> want to change some hints. Java does this for MWM hints (because some
> WMs apparently don't update them on-the-fly) and it is VERY annoying to
> have the window blink.

You say the app will do it only when mapped, but the description of the
hint states something different (by allowing client messages). BTW, I
subscribe 100% to what Greg Badros wrote yesterday. We should really
think more about the features that are really needed instead of allowing
applications maximum control of their appearance. It's just too
dangerous. I can remember well tha days when every application came with
its own GUI with its own behaviour. We should absolutely avoid this.

> > --
> > > _NET_WM_HINTS CARDINAL/32
> > > Additional hints for the window manager or tools like panels or
> > > taskbars.
> > 
> > I'm quite unhappy with the naming here. Either they are WM hints or not.
> > If taskbar hints are needed then define them as _NET_TB_..., but not
> > as _NET_WM_... hints.

> > > #define _NET_WM_HINTS_STANDALONE_MENUBAR  (1<<4) /* this window is a
> > > standalone menubar */
> > 
> > What would the effect of this be?
> > 
> > > #define _NET_WM_HINTS_FIXED_POSITION  (1<<5) /* this window has a fixed
> > > position (should be excluded from desktop uncluttering etc.) */
> > 
> > Does this include moving?
> 
> No. It should probably be renamed to _IGNORE_ARRANGE.

Okay.

> > > #define _NET_WM_HINTS_DO_NOT_COVER (1<<6) /* attempt to never cover up
> > > this window if possible (placement policy priority hint)*/
> > > #define _NET_WM_HINTS_LOCK_ZORDER (1<<7) /* window will not be raised
> > > when clicked even if WM does this for normal windows)*/
> > 
> > What about lowering?
> 
> That too. I added this because mozilla would like to have it. See my
> recent email. We should ask them exactly what they would like to have.

Yes. As a WM hacker I'd rather see that mozilla makes their software
cooperater better with the WM. About a third of our bug reports related
to stacking order etc. are for netscape.

> > > A window manager honors _NET_WM_HINTS whenever a withdrawn window
> > > requests to be mapped.  When being in another state (iconified or
> > > mapped), the client can request a change by sending a _NET_WM_HINTS
> > > client message to the root window.  (window is the respective window,
> > > type _NET_WM_HINTS, format 32, l[0]=<mask>, l[1]=<new values for masked
> > > bits> )
> > 
> > Hm, how can you distinguish between 'I don't care' (bit set to zero) and
> > 'Don't do it' (bit set to zero)?
> 
> With the <mask> argument above.

Ah - no. If a bit was set previously and the app resets it to zero, does
that mean 'don't care' or 'don't do it'?

> > > _NET_WM_ICON_GEOMETRY
> > >
> > > An array x,y,w,h of type CARDINAL, format 32.  This optional property
> > > may be set by standalone tools like a taskbar or an iconbox. It
> > > specifies the geometry of a possible icon in case the window is
> > > iconified.
> > >
> > >   Rationale: This makes it possible for a window manager to display a
> > >   nice animation like morphing the window into its icon.
> > 
> > ?? Since the window manager already handles icons, what would that hint
> > tell it? It knows much better what icon it will use and where it will be
> > placed than any application. Or is the reasoning here that the WM will
> > not handle icons? If this is the case I wonder why the WM should draw
> > icon animations at all. If it isn't even allowed to manage icons it is
> > clearly not the WM's responsibility to draw animations. So if it's
> > desirable that the taskbar manages all icons it should tell the WM
> > not to handle icons at all and do the drawing itself, but not misuse
> > the WM as an 'animation extension'. If a central place for animations
> > is needed there should be some kind of 'animation server'.
> 
> This makes sense. Matthias? I didn't plan to implement any of this
> animation stuff in icewm anyway.

> > In general, what I miss in this draft is a list of properties/hints/protocols
> > that a compliant window manager *must* obey and what it *should* or *may*
> > obey. E.g. it was said in the previous discussions that the paging
> > interface would be constituted of hints, i.e. the user can tell the WM
> > to ignore all this if he doesn't like it. How would that work if
> > you used _NET_NUMBER_OF_DESKTOPS to delete/add desktops?
> > 
> > Another thing that isn't addressed are icons. What is the rationale
> > behind the implicit assupmtion that compliant WMs will not manage
> > icons (because of feature duplication with the desktop environment)?
> 
> Current desktop environments (GNOME/KDE) have filemanager icons on the
> desktop. There are no icons for app windows.
>  
> > Rationale for letting the WM do *all* icon management:
> > 
> > Icons are closely linked to their applications and the WM may make
> > them look similar to their full sized window (e.g. colour of the
> > window/icon title). Icon management has always been a core
> > responsibility of the WM and thus many WMs are very sophisticated
> > when it comes to icon management. Furthermore it is undesirable
> > that the WM controls mouse bindings on full sized windows while
> > the desktop environment handles the bindings on icons (because it
> > is hard to understand/change for the user).
> > 
> > Implementation idea for 'shortcuts':
> 
> Do you mean file manager icons by "shorcuts".

Yes, for example.

> IMO the only reasonable
> implementation is to keep a file manager window at the bottom of the
> Zorder (layer=DESKTOP). The current GNOME implementation where every
> icon is a managed window is very messy and doesn't work well. The
> desktop should behave exactly like a file manager window (with no menus,
> toolbars, ... scrollbars should be there if necessary).
>  
> > The desktop environment sets icon hints much like a normal application
> > would, but it can have any number of icons. There must be a way to
> > tell the WM to add or remove any particular shortcut. The desktop
> > environment may provide an icon window or a pixmap. If it provides
> > a pixmap it leaves decoration the shortcut to the WM (exactly like
> > it is with icons). The WM communicates the window id of the shortcut
> > window back to the desktop environment so that it can select mouse
> > or keyboard events on the shortcut. The WM never selects any mouse
> > or keyboard events on the shortcut. Perhaps there has to be an
> > interface to request icons and or shortcuts to be rearranged.

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, dominik_vogt@hp.com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]