ellis@cadillac.siemens.COM (Ellis Cohen) (01/05/88)
There will be a meeting to discuss window manger related issues
from 9:30am to Noon on Wed Jan 13th at the X Conference.
Members of the DEC, SUN and Siemens window manager group will
be there. You are also invited to attend if you are actively
developing a window manager, or have been actively thinking about these
issues and can contribute to the discussion.
We would like to limit attendance to at most a dozen people so that we
can accomplish as much as possible in the limited time available. If you
would like to attend, contact me by e-mail or phone, leting me know why
you'd like to attend, and I'll let you know the location.
A list of issues is included below, culled from a variety of sources,
including questions and comments in the various mailing lists. I've
tried to be both neutral and complete.
At the meeting, we hopefully will find that we are in agreement about
each issue -- where we are not, we probably will simply clarify our
positions and list pros and cons.
The results of the meeting should be the basis for further discussion at
the WM BOF at the X Conference and/or in the appropriate mailing list.
Among the eventual results should be
(1) a guide for clients -- indicating how they should write code
to work with different window manangers (or none at all).
(2) a guide for wm developers -- indicating what they ought to do
to keep client programs happy.
If there are issues you think should be added (whether or not you
will be attending the meeting), send me mail, and I'll include them.
Ellis Cohen
Siemens RTL Tiled Window Project
105 College Rd East
Princeton NJ 08540
(609) 734-6524
ellis%cadillac.siemens.com@princeton.edu (arpa)
princeton!siemens!ellis (uucp)
------------------------------------------------------------
Philosophical
-------------
How much should properties be changed? How hard should we strive
to stay compatible with existing programs?
Should we consider issues that are important to a class of window
managers, even if they are not universal?
Should we consider changing any property names -- e.g.
WM_NAME => WM_TITLE, WM_ICON_NAME => WM_ICON_TITLE,
WM_CLASS => WM_RESOURCE_NAMES?
About WM_CLASS
--------------
Is WM_CLASS meant to be write-at-most-once? If not, what should be the
effect of changing it?
Should we recommend a way for clients to generate WM_CLASS (such as, in
Unix, using a RESOURCE_NAME environment variable or argv[0])?
Should we recommend a way for clients to automatically generate WM_NAME
from WM_CLASS and/or WM_CLIENT_MACHINE if WM_NAME is not explicitly
provided?
About WM_HINTS
--------------
Should WM_HINTS initial_state only be initial? If so, what if a wm
crashes and is restarted after the client iconizes it? If not, how
can/should wm's respond to changes in it?
Should other fields be added that some wm's might find useful -- e.g.
expensive_to_redraw, expensive_to_resize, keep_visible,
accept_wm_messages, extensions_used?
Should icon-related properties be pulled out of WM_HINTS and moved to a
separate WM_ICON_HINTS property?
About Icons
-----------
How should wm's respond to changes in the icon-related fields of
WM_HINTS?
Should a can_ahrink_to_iconify field be added to WM_HINTS? It would
suggest that a window manager can iconize a window by simply shrinking it
to icon size (possibly removing the usual window decorations).
Clarify which proerties are relevant to client_icon_windows: Size hints?
Non-icon-related fields of WM_HINTS?
About Transient Windows
-----------------------
Should other fields be added to the WM_TRANSIENT_FOR property?
- map_together: When TRUE, mapping or unmapping the application window
should have the same effect on the transient window. (Consider
semantics if can_shrink_to-iconify is included.)
- transient_location: Initial desired location relative to application
window.
- transient_gravity: How the wm should move the transient window when
the application window is moved or resized.
- application_inactive: Indicates that no output is sent and no input
accepted in the application window while the transient window is
mapped.
Clarify which properties are relevant to transient windows: Size hints?
WM_CLASS? WM_NAME? Non-icon-related fields of WM_HINTS?
About Window Sizes
------------------
Should WM_ZOOM_HINTS (and ZoomState) be eliminated? Should a
WM_RANGE_HINTS property be added instead (or added to WM_NORMAL_HINTS).
It would hold a list of height and width ranges that are desired. Could
it allow a specific height range to be associated with a specific width
range, and vice versa?
Clarify the relation of min_width and min_height to width_inc and
height_inc. How should the window size be reported by the wm to the user
when the _inc's are provided (and != 1)?
How should a client request a size change? By doing first an XConfigure
followed by setting WM_NORMAL_HINTS? If so, should we
encourage/discourage special meaning from being attached (by wm's) to
just doing one or the other?
How should a wm respond to to changes in the min or max size in
WM_NORMAL_HINTS if the current window size is no longeer within the range
indicated? Alternately, how should a client change a window's min or max
size?
Should a new WM_USER_GEOMETRY property be added, that would be set by
the wm when the user specified a desired change in the window geometry
(this may be different from the actual XConfigure done by the wm if
it is enforcing layout constraints)? How would an application use this
information?
About Colormaps
---------------
Clarify how a window manager should deal with colormaps.
About Input Focus
-----------------
Clarify the ways & reasons a client might set input focus and how a wm
ought to respond.
Clarify how an application with multiple top-level windows should move
the pointer/focus from one to the other. WarpPointer followed optionally
by a SetInputFocus?
About WM_MANAGER
----------------
Should a wm place a WM_MANAGER property on the desktop (root or
pseudo-root) it manages? It would contain an id of a window that would
probably not be mapped and not be in the wm's save set. The wm could
attach properties to it readable by its clients, and clients could send
messages (including specialized wm-specific protocols) to the wm via this
window.
Should the WM_ICON_SIZE property be moved to this window?
Is there a need for a standard WM_PROPERTIES property to be placed
on the WM_MANAGER window? It would contain fields indicating whether or
not the wm
- sends messages or synthetic events (see below)
- reparents/constrains regular/transient/icon windows
- notifies when configure is denied
- supports client icons
- supports transient gravity
- etc.
Is there a need for a WM_PROTOCOLS property to be placed on the
WM_MANAGER window? It would hold a list of atoms identifying
protocols or conventions that the window manager supports for
interacting with clients.
About WM/Client Communication
-----------------------------
Should a special class of ClientMessages be defined for wm/client
communications?
When a reparenting wm reconfigures a window but does not resize it
(i.e. restacks or moves the parent), should the client be notified?
By a synthetic ConfigureNotify event? By a WM_MOVED message?
When a ConfigureRequest is effectively denied by a wm (no change takes
place), should the client be notified? By a synthetic
ConfigureNotify event? By a synthetic error event? By a
WM_CONFIGURE_DENIED message? If a message, might the wm also supply
hints about a request that could succeed? Should a client that needs to
wait for such a notification time out, assume that any wm either
does the configure or denies it, or use a timeout based upon fiedl in
WM_PROPERTIES?
When a reparenting wm unmaps the parent window, should it also unmap the
client window? Send it a synthetic UnmapNotify event? Send it a
WM_UNAMP message? (Consider case where it is backed_up, or where
can_shrink_to_iconify is used).
Should a wm notify top-level window clients when it comes up?
Via a synthetic PropertyNotify event? Via a WM_INSTALL message?
Should a wm notify a client that a user has requested that its geometry
be changed? Via a synthetic PropertyNotify event? Via a
WM_USER_GEOMETRY message?
Should there be a standard WM_REQUEST_KILL message that a wm can use to
request that a client kill itself? How might a client respond to such a
message? Via WM_KILL_REFUSE, WM_KILL_ACCEPT, or WM_KILL_WAIT messages
(send via the WM_MANAGER window)?
How about a WM_WILL_KILL message indicating that the client will be
killed by a certain time?
Relating to Xlib
----------------
Should XSetStandardProperties be eliminated or changed, for example, to
accept a resource class and name? Should it set WM_CLIENT_MACHINE? If a
resource class is not provided, should XSetStandardProperties set it to
the window name? If a resource name is not provided, should
XSetStandardProperties set it based on a RESOURCE_NAME environment
variable and/or argv[0]? If a window name is not provided, should
XSetStandardProperties set WM_NAME based on other properties?
How to best support cases where a window manager uses a window other than
the root as the desktop? A PARENT_DESKTOP environment variable?
Extending the DISPLAY environment variable? Should there be a new Xlib
DefaultParentWindow macro, and should clients be encouraged to use this
instead of DefaultRootWindow in XCreateSimpleWindow?
Do other functions need to be added to Xlib encapsulating some of the
common but complex sequences of operations a client needs to do?