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

Description

  • A 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.
  • A 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.

Thoughts

  • 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".