Allow to run multiple instances of AwesomeWM and communicate between them with dbus

[actionless]

The concept is that i wanna hv smth like this in my init script:

awesome --config ./rc_wm.lua --name "wm" --disable-naughty &
awesome --config ./rc_notifications.lua --name "naughty" --disable-wm &
awesome --config ./rc_panels.lua --name "panels" --disable-wm --disable-naughty

and inside the config to hv smth like this:

awesome_remote("panels"):emit_signal("top_panel::expand", {some_data})
awesome_remote("naughty"):emit_signal("naughty::close_all", {some_data})

and so on

WDYT?

[Elv13]

This would require to strip out the window management code from the "other" processes (and most of capi). It might also be easier to do share-nothing threads within the main process and use lua built-in serialization to send messages to the thread mainloop. That requires to strip even more our of capi to avoid race conditions.

[actionless]

i understand that inter-communication could be tricky and be implemented in different approaches, however for starters i'm more curious, how complicated could be implementing --disable-wm and --disable-naughty?

[Aire-One]

--disable-naughty is a frequently requested feature, so it would make sense to support it at some point. (Maybe through startup options/modeline https://awesomewm.org/apidoc/documentation/09-options.md.html ?)

To my understanding, --disable-wm would basically allow creating wiboxes/widgets on a "standalone mode". @xinhaoyuan already made some work on this direction: https://github.com/xinhaoyuan/awexygen. Widgets that interacts with the WM features would require some ipc/dbus work to be done on the awesome backend side.

[sclu1034]

What's the use case, even?
--disable-naughty makes sense for people that want to use other daemons, like dunst. awexygen makes sense as a way to bring your UI to other WMs. So in both cases, the point is compatibility with other applications.

But what's the use case for this when all of it stays within Awesome anyways? What do you need separate processes for?

[actionless]

What's the use case, even?

because rendering panels in the same thread as doing window-management stuff is cringe

and also should allow using awesome panels/widgets with hyprland

[joaopauloalbq]

What's the use case, even?

because rendering panels in the same thread as doing window-management stuff is cringe

and also should allow using awesome panels/widgets with hyprland

Making Awesome multithreading and making Awesome do what Hyprland does is a better approach IMO.

[actionless]

@joaopauloalbq are you willing to contribute that code..?

[actionless]

also some after-thoughts:

1. would we also need --disable-root flag probably? (or it's logical to assume that with --no-wm)
2. since multi-threading was mentioned couple of times, i'll also add few cents about that (not in relation to main topic, mb even worth creating separate ticket for this point) - that actually would be dope to make separate drawing thread, but it would require rewriting big bunch of code, as now all drawing-related code is written synchronously
3. and also after adding some decent Scrollable Area kind of widget, awesome in no-wm mode could be a nice UI toolkit for writing some small apps, as current ui toolkits either crazily bloat like gtk and qt, either not able to follow the system theme settings like tk or fltk