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