wlmaker
|
xdg_toplevel... => on handle_new_surface
listeners for map, unmap, destroy
=> so yes, what will this do when mapped?
set title handler:
request maximize handler:
upon surface::map
workspace::map_window(window) => this should add window to the set of workspace::mapped_windows => window element->container -> map_element(element) (expects the container to be mapped)
=> will call map(node?) on window element
upon surface::unmap
workspace::unmap_window
=> window element->container -> unmap_element(element) => will call unmap() on window element => destroy the node
There is a click ("pointer button event") -> goes to workspace.
Button is pressed => pass down to pointer-focussed element. Would eg. show the "pressed" state of a button, but not activate.
button_down
Button is released => pass down to pointer-focussed element. (actually: pass down to the element where the button-press was passed to) Would eg. acivate the button, and restore the state of a pressed button.
button_up click
Button remains pressed and pointer moves. Means: We might be dragging something around. Start a "drag" => pass down a "drag" event to pointer focussed element. Keep track of drag start, and pass on relative drag motion down to element. Keeps passing drag elements to same element until drag ends. Would keep the element pointer focussed (?)
A 'button' would ignore drags. drag_begin, drag_end, drag_motion ? A 'titlebar' would use this to begin a move, and update position. A 'iconified' would use this to de-couple from eg. dock
drags have a pointer button associated (left, middle, right), and a relative position since. They also have the starting position, relative to the element.
button_down [lingering time, some light move] drag_begin drag_motion drag_motion button_up drag_end
Button is pressed again, without much move since last press. Means: We have a double-click. Pass down a double-click to the pointer-focussed element.
button_down button_up double_click
Dock
is the base class for the Dock, Clip or icon area. It has an anchor to either a corner or an edge of the screen, and an orientation (vertical or horizontal). On screen edges, the orientation must be parallel to the edge's orientation.Tile
is the parent for what's shown in the dock, clip or the icon area. An entry is quadratic, and the size is given by the dock. The size may change during execution. A Tile will accept and may pass on pointer events.A Launcher
is an implementation of a Tile. It shows an image (the application icon), and will spawn a subprocess to execute the configured commandline when invoked. A launcher is invoked by a click (TODO: doubleclick?). It shows status of the spawned subprocesses ("running", "starting", "error").
If the application is running, it may show the application's icon (provided by the running application via a Wayland protocol), instead of the pre-configured one.
The Launcher is not part of wlmtk, but of wlmaker implementation.
A running application in WLMaker may (1) have an icon, and (2) be in miniaturized (iconified) state.
An "application" in this context refers to ... a wayland client? an XDG toplevel? Any toplevel (eg. X11 toplevel)? For UI interaction, a "toplevel" seems a good answer, as it's the toplevel that can be iconified. That would apply to both X11 and XDG shell toplevels.
Implication: WLMaker needs to keep track of "applications".
If there is an icon, it should be shown on the launcher that spawned the "application". (showing the icon of the most recently launched one). Otherwise, it should be displayed in the icon area.
An "application" that is iconified will be shown in the icon area. This is irrespective of whether there is already an icon shown for that "application".