Checklist: ICCCM/EWMH

[Dana Jansens]

Wow lots of stuff, and I can see a lot of thought in it. Nice job.
Some comments inline.

On Thu, Jan 27, 2011 at 1:44 PM, Marty Jack <martyj19 at comcast.net> wrote:
> Design choice recommendations
>        Move to a single character set (UTF-8)
>        Move to a single coordinate space for multiple video cards, multiple outputs on same video card
>                I think EGLDisplay should be what X would call a Virtual screen and that is large enough to combine the outputs of all video cards being managed
>                        I know the EGL spec equates EGLDisplay to "monitor"
>                        Dispense with Screen, Zaphod, Xinerama
>                Need an equivalent to xorg.conf.d for annotating and blacklisting video cards and their outputs
>                Need an equivalent to xorg.conf.d for annotating and blacklisting input devices
>        Move to a single coordinate space for multiple desktops
>                User support requests indicate they really like keeping applications on (the illusion of) multiple desktops and switching them
>                Too much complexity here
>                Dispense with _NET_NUMBER_OF_DESKTOPS, _NET_CURRENT_DESKTOP, ability to mix large desktops and multiple desktops
>                Try to dispense with panning and only allow paging multiple desktops (is this exactly backwards for mobile?)

Rather than stick with hardcoding a rigid notion of desktops, I would
really like to see this abstracted more so that people can be more
creative with organizing the desktop space.  The idea of disjoint sets
of windows on a fixed number of desktops is an old idea and it is very
limiting.  There are already some X window managers which cannot be
fully communicate their windows' setup via the current desktop model.

To contribute one such idea, we could instead use in the API "sets of
visible windows".  Let's call these sets "tags", and a window belongs
to set A if it has been tagged with A.  The main point is that a
window could belong to an arbitrary number of such tags, and an
arbitrary (and different) number of such tags would be visible at any
given time.  A simple implementation could use this to replicate
current desktop semantics, but it also allows a lot more.

Quick example in case that didn't make sense.  Firefox could be tagged
with {A, C, D}.  Xmms tagged with {A, B, E}.
And currently visible on the display could be tags {A, E} (both
windows would be visible then).

Under the current model a window would be only be tagged with a single
tag, or with all of them.  And only a single tag-set would be visible
at a time.

Lastly, the user will likely have sets of tags (perhaps a single tag
at a time) that they would like to reuse.  These should be possible to
assign and save, and name.  For instance, "At home" could refer to
tags {A, C} (where A and C are each tag-sets of windows).  Then making
"At home" exclusively visible would make only windows with tags A or C
visible.  In the traditional model, each such grouping has a name and
would contain a single tag-set of windows, such as "Desktop 1" => {A},
"Desktop 2" => {B}.

>        Would have been nice to move to a single Visual/Colormap equivalent, that is, RGBA-32, always composited
>                But, EGL has these as choices and I suppose YUV is relevant
>
> ICCCM not desktop environment relevant requirements, may be someone else's
>        Window geometry constraints (minimum size, resize increments) in WM_NORMAL_HINTS
>        Window gravity (no longer of much interest?)
>        Input focus model knob in WM_HINTS
>
> ICCCM/EWMH requirements, from desktop environment's point of view
>        Way of detecting unresponsive client
>        Enumerate toplevel windows (would be equivalent if we could get New and Gone events) (taskbar, pager): _NET_CLIENT_LIST
>        Enumerate stacking order (pager): _NET_CLIENT_LIST_STACKING
>        Window that has focus: _NET_ACTIVE_WINDOW (taskbar, pager may draw it differently)
>        Window title (display in taskbar): WM_NAME, WM_ICON_NAME, _NET_WM_NAME, _NET_WM_ICON_NAME, _NET_WM_VISIBLE_NAME, _NET_WM_VISIBLE_ICON_NAME
>                Carry forward only a single UTF-8 title found now in _NET_WM_NAME

There will be no way for a compositor to influence the title found in
window title bars, unless we provide one for the toolkits to use.
Should there be?

>        Window icon (taskbar, title bar) _NET_WM_ICON, WM_HINTS as Pixmaps requiring extra round trips
>                Carry forward only a literal icon found now in _NET_WM_ICON
>                Re-evaluate whether having a lot of sizes is necessary
>        Window class (arbitrary string controlling taskbar button grouping) WM_CLASS
>                Carry forward at least the Class part, don't use the Instance part

Class (and the already obsolete role) are also used for another
important function - identifying windows across sessions.

Rather that using class/role type hints for this, as it is such a
hack, I'd like to see some sort of property provided by an application
that would explicitly be to allow that window to be uniquely
identified.  This would allow applications to remember the window in
the future if the application is launched again and restores its
state.  The property would basically be an encoding of the application
and the window's state (or identity within the application).

>        Iconic state: WM_HINTS
>        Window purpose: WM_TRANSIENT_FOR, _NET_WM_WINDOW_TYPE, _NET_WM_STATE (used ad-hoc to add to _NET_WM_STATE_SKIP_*)
>        Window urgency: WM_HINTS
>        Window type and state _NET_WM_WINDOW_TYPE, _NET_WM_STATE:
>                Lots of "window roles" that affect placement and stacking order
>                Taskbar visibility controls _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_HIDDEN
>                Taskbar/pager tends to use other window roles in an ad hoc way to affect visibility

As you say a lot of pain and suffering has come from the lack of
expectations about how these types and states are meant to affect
things.  Ambiguity here has not been a helpful thing for application,
window manager or desktop chrome authors.  I'm glad you're pointing
this out also.

The transient-for model currently allows arbitrary relationship graphs
between windows.  If, instead, a window could only set the property
when it appears, and could only refer to another existing window, then
it would only allow for relationship trees, which would be a useful
thing.

>        Version control on features: _NET_SUPPORTED
>        Window operations
>                Close: _NET_CLOSE_WINDOW, WM_PROTOCOLS[WM_DELETE]
>                Iconify, Restore: XIconifyWindow, XMapWindow
>                Shade, unshade: _NET_WM_STATE_SHADED
>                Maximize, demaximize: _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ
>                Raise: _NET_ACTIVE_WINDOW, XMapRaised, XSetInputFocus
>                Full screen:  _NET_WM_STATE_FULLSCREEN
>                Take input focus: _NET_ACTIVE_WINDOW

_NET_ACTIVE_WINDOW has been a can of worms.  If you activate a window
on another desktop, there is no way to know if the caller intends the
window to be added to the current set(s) of visible windows, or to
instead change which set(s) of visible windows are being shown.  Some
clarity, for instance, to say that a window can only take input focus
if it is in the visible set(s) would help a lot here.  (Applications
can always request the set of visible windows be changed first.)

>                Mass iconify/restore: _NET_SHOWING_DESKTOP

This was a weird copy of a windows xp feature, and could be done
better.  For instance, it is not clear which windows are/aren't being
hidden when this is set currently. So it is not possible for a pager
to always mimic what the user is actually seeing by using this hint.
Personally, I think this should be an internal state in the
compositor, and it should just be possible to see where windows in the
currently visible sets are positioned and how they are/aren't being
drawn.

>                Make sticky: _NET_WM_STATE_STICKY

As a note, this only applies to panning, which you've suggested
removing earlier.

>                Change visibility in desktop metaphor: _NET_DESKTOP_VIEWPORT
>                Move window to different view in desktop metaphor: _NET_MOVERESIZE_WINDOW
>        Window geometry relative to desktop metaphor (pager)
>                Pager uses ConfigureNotify event and XGetGeometry to get position on virtual desktop
>                The coordinate space changes, and there is a race condition between ConfigureNotify and _NET_DESKTOP_VIEWPORT;
>                    causes an unnecessary XGetGeometry round trip;
>                    fix this by not changing the coordinate space
>        Space allocation for docks in presence of application windows, so maximized windows won't overlay them
>                _NET_WORKAREA
>                _NET_WM_STRUT, _NET_WM_STRUT_PARTIAL

There are races/unclear semantics in the strut implementation as it is.

When two applications both want to place a strut on the same edge of a
monitor, they must read which struts are present there to decide their
position against the edge.  This is a race, as they may both read no
struts and place on top of each other.  Secondly, the user has no way
to specify the order in which they appear from the edge of the
display.

My suggestion is that the compositor is responsible for placing
strut-type windows so it can determine order and positioning
correctly.

Secondly, the strut hints as they are assume a single monitor space,
and do not allow docks to be placed at edges between monitors.

My suggestion here is to allow a window to specify a strut region for
each monitor (if it wants), and each strut is always relative to a
specific monitor.

>        Geometry of iconified view so window manager can animate iconify: WM_ICON_GEOMETRY
>        Desktop metaphor configuration sensing, including "sticky" windows that are visible on all views
>                _NET_WM_DESKTOP (window property)
>                _NET_NUMBER_OF_DESKTOPS
>                _NET_DESKTOP_GEOMETRY

Disregarding panning, this currently assumes a single monitor, or
monitors which sizes happen to create a single rectangular desktop.

>                _NET_DESKTOP_VIEWPORT
>                _NET_CURRENT_DESKTOP
>                _NET_DESKTOP_NAMES
>                _NET_DESKTOP_LAYOUT

This assumes desktops are (all) organized in a spacial fashion beside
each other, as well as being predicated on the old
disjoint-sets-of-windows desktop model.

If we could instead provide in the API saved groups of (tag-sets of)
windows, we could allow the compositor to specify, for each such saved
group, its position relative to another saved group, or to not.

For instance, in a traditional setting, the dashboard in MacOSX could
be a group of windows tagged "dashboard", but it does not have a
position relative to other such groups, such as "Desktop 1".

>        Window information
>                _NET_WM_PID, backpointer to owning process in case we want to kill() it
>        Event when
>                Hotkey presses (do the requested action)
>                New or deleted toplevel window (update taskbar, pager)
>                Locked keyboard group changes (update country flag, update on-screen keyboard keycaps)
>                Keyboard changes (re-enumerate keyboard symbols, update country flag)
>                Keyboard indicators change (update on-screen indicator display)
>                Monitor geometry changes (re-enumerate monitors, update all panel geometry, configuration dialog if open)
>                Monitor backlight changes (update on-screen display)
>                Window moves (update pager)

and resizes.. and flips.. In a composited environment, the desktop and
each window may be transformed in any number of ways, so I think its
worth thinking about what information a pager would want to display,
and what it would need to do that.

>                Visible desktop changes (update taskbar, pager)
>
> Not relevant
>                Entire design for compositing manager
>                _NET_SUPPORTING_WM_CHECK
>                _NET_VIRTUAL_ROOTS
>                _NET_REQUEST_FRAME_EXTENTS
>                _NET_WM_HANDLED_ICONS
>                _NET_WM_USER_TIME
>                _NET_WM_USER_TIME_WINDOW
>                _NET_FRAME_EXTENTS
>                _NET_WM_SYNC_REQUEST
>                _NET_WM_FULLSCREEN_MONITORS
>                _NET_WM_FULL_PLACEMENT
>                WM_COLORMAP_WINDOWS
>                WM_CLIENT_MACHINE
>                WM_ICON_SIZE
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>