[Snowcap] Task List RFC

[Ph4ntomas]

I've been tinkering with wlr-foreign-toplevel-management, and I'm finally at a stage where I have something to show.

My general idea was to implement a server side widget that would work a bit like a mouse-area. It's goal is not to present anything, but to allow for the state to be notified of changed in the task.

tasklist_2.mp4

The widget currently exposes 3 signals sources:
Enter: A new task is being tracked by the widget.
Leave: A task stopped being tracked by the widget.
Update: A tracked task state has changed.

The widget additionally take a single child which will hold the content to be rendered (this means the config choose how the actual task is being rendered.

How it works:

1. Snowcap is notified of the state change for wlr-foreign-toplevel-management.
2. A set of custom operation are broadcasted to every surfaces.
3. The widget react to this operation and prepare message that are stored in its internal state.
4. The pending changes are converted into messages next time the update function is called
5. After the broadcast is done, wlr-foreign-toplevel-management functions request a redraw.

Planned features (assuming I/we proceed with this):

• Make the widget output aware, so it only notify for toplevels on its output (and make this a config option)
• Add a way to interact with the tasks being displayed. The idea here would be to implement additional operation exposed to the config to call some methods on wlr-foreign-toplevel-management handles. The preliminary work is already done, as the widget hold on weak handles, and transmit a unique id as part of the messages it emit.

Notes & caveat:

I've base the POC on wlr-foreign-toplevel-management because it's supported by most compositor and can actually control the foreign toplevels.
However this protocol has a few limitation:

• No support for workspace, the best you can do is filter per output.
• No unique identifier per toplevel (so no way to tie it back to pinnacle config).

ext-foreign-toplevel-list doesn't have a way to act on the toplevel yet, but we get an identifier that we can the tie back to the config using WindowHandle:foreign_toplevel_list_identifier()

Long term, I think we should move to foreign-toplevel-state (assuming it gets merged), but for the time being, there are a few things that can be done:

• Have a WlrTaskList widget (essentially what I have a poc for), that only cares about the wlroot implementation, even if it have some limitation.
• Have a TaskList/ExtTaskList widget, and let the config fill the gap using the identifier (we may want to add some way to get a WindowHandle from a identifier).
• Implement foreign-toplevel-state ahead of time as an experimental support to augment the TaskList/ExtTaskList widget. This could also help with the protocol getting merged, since it needs to have some implementations in use (not actually required, with cosmic, niri & wlroots actively participating in the PR)
• Implement a protocol, either to add a state of our own while waiting for foreign-toplevel-state, or to tie foreign-toplevel-list and wlr-foreign-toplevel-management, so we can use the data coming from pinnacle while writing our config.

(these options are not mutually exclusive. I don´t really plan on scrapping WlrTaskList, and part of the implementation can be re-used regardless of what's end up being done.)

I have a bit of cleanup to do, then I'll open a PR with my current work

[Ottatop]

Now that #414 is merged I'd like to propose an alternative to an in-tree, server-side widget for dealing with a task list.

I see two ways to do this: widgets and operations (implemented here), or signals and handles. Both allow us to retrieve task information and provide task controls, but the problem I see with the widget approach is that it's not user-customizable. Any configuration has to be done within the server and there's no way to, for example, plug in a different source for tasks without hand-rolling a separate signal + handle approach or making a new server implementation, at which point I'd rather have both solutions use signals and handles.

A theoretical impl

This is how I envision the Rust side to look like with Pinnacle WindowHandles as a task source for example:

pub trait Source {
    type Task;
    type Message;

    fn register(&self, signaler: Signaler);
    fn update(&mut self, msg: Self::Message);
    fn tasks(&self) -> &[Self::Task];
}

pub trait Task {
    fn title(&self) -> String;
    fn app_id(&self) -> String;
    // ...
    
    fn set_maximized(&mut self, maximized: bool);
    fn activate(&mut self);
    // ...
}

pub struct PinnacleSource<Msg> {
    windows: Vec<WindowHandle>,
    handles: Vec<SignalHandle>,
    _phantom: PhantomData<Msg>,
}

enum PinnacleSourceMsg {
    Created(WindowHandle),
    Updated(WindowHandle),
    Destroyed(WindowHandle),
}

impl Universal for PinnacleSourceMsg {}

impl<Msg> Source for PinnacleSource<Msg>
where
    Msg: From<PinnacleSourceMsg> + Into<Option<PinnacleSourceMsg>>,
{
    type Task = WindowHandle;
    type Message = Msg;

    fn register(&self, signaler: Signaler) {
        self
            .handles
            .push(window::connect_signal(WindowSignal::Created(Box::new({
                let signaler = signaler.clone();
                move |win| {
                    signaler.emit(Message(Msg::from(PinnacleSourceMsg::Created(win.clone()))));
                }
            }))));

        self
            .handles
            .push(window::connect_signal(WindowSignal::ImagineWeHadAnAllPropertiesSignalHere(Box::new({
                let signaler = signaler.clone();
                move |win, props_idk| {
                    signaler.emit(Message(Msg::from(PinnacleSourceMsg::Updated(win.clone()))));
                }
            }))));

        self
            .handles
            .push(window::connect_signal(WindowSignal::Destroyed(Box::new({
                let signaler = signaler.clone();
                move |win, _, _| {
                    signaler.emit(Message(Msg::from(PinnacleSourceMsg::Destroyed(win.clone()))));
                }
            }))));
    }

    fn update(&mut self, message: Msg) {
        let Some(msg) = message.into() else {
            return;
        };

        todo!()
    }

    fn tasks(&self) -> &[WindowHandle] {
        &self.windows
    }
}

impl Drop for PinnacleSource {
    fn drop(&mut self) {
        for handle in self.handles.iter() {
            handle.disconnect();
        }
    }
}

impl Task for WindowHandle {
    fn title(&self) -> String {
        self.title()
    }

    fn set_maximized(&mut self, maximized: bool) {
        self.set_maximized(maximized);
    }

    // ...
}

// The tasklist

pub struct Tasklist<S, Msg = UniversalMsg> {
    source: S,
    // other stuff here
}

impl<S: Source, Msg> Tasklist<S, Msg> {
    pub fn new(source: S) -> Self {
        let base = WidgetBase::new();
        source.register(base.signaler());
        todo!()
    }

    // ...
}

enum TasklistMsg {
    Activate { index: usize },
    SetMaximized { index: usize, maximized: bool },
    
    // Maybe a custom message to have access to the actual task.
    // 
    Custom { .. },
}

impl<S> Program for Tasklist<S, Msg>
where
    S: Source<Message = Msg>,
    S::Task: Task,
    Msg: Clone + From<TasklistMsg> + Into<Option<TasklistMsg>>,
{
    type Message = Msg;

    fn update(&mut self, message: Self::Message) {
        let Some(msg) = message.into() else {
            return;
        };

        if let TasklistMsg::Activate { index } = msg {
            self.source.tasks()[index].activate();
        }

        self.source.update(message.clone());

        todo!()
    }

    fn view(&self) -> WidgetDef<Msg> {
        let tasks: &[S::Task] = self.source.tasks();
        // build widget from tasks
        
        let button = Button::new(Text::new(tasks[0].title())).on_click(TasklistMsg::Activate {
            index: 0
        }.into());

        todo!()
    }
}

We'll need to provide a wlr-foreign-toplevel impl in Snowcap that exposes toplevel handles and signals, but this approach lets users swap out and define new implementations without having to make changes to Snowcap.

Now, you made a good point in #415 about the in-tree widget being able to know what output it's on, which is valuable information. I think instead of having that on a tasklist widget, we can create an OutputAware widget whose sole responsibility is to generate output messages. This gives us a reusable building block for anything else we want to make. Alternatively this could also be a signal, which would necessitate a connection in Program::created. Unsure of what should move forward there.

[Ph4ntomas]

I see two ways to do this: widgets and operations (implemented here), or signals and handles. Both allow us to retrieve task information and provide task controls, but the problem I see with the widget approach is that it's not user-customizable. Any configuration has to be done within the server and there's no way to, for example, plug in a different source for tasks without hand-rolling a separate signal + handle approach or making a new server implementation, at which point I'd rather have both solutions use signals and handles.

I think we have a different view on widgets :)

Iced already have some data-only widgets (e.g. mouse-area), and I was considering the WlrTaskList widget (at least the server-side) as a data-only widget. Those are not user-customizable, but neither would be a Signal & Handle based approach.
Assuming the user want some customization, they could roll their own view using several data-sources regardless of whether the data-source is in-tree or out-of-tree.

IMO the main difference between data-only widget/op and source/handle at that point is:

• Widget/op requires a surface to exists, but automatically send message/redraw UI.
• Signal/handle can work without any surface. When used in a widget/Program, it's that object responsibility to trigger an update/redraw. Since they're not tied to a surface, you could have a single signal source for multiple widget, or use it without any surfaces.

But anyway :

A theoretical impl

This is how I envision the Rust side to look like with Pinnacle WindowHandles as a task source for example:
[snippet]

Yeah, I had a similar-ish idea where talking about the Source trait in #414. I'm fine with that approach, too. I'll come back with some kind of implementation for this soon.

In #415 I mentioned that it wasn't possible to filter toplevels if the compositor did not send a name for them, but we can send a hash as an Id as long as we have some way to receive Output updates (signal || ui-based message)

[Ph4ntomas]

Widget/op requires a surface to exists, but automatically send message/redraw UI.

Okay, something I forgot, but IMO should be added:
data-only Widget/op usually represents user interactions, and considering tasks/toplevel as that is a stretch.

[Ottatop]

Iced already have some data-only widgets (e.g. mouse-area), and I was considering the WlrTaskList widget (at least the server-side) as a data-only widget.

While that's true, I think a big distinction and one of the reasons I prefer a signal+handle approach is that a mouse area needs to be in the widget tree because its size depends on parent and child widgets. In contrast, a WlrTaskList widget does not care about the state of the tree it's in at all (apart from knowing its output, but this doesn't really depend on the tree per-se and, as I mentioned, could be extracted into a lower level building block).

[Ph4ntomas]

Yup, I agree :)

I'll rework my PR