wlmaker
Loading...
Searching...
No Matches
toolkit

Toolkit

Compositor Elements

Class Hierarchy

  • Where do we use composition, vs. inheritance?

Pending work

  • Separate the "map" method into "attach_to_node" and "set_visible". Elements should be marked as visible even if their parent is not "mapped" yet; thus leading to lazy instantiation of the node, once their parent gets "mapped" (ie. attached to the scene graph).

User Journeys

Creating a new XDG toplevel

  • xdg_toplevel... => on handle_new_surface

    • XdgToplevelSurface::create(wlr surface)
      • listeners for map, unmap, destroy

        => so yes, what will this do when mapped?

    • Window::create(surface)
      • registers the window for workspace
      • creates the container, with parent of window element
      • if decoration:
    • will setup listeners for the various events, ...
      • request maximize
      • request move
      • request show window menu
      • set title
      • ...

    set title handler:

    • window::set_title

    request maximize handler:

    • window::request_maximize
      • window::set_maximized
        • internally: get view from workspace, ... set_size
        • callback to surface (if set): set_maximized

    upon surface::map

    • workspace::add_window(window) (unsure: do we need this?) => should set "container" of window parent... element to workspace::container (ie. set_parent(...); and add "element" to "container")
    • 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

      • is implemented in Container:
      • create a scene tree (from parents node) oc reparent (from parent)
      • calls map for every item in container

    upon surface::unmap

    • workspace::unmap_window

      => window element->container -> unmap_element(element) => will call unmap() on window element => destroy the node

    • workspace::remove_window(window) (do we need this?)

There is a click ("pointer button event") -> goes to workspace.

  • use node lookup -> should give data -> element
  • element::click(...)
  • Button::click gets called. Has a "button_from_element" & goes from there.

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 and Clip class elements