wf-panel: titlebar and desktops

[wayfirewm]

wf-panel: titlebar and desktops

[ammen99]

bklaase, there is a protocol for that (this is how it is implemented for the current window-list).
I guess it should not be hard to implement a widget, but please understand that we cannot implement every possible widget a user wishes for :)

In this regard I think it may make sense to allow custom widgets in the same way wayfire plugins work, so you can then add this widget on your own.

[ammen99]

@bklaase, the best way to reach out for help especially for development is #wayfire on freenode. It may not be ideal though since you'd need constant internet connection go receive replies.

Anyway, Wayland is just a way for IPC. It is actually a socket internally afaik :)

The protocols are built on top of this abstraction, and the header you mentioned is autogenerated to abstract away the lowlevel details from clients.

[soreau]

What do you mean by client title widget? There is window-list widget if that's what you're looking for. Workspace information/control isn't provided by the wayfire shell protocol, and that would have to be added to create a workspace switcher widget.

[bklaase]

Ah, I missed the window list. I meant a widget that just displays the text of the title of the active window. I like to have that be in the panel center, like so:
https://i.imgur.com/dvBYxN3.png

I know it's still early days, but if wayfire could dump it's status like bspwm/i3/sway/etc, users can easily create their own panels.

Thanks for replying so quickly btw!

[bklaase]

So, I'm dusting off my c++ "skills" and I want to start off very simple: Make a tool that, using the protocol can react to events (desktop changed, title changed, window created, etc) and dump info to STD out, so that people can use that in script based widgets/dmenu replacements.

However, if you could give me a small nudge in the right direction (or point out why this approach is nonsene), I would greatly appreaciate it!

I have read the wiki page on plugin-arch and looked at the code for various plugins and the wf-shell repo.

I feel there are two approaches: make this into a plugin that outputs to a configuratble socket, which can then be read by various tooling (the bspwm / i3 / sway etc model)
Or: view this as something that ought to belong in wf-shell and simply writes to stdout.

What would be a good starting place?

[soreau]

So, I'm dusting off my c++ "skills" and I want to start off very simple: Make a tool that, using the protocol can react to events (desktop changed, title changed, window created, etc) and dump info to STD out, so that people can use that in script based widgets/dmenu replacements.

This approach would be fine for displaying stuff from wayfire but wouldn't be able to talk back to wayfire for things like desktop switching and window control (focus/maximize/minimize/close).

However, if you could give me a small nudge in the right direction (or point out why this approach is nonsene), I would greatly appreaciate it!

I have read the wiki page on plugin-arch and looked at the code for various plugins and the wf-shell repo.

Unfortunately, the plugin-arch page is pretty out-of-date. The source is probably the best reference and of course you can always ask about stuff you don't understand.

I feel there are two approaches: make this into a plugin that outputs to a configuratble socket, which can then be read by various tooling (the bspwm / i3 / sway etc model)

This would work but I feel this belongs in a standalone program rather than a plugin.

Or: view this as something that ought to belong in wf-shell and simply writes to stdout.

I don't think wf-shell is a good place for this.

What would be a good starting place?

I'd probably write a standalone program (C++ is not mandatory) that relays the protocol information to/from a socket and in turn, to any other client/script.

[ammen99]

A good starting place for showing the active window would be https://github.com/swaywm/wlroots/blob/master/examples/foreign-toplevel.c and the protocol that this example uses. There you can see how you can list all open windows on an output, and how you can listen for new window / window focused / etc.

Maybe you want to create a small daemon similar to swayidle which internally uses a protocol to communicate with the compositor, but then exposes scripting capabilities?

Wrt active desktop/workspace, there is this protocol here: swaywm/wlr-protocols#35

I think the best approach is creating the appropriate wayland protocols. With the changes to the governance of wayland-protocols upstream, we have hopes of making those protocols cross-compositor and letting programs work on Sway/Wayfire/etc without caring about the underlying compositor.

In any case, if you want to make a widget in wf-panel itself, then you'll have to change the panel's widget loading mechanism to just load arbitrary plugins from .so files like Wayfire does. This should not be hard since we already have some kind of interface for widgets in wf-panel, so the problem is porting the dlopen/dlsym/etc dance from Wayfire. I can try to answer any questions you might have on those points, let me know :)

[bklaase]

Thank guys, for these complete and helpful answers!
As a developer myself, I can understand the immense value in having features such as these solved in a sustainable way that benefit all Wayland compositors, not even "just" wlroots.

And (re)picking up c++ is precisely that I can eventually start contributing to these great initiatives that I make use of daily. I am a developer by trait, just not systems level development, so it's a bit of a shift. In the short term, I do love working in a desktop environment that feels like a toy .. ;). So for the short term I want something that I can implement as quickly as possible to use wayfire as main driver (not much is required, since any WM/OS is basically a bootloader for Emacs, of course) and I feel that if I can retrieve title of active window, desktop layout (or even numbers) + active desktop, that I'm there. Well, that and having a 2 px border consistency for ALL windows (but that is effectively achieved with the option of preferring server (vs client) decorations, already)

That's why this speaks to me:

I'd probably write a standalone program (C++ is not mandatory) that relays the protocol information to/from a socket and in turn, to any other client/script.

However, I do expect the protocol still being something to link to on the compiler level? Not something that is exposed currently? It's refering to wlr-foreign-toplevel-management-unstable-v1-client-protocol.h ?

If I get started on this, would you prefer I keep asking questions in this issue, or some other way?

Thanks again for taking the time to not only develop this great project, but also being so welcoming to the uninitiated :)

[bklaase]

ok! I'll use that channel then and close the issue :)