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 <[email protected]> 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
