Wayland and BunsenLabs

hhh · 2024-06-24 03:36:16

Woops, I didn't paste the hyprlock link. One minute, I'll update the post.

-edit- hyprlock download link added

Last edited by hhh (2024-06-24 03:40:04)

johnraff · 2024-06-24 04:05:09

hhh wrote:

I have a fairly nice config going for nwg-bar as an exit app though, that uses swaylock to lock the screen on suspend...
https://i.imgur.com/FBMGZ22t.png

Looks nice, but we might be able to continue using bunsen-exit. Just have to make sure loginctl calls the appropriate locker, whether on X or Wayland. If that doesn't happen automatically, then a fallback is to make LOCK_SCREEN_COMMAND user-configurable.

@micko01 brought this up on GitHub a while ago: https://github.com/BunsenLabs/bunsen-exit/pull/6

EDIT: with any luck, loginctl might detect hyprlock as easily as swaylock, and send the lock command to whichever daemon is running. (They are daemons?)

EDIT2: with no LOCK_SCREEN_COMMAND set, bl-exit calls

loginctl lock-session $XDG_SESSION_ID

which I think passes on the lock command to whatever lock utility is available. I've just confirmed that the above command works on Boron - could you @hhh or anyone running Wayland with a locker utility installed, check what happens if that command is run in a terminal?

Last edited by johnraff (2024-06-24 05:19:17)

johnraff · 2024-06-24 06:03:10

hhh wrote:

...there is a lot of info and a lot of questions, and some of it should be split into individual threads

micko01 wrote:

Speaking of the repo, it's up!
Only 2 packages azote and labwc-menu-generator, but it is a success! I enabled it on my laptop and after sudo apt update I was offerred to update labwc-menu-generator_0.1-1 to labwc-menu-generator_0.1.0-1! Works a treat . Also installed azote.
Now onto building some more packages .. hopefully I'll have a few done by the end of the week-end.

Maybe this topic is important enough to merit its own thread? Especially if people might post requests to add packages.

Here: https://forums.bunsenlabs.org/viewtopic.php?id=9031

Last edited by johnraff (2024-06-24 07:06:32)

johnraff · 2024-06-24 06:54:07

Snipped this out of micko's repo top post, so pasting here:

micko01 wrote:

^yes gimp-3.0 was slated for release this year but with such a complex code base I can understand holding back.
I used to use mtpaint a lot and there is a patch to make it wayland friendly - it may make it to my repo with said patch. Edit to add - uploading mtpaint package shortly

Bearded_Blunder · 2024-06-24 12:58:13

Oh I completely see that for development.

johnraff · 2024-06-27 00:15:30

The BL carbon packages are pretty much all migrated now and ready for use on Trixie systems. Of course they might get upgrades before official release time...

There is now a carbon branch of the netinstall script, but more relevant for this thread, also a carbon-wayland branch:
https://github.com/BunsenLabs/bunsen-ne … on-wayland

Micko01's experimental repo is enabled out of the box, but no wayland-oriented package list changes have been made yet, eg openbox replaced by labwc...

@micko01 if you'd care to fork carbon-wayland then I'll be happy to merge in any PR's you send.

wrt package lists, I'd recommend ignoring pkgs-{recs,norecs} and pkgs-{recs,norecs}-lite and just focus on pkgs-recs-base and pkgs-norecs-base for now. In fact, I've commented out the part of the install script where the user is offered that choice, leaving only the "base" install. The fuller options can go back in after "base" is sorted.

If you want to ship some user configs, you can put files in the directory "userfiles" which I've just added. If the directory is non-empty its contents will be recursively copied into the user's $HOME. This might be a useful workaround until a wayland-gnostic bunsen-configs arrives.

Last edited by johnraff (2024-06-27 07:27:59)

tynman · 2024-06-27 23:08:00

In post #155, Johnraff mentioned,

(I've said it before, but I'm quite unhappy about losing jgmenu.)

A few months ago I played with labwc under Debian Bookworm/SID, and I was pleased to find that Jgmenu worked fine. I ended up abandoning my labwc as too prone to hanging/crashing - but as far as I know Jgmenu wasn't the problem

So unless you know something I don't know, maybe don't give up on Jgmenu. (definitely my most favorite menu application anywhere)

hhh · 2024-06-27 23:42:29

^ jgmenu is an x11 menu, it runs on Wayland via Xwayland, so we can still use it. But @malm is slowly working on a no-gtk, no-x11 menu, trappist...

https://github.com/johanmalm/trappist

johnraff · 2024-07-12 04:26:59

This morning, wondering about Wayland sessions, did some websearching and found a few links:

https://wiki.debian.org/Wayland

If you have fully switched and want to check whether an application is using native Wayland support or XWayland, the easiest way is to run the xeyes program, and check whether the eyes still track the cursor when that is inside the application window.

environment-variables-for-wayland-hackers
gtk backend selection or why gtk cannot open display 0
Running programs natively under wayland
Useful add ons for sway (long list, not only for sway)
wayland session and xwayland configuration

https://wiki.archlinux.org/title/Display_manager

Many display managers read available sessions from /usr/share/xsessions/ directory. Some display managers use a separate /usr/share/wayland-sessions/ to list Wayland-specific sessions.

Redhat 8 desktop display options - wayland or X11
Ubuntu session x11 instead of wayland

(repeat post xfce roadmap because it's useful:)
https://wiki.xfce.org/releng/wayland_roadmap
(xfce4-panel now supports wayland:)
https://gitlab.xfce.org/xfce/xfce4-pane … quests/103

xfce4-panel dev wrote:

The two main compositors used for this work (xfce4-panel) are Labwc and Wayfire.
My preference is Labwc for its simplicity and development goals...

Overall impression: people are working hard on getting things to run on Wayland, but there are many details not finished yet, and users will run into a lot of functionality - that they got used to on X11 - not working. I think the chances of a BL Wayland Carbon, even close in functionality to the X11 version, are small. It will have to be something pretty basic, for hackers to play with. But we should do it anyway, and maybe in a couple of years the scene will be very different.

Last edited by johnraff (2024-07-17 07:39:28)

Bearded_Blunder · 2024-07-13 06:55:56

I'm tending to agree even though I've little time to experiment right now, a Wayland / Carbon branch equivalent to Sid seems in order, & possibly one for Nitrogen equivalent to Testing, before a switch of default...

There's no tearing rush, X works. Even if there are advantages to the new tech.

malm · 2024-07-14 19:42:24

Just catching up and feel this needs a response...

johnraff wrote:

^bl-libreoffice-pipemenu and bl-multimedia-pipemenu are no longer used unfortunately. In fact they no longer exist, since Lithium.
The new install menu spits out jgmenu csv code so that will have to be rewitten for labwc.
But it outputted XML in an earlier incarnation so it might not be too hard, and of course openbox on BL/X will happily use XML pipemenus.
(I've said it before, but I'm quite unhappy about losing jgmenu. I'm sure @malm had good reasons, but...)

I don't feel there is an easy answer - but if I provide some context I suppose the statement/question might develop...

I wrote most of jgmenu during 2015-2018 and at that time I really didn't know much about Wayland. I had been on X.Org Server for a long time and rather liked it. I wrote a number of small things using both Xlib and xcb; and to be honest I didn't really see the technology-stack change coming. In fact it was o9000 (the maintainer of tint2 at the time) who voiced annoyance a number of times that Wayland was throwing the baby out with the bath water, and that sort of drew my attention to it and got me curious.

I'm generally NOT an early adopter of new technology, but in 2019 I started dedicating some time to understand Wayland and started coding some toy desktop tools because at that time it was becoming pretty clear that Qt/Gtk as well as Gnome/KDE were moving fast in that direction and the thought of not having a simpler, indepedent setup didn't sit well with me.

I was hopeful in the begining that I'd get jgmenu working via XWayland, but quite frankly - as we sit here today - I think it's an exaggeration to say that jgmenu works on Wayland. You could make it look like it's working IF you set position_mode=fixed, IF you don't expect it to close when you click outside the menu, and IF you don't expect the use more than one screen or indeed scale!=1.0. But to ship it with a Production quality distro would be completely out of the question in its current state.

So, why hasn't @malm just waved their magic wand to sort all that out?

Let's do this in steps:

1. Well to start with I've spent the last five years writing a compositor to keep the 'flame' alive so that there is actually something to use an independent menu with. Well - Wayfire is also a very good choice (quite different to labwc, but still) but I didn't know that at the time and surprisingly today there still aren't any other credible contenders around (I don't think!). You might consider Cosmic, but hey, we digress.

2. jgmenu uses Xlib/cairo/pango but implements most other things from scratch. In this sense it's similar to rofi and tint2; and in terms of tech-stack choice it's a pretty small club who live in that domain. The choice has a number of consequences:
- It's very powerful and allows a developer (me in this case) to create very specialist things because you're not tied to the inner workings of Gtk/Qt/Other.
- You have to implement a lot of things yourself like the event-loop, self-pipes, threads, file-locks, etc. for things that would normally come with a GUI toolkit.
- You can shape things to behave exactly how you want them - which for normal Desktop applications would most likely never be worth the effort (just use Gtk/Qt) but for a desktop-components is quite attractive. In practice that probably means override-redirect flags, XGrabKeyboard() and stuff like that which is a bit "wild west" in the eyes of Wayland and seems to be beyond me to get working consistently (without wrecking everything else) on Wayland... and by the way that seems to be the conclusion of other Wayland compositor devs too.
- So porting such an application to a different technology-stack like Wayland is hard (bordering on not credible) and I think most people would conclude that "starting again" is indeed faster and simpler.

3. Now, "starting again" can mean either "re-write" in the sense of porting to a new language/protocol/toolkit/whatever whilst maintaining feature parity; or "replacement" as in creating something that meets the users' needs but potentially does so in a different way.

4. Changing topically slightly, I suspect I've got five years left (minimum) of work on labwc before we can position it in some sort of "deep maintenance" state. I really enjoy it and don't feel it would be right/good to hand over the tech lead position any time soon. In comparison, openbox took 13 years (2002-2015) and they started with Blackbox which was already a working window manager. The reason I say all this is to clarify that the majority of any dev/maintenance time I can squeeze out of life is probably best spent on the labwc project.

5. A few people have mentioned trappist in this thread. Just to be clear - trappist is just a toy project of mine, with no real direction. A lot of the hard things have been implemented though (if the aim were to build an independent root-menu), but it's missing scaling, configuration, pipes, IPC, widgets and no doubt a few other things. I suspect a few months' of hard dev work could have you on par with how BL uses jgmenu (albeit implemented differently) - which is fundamentally a ob-root-menu as an independent, long-running processes with some better configuration options and type-to-search. At my current pace that probably translates to five years - if indeed anyone wants it!! So far the scope just follows my mood - nobody has expressed any wishes/needs, nor show any interest in thinking about it; nor contributing to it. If anyone wants to explore that further, I'd suggest starting with:
https://wayland-book.com/ and https://wayland.app/protocols/

Btw, have you noticed that openbox.org doesn't work anymore? We've made a copy here: https://redtide.github.io/openbox-wiki/

johnraff · 2024-07-15 03:18:50

@malm many thanks for this illuminating input!

malm wrote:

johnraff wrote:
(I've said it before, but I'm quite unhappy about losing jgmenu. I'm sure @malm had good reasons, but...)

First off - I hope you didn't see that as any kind of implied criticism. More the opposite - jgmenu works so well for me, not only in BL but in my personal desktop tweaks, that I'll be sad to have to give it up. It's really convenient to be able to throw up a small standalone menu from a script. Being independent of the window manager is another big plus IMO. There seem to be a lot of jgmenu fans!

...if I provide some context I suppose the statement/question might develop...
...it was becoming pretty clear that Qt/Gtk as well as Gnome/KDE were moving fast in that [Wayland] direction and the thought of not having a simpler, independent setup didn't sit well with me.

It would mean the end of BL, and a bunch of other alternatives for people who don't want a full-fat DE.

...to start with I've spent the last five years writing a compositor to keep the 'flame' alive so that there is actually something to use an independent menu with.

For which post-X BL users will be grateful!

Now, "starting again" [the menu] can mean either "re-write" in the sense of porting to a new language/protocol/toolkit/whatever whilst maintaining feature parity; or "replacement" as in creating something that meets the users' needs but potentially does so in a different way.

Sure, move forward. We'll cope with it.

...nobody has expressed any wishes/needs, nor show any interest in thinking about it [trappist]; nor contributing to it.

Trappist has been mentioned once or twice here on the BL forums, as something to maybe look forward to in the future...

But I feel quite guilty about asking for things to be made for my use when I'm unable to help. My skills are very much limited to shell scripting (eg I have a grasp of the Debian X session, live-build and the debian-installer) and simple Debian packaging. I'm afraid things like"override-redirect flags, XGrabKeyboard() and stuff like that" are way outside my comfort zone.

Btw, have you noticed that openbox.org doesn't work anymore? We've made a copy here: https://redtide.github.io/openbox-wiki/

No I hadn't! No announcement.

Someone on Reddit noticed that the git repo is still up, so it might be a technical issue. They're still on Archive, but thanks for storing away that copy of the Wiki.

I imagine openbox - and tint2 - will be available from Debian for some time longer, but if BL is to have a future it needs to at least be ready to make some changes.

Last edited by johnraff (2024-07-17 06:40:57)

johnraff · 2024-08-11 05:45:43

johnraff wrote:

malm wrote:
Btw, have you noticed that openbox.org doesn't work anymore? We've made a copy here: https://redtide.github.io/openbox-wiki/
No I hadn't! No announcement.
Someone on Reddit noticed that the git repo is still up, so it might be a technical issue. They're still on Archive, but thanks for storing away that copy of the Wiki.

It's back.
https://openbox.org/

johnraff · 2024-08-11 05:48:45

Post copied from here: https://forums.bunsenlabs.org/viewtopic … 33#p136833

hhh wrote:

We're not migrating to labwc for this release, are we?

Not if it's up to me. In fact No Way comes closer. The more I look at the nitty-gritty of Wayland the more I want to stay on X11, at least for another release. There's so much that devs seem to say "it's up to the compositor to implement" and it's just not there yet. So many small details, like, eg xfce4-screenshot on Wayland is unable to capture "the active window", something I use all the time. Hackers might be fine with things that way, but I don't think "just let me get on with my life" users will appreciate it.

But labwc looks like a very nice piece of work (like jgmenu), and once 99% of those annoyances have been fixed then of course I think we should switch to Wayland.
Eventually...

I think BL Wayland should just be a side project for this release.

For sure. Recently I've been spending a lot of time thinking about how best that can be implemented so people who want to try BeakerLand (or whatever it gets called) can just install a package on regular BL Carbon and have a login "Bunsenlabs-Wayland" option appear. At the same time people who want to stay on X11 as long as possible should not have their lives disrupted. This thread: https://forums.bunsenlabs.org/viewtopic.php?id=9081

One change that might have to come in is swapping out lightdm for greetd+cage+nwg-hello, or some other wayland-supporting DM like ReGreet. Right now, I'd prefer to stick with lightdm but there seem to be issues with it launching Wayland. It would be a pity if we had to force a deterioration of the login experience on Carbon X11 users, but we might be forced to make a compromise, just so the Wayland plugin option becomes possible. But choice of DM is not "Carbon Themes" and needs its own thread.

johnraff · 2024-08-11 05:55:45

hhh wrote:

IMO... Stay with OB and lightdm, because we also have light-locker tied into that, and trying to get a cross X11/wlroots screen-locker is not in the cards in the near future. Make BL-Wayland it's own separate, experimental thing for now.

The thing is, making BL-Wayland a completely separate thing looked as if it might be more work than a basic addon would be. But the details still need to be worked out. Like, what packages would it go in? Would every BL package need to have a separate Wayland version?
EDIT: I now remember - another point was that having a two-system install would give users who messed up in Wayland a way back to their system on X11, where they could get sorted. But to repeat - this is going to be an optional install in Carbon at best. Default will be X11-only, as now.

---
The locker: light-locker won't work on Wayland but if we add a bit of script to bl-exit to test for an X11 or Wayland session it might be possible to cover both cases. I get what you say about the light-locker<->lightdm (and xfce4-power-manager) connection and we certainly don't want to break that.

---
Lightdm is the one thing I'm not sure about. Maybe the Wayland addon package could replace it with a wayland DM when/if it's installed, leaving lightdm for default X11 users only?

johnraff · 2024-08-25 09:44:47

johnraff wrote:

One change that might have to come in is swapping out lightdm for greetd+cage+nwg-hello, or some other wayland-supporting DM like ReGreet. Right now, I'd prefer to stick with lightdm but there seem to be issues with it launching Wayland. It would be a pity if we had to force a deterioration of the login experience on Carbon X11 users, but we might be forced to make a compromise, just so the Wayland plugin option becomes possible.

Anyway, I've added a few files (courtesy of micko01) to bunsen-configs so it will support the greetd cage nwg-hello option as well as lightdm, for logging into X11 and Wayland too (if it's installed).
https://github.com/BunsenLabs/bunsen-co … edb4822c89

DeepDayze · 2024-08-25 14:57:35

johnraff wrote:

hhh wrote:
IMO... Stay with OB and lightdm, because we also have light-locker tied into that, and trying to get a cross X11/wlroots screen-locker is not in the cards in the near future. Make BL-Wayland it's own separate, experimental thing for now.
The thing is, making BL-Wayland a completely separate thing looked as if it might be more work than a basic addon would be. But the details still need to be worked out. Like, what packages would it go in? Would every BL package need to have a separate Wayland version?
EDIT: I now remember - another point was that having a two-system install would give users who messed up in Wayland a way back to their system on X11, where they could get sorted. But to repeat - this is going to be an optional install in Carbon at best. Default will be X11-only, as now.
---
The locker: light-locker won't work on Wayland but if we add a bit of script to bl-exit to test for an X11 or Wayland session it might be possible to cover both cases. I get what you say about the light-locker<->lightdm (and xfce4-power-manager) connection and we certainly don't want to break that.
---
Lightdm is the one thing I'm not sure about. Maybe the Wayland addon package could replace it with a wayland DM when/if it's installed, leaving lightdm for default X11 users only?

Any chance of bug report to lightdm (and light-locker) devs about adding better support for launching Wayland sessions?

Last edited by DeepDayze (2024-08-25 14:58:19)

johnraff · 2024-08-26 06:33:26

DeepDayze wrote:

Any chance of bug report to lightdm (and light-locker) devs about adding better support for launching Wayland sessions?

We'd need to do some debugging ourselves first, if the report is going to be helpful. Also some websearching to see if anyone else is getting problems launching Wayland sessions from LightDM. First, find where the lightdm logs are, and if it has a "verbose" option we can set somewhere. It's strange, because by the time the session has been started (by executing the command in a .desktop file) lightdm should have left the scene altogether...

And why does nwg-hello have no problems?

hhh · 2024-08-29 01:00:01

apt lets me install both xfce4-notifyd (x11/carbon w/ openbox) and mako-notifier (wlroots/carbon w/ labwc), but the two notifiers cancel each other out when you boot. They both try to access dbus, and they both fail since only one is allowed.

DeepDayze · 2024-08-29 02:44:46

hhh wrote:

apt lets me install both xfce4-notifyd (x11/carbon w/ openbox) and mako-notifier (wlroots/carbon w/ labwc), but the two notifiers cancel each other out when you boot. They both try to access dbus, and they both fail since only one is allowed.

Should be a way to have each only start in their respective sessions.

#161 2024-06-24 03:36:16

Re: Wayland and BunsenLabs

#162 2024-06-24 04:05:09

Re: Wayland and BunsenLabs

#163 2024-06-24 06:03:10

Re: Wayland and BunsenLabs

#164 2024-06-24 06:54:07

Re: Wayland and BunsenLabs

#165 2024-06-24 12:58:13

Re: Wayland and BunsenLabs

#166 2024-06-27 00:15:30

Re: Wayland and BunsenLabs

#167 2024-06-27 23:08:00

Re: Wayland and BunsenLabs

#168 2024-06-27 23:42:29

Re: Wayland and BunsenLabs

#169 2024-07-12 04:26:59

Re: Wayland and BunsenLabs

#170 2024-07-13 06:55:56

Re: Wayland and BunsenLabs

#171 2024-07-14 19:42:24

Re: Wayland and BunsenLabs

#172 2024-07-15 03:18:50

Re: Wayland and BunsenLabs

#173 2024-08-11 05:45:43

Re: Wayland and BunsenLabs

#174 2024-08-11 05:48:45

Re: Wayland and BunsenLabs

#175 2024-08-11 05:55:45

Re: Wayland and BunsenLabs

#176 2024-08-25 09:44:47

Re: Wayland and BunsenLabs

#177 2024-08-25 14:57:35

Re: Wayland and BunsenLabs

#178 2024-08-26 06:33:26

Re: Wayland and BunsenLabs

#179 2024-08-29 01:00:01

Re: Wayland and BunsenLabs

#180 2024-08-29 02:44:46

Re: Wayland and BunsenLabs

Board footer