carbon-wayland

micko01 · 2024-07-14 04:35:23

Of course you need proof or it didn't happen!

johnraff · 2024-07-14 08:21:37

Confirmed!

It looks very nice.

But I have some hurdles to jump before I can call it a usable system.

First off, how to set the keyboard layout to my jp keyboard? Googling wasn't encouraging, eg
https://lars.ingebrigtsen.no/2024/04/28 … n-wayland/

Open file as root from Thunar doesn't work because those pkla files...

No Win key keybinds?

But great job nevertheless!
You must have put a lot of work into it.

Last edited by johnraff (2024-07-14 08:54:36)

micko01 · 2024-07-14 09:14:53

johnraff wrote:

First off, how to set the keyboard layout to my jp keyboard? Googling wasn't encouraging

labwc-tweaks-gtk can handle keyboard layouts but @malm is concentrating on the Qt version and it has attracted more interest. Still, the gtk version has it's place and and I can probably push some PRs when I have the time to get it up to speed.

johnraff wrote:

pkla

'nuff said. Had a look but yeah, trixie dev's problem really. Will add if I can eventually.

johnraff wrote:

No Win key keybinds?

They do work if configured. That is WIP and when we get this up to speed I'll take user input on board.

Thanks for the feedback

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

I've got some ideas about simplifying the approach for 01micko's bunsen-config-wayland package. Was just logging in to ask what thread to post that in.

But... whilst I'm here :smile:

johnraff wrote:

First off, how to set the keyboard layout to my jp keyboard?

Put these in your ~/.config/labwc/environment

XKB_DEFAULT_LAYOUT=gb,jp
XKB_DEFAULT_OPTIONS=grp:shift_caps_toggle

https://github.com/labwc/labwc/blob/3be … nt#L20-L23

The labwc-tweaks tools provides a GUI for setting XKB_DEFAULT_LAYOUT in case users don't know their language codes (which most probably don't).

I have to admit - I can't even remember how one does this on X

johnraff wrote:

No Win key keybinds?

We support this from 0.7.3

https://github.com/labwc/labwc/blob/mas … S.md#added

<keybind key="Super_L" onRelease="yes" name.action="ShowMenu" menu.action="root-menu"/>

In the interest of comparison, Openbox doesn't actually support this, so under X.Org Server we have previously used xcape and similar to listen to all key events (security implications obvious) whereas labwc supports it directly.

Last edited by malm (2024-07-14 09:26:10)

malm · 2024-07-14 10:04:57

Thoughts on keeping packaging simpler and treating as a bolt-on for users to evaluate.

Ref:

- https://github.com/BunsenLabs/bunsen-configs/pull/131
- https://github.com/BunsenLabs/bunsen-configs/pull/132

1. Remove greetd, nwg-hello (suggest putting that setup in a separate repo for now - just keep it away from bunsen-configs to make it easier to merge)
2. Don't put labwc+sfwbar in skel/ or skel-base/ because they're likely to change a lot as people test, and ones they're in people $HOME directory you can't control them.
3. Regarding sfwbar - have you actually modified any of the widgets? If not, it's enough to just use sfwbar.config (which is much cleaner).

So instead...

a. Agree the minimum debian dependecies (possibly just labwc, sfwbar, grim, swaybg, swaylock, kanshi, qt5-wayland, qt6-wayland)
b. Install config files /etc/xdg/{labwc,sfwbar} for a pre-configured base system. If you then run with `labwc --merge-config` https://labwc.github.io/labwc.1.html#en … rge-config users can still setup their keyboard-layout, shortcuts, etc in $HOME. This is how Raspberri Pi have done it and I think there is a lot to be said for it.
c. Create some basic openbox compliant bl-ob-pipemenu (as we did before jgmenu) just to get the basics going.
d. Don't complicate things in this first step by adding color-pickers, wallpaper-setter-gui, etc. Just provide some notes on how to do all that manually. In line with my proposed direction here, a single-file gtk/qt python script would also be a lot easier to bundle in a bunsen-config-wayland package - for example for a nitrogen replacement.
e. I don't personally use a display-manager but think that "labwc" will just appear in lightdm on installation. Again RPiOS have taken this approach (https://github.com/labwc/labwc/issues/1970).
f. Try hard not to touch any extant bunsen-config files in this evaluation period. I might be wrong - but suspect we won't need to. It's a lot easier to digest + merge that way.

-- EDITED --
For comparison:
- https://github.com/raspberrypi-ui/raspb … /xdg/labwc

Last edited by malm (2024-07-14 10:10:34)

micko01 · 2024-07-14 11:52:49

malm wrote:

1. Remove greetd, nwg-hello (suggest putting that setup in a separate repo for now - just keep it away from bunsen-configs to make it easier to merge)
2. Don't put labwc+sfwbar in skel/ or skel-base/ because they're likely to change a lot as people test, and ones they're in people $HOME directory you can't control them.
3. Regarding sfwbar - have you actually modified any of the widgets? If not, it's enough to just use sfwbar.config (which is much cleaner).

1. I have a HP laptop that absolutely refuses to work with lightdm and wayland. I'm sure I wouldn't be the only one. Fair enough to make it a separate package. I'll do that and take it out of bunsen-configs.
2. Do you think no configs? Not too sure about that but I can probably simplify them more.
3. Yes I have several configs/widgets for sfwbar and they just give a nice look and feel. Maybe a separate package?

as for a. we haven't got much apart from @hhh 's packages for hyprlock, hyprconf. There's a weird bug in swaylock where backround doesn't show if you timeout for over 300 seconds.

b. Only have configds packaged, so that should be ok.

c. working on pipemenus. I have a wrapper script around the menu that supports pipe-menus. Works well.

d. I do have yad gui's that I wrote a while ago that covers themeing. Might revive them.

e. See above about HP laptop, plus it drags in X and all it's dependencies.

f. Only playing with bunsenlabs-session and the user autostart. What I've changed seems good.
https://github.com/01micko/bunsen-confi … bc4eef487a
https://github.com/01micko/bunsen-confi … 09f8fa62cd

Thanks!

unklar · 2024-07-14 15:44:04

I've only just read @malm's posts.
Clear, structured, understandable, thanks for that

@micko01,
This morning I tested your carbon script with a debian-netinstall on my desktop.

I was not able to get to the nwg-helo screen.
Before the second test I had copied from /usr/share/doc/labwc to ~/home (set in environment de as a precaution).

Same behavior.
With labwc I now get to the desktop and have utf-8_US, instead of the set utf-8_DE...

I will now wait until you release a new test.

PS: On this HP laptop the carbon-wayland-labwc runs very smoothly and well. Other installed applications are qpdfview and audacious.
I notice that the script only installs pipewire. However, the pipewire-pulse package is still missing, otherwise the user has no sound because it fails:

pactl info | grep '^Name des Servers'
Name des Servers: PulseAudio (on PipeWire 1.2.1)

hhh · 2024-07-14 18:14:55

malm wrote:

<keybind key="Super_L" onRelease="yes" name.action="ShowMenu" menu.action="root-menu"/>

Impressive, your team is great!

PackRat · 2024-07-14 19:11:57

hhh wrote:

malm wrote:
<keybind key="Super_L" onRelease="yes" name.action="ShowMenu" menu.action="root-menu"/>
Impressive, your team is great!

And it works as advertised. Just added to Void-labwc setup labwc; labwc-0.7.3_1

malm · 2024-07-14 19:45:49

hhh, unklar, PackRat - thanks

01micko wrote:

2. Do you think no configs? Not too sure about that but I can probably simplify them more.

Yes, we need configs. I meant to put them under /etc/xdg/ rather than in $HOME/.config/

IIRC anything you put in skel/ goes to $HOME/ (but it's been a long time, so might remember wrong)

johnraff · 2024-07-15 04:51:06

micko01 wrote:

johnraff wrote:
First off, how to set the keyboard layout to my jp keyboard? Googling wasn't encouraging
labwc-tweaks-gtk can handle keyboard layouts but @malm is concentrating on the Qt version and it has attracted more interest. Still, the gtk version has it's place and and I can probably push some PRs when I have the time to get it up to speed.

Please don't worry about that. I was just wondering what file to edit - up to now it's been /etc/default/keyboard on Debian, and on this test VM it had already been set to my jp keyboard but was being ignored on the Wayland session.

malm wrote:

johnraff wrote:
First off, how to set the keyboard layout to my jp keyboard?
Put these in your ~/.config/labwc/environment
XKB_DEFAULT_LAYOUT=gb,jp
XKB_DEFAULT_OPTIONS=grp:shift_caps_toggle
I have to admit - I can't even remember how one does this on X

It's in /etc/default/keyboard
/etc/default holds a lot of Debian, er, default settings. Some day they should arrange for Wayland stuff to go in there too. It seems a pity that each wayland compositor has to set keyboard layouts for itself. Or can those environment variables be set higher up in the chain where any compositor will see them? Or even in /etc/default/keyboard along with the XKB settings already there?? (I'll give it a try.)
(EDIT: adding XKB_DEFAULT_LAYOUT=jp to /etc/default/keyboard didn't work, but ~/.config/labwc/environment did.)
my /e/d/k:

XKBMODEL="pc105"
XKBLAYOUT="jp"
XKBVARIANT=""
XKBOPTIONS=""

BACKSPACE="guess"

micko01 wrote:

johnraff wrote:
pkla
'nuff said. Had a look but yeah, trixie dev's problem really. Will add if I can eventually.

I need to learn the new syntax for Carbon/Trixie anyway, so I'll have a look too. You have plenty to work on.

johnraff wrote:
No Win key keybinds?
They do work if configured. That is WIP and when we get this up to speed I'll take user input on board.

Again, you don't have to take the whole BL project's Wayland future on your shoulders! I just wanted to know at this stage if the Win keybinds would be usable. I think they can be considered a feature of BL. If Win is available then we can just migrate across the current keybinds as they are - minus the ones which are inapplicable of course.

Last edited by johnraff (2024-07-15 05:42:04)

johnraff · 2024-07-15 04:52:52

malm wrote:

johnraff wrote:
No Win key keybinds?
We support this from 0.7.3
https://github.com/labwc/labwc/blob/mas … S.md#added
<keybind key="Super_L" onRelease="yes" name.action="ShowMenu" menu.action="root-menu"/>
In the interest of comparison, Openbox doesn't actually support this, so under X.Org Server we have previously used xcape and similar to listen to all key events (security implications obvious) whereas labwc supports it directly.

Nice!

johnraff · 2024-07-15 05:06:44

malm wrote:

Yes, we need configs. I meant to put them under /etc/xdg/ rather than in $HOME/.config/
IIRC anything you put in skel/ goes to $HOME/ (but it's been a long time, so might remember wrong)

That's still true. The contents of skel/ get copied into ~/ on the user's first login by bl-user-setup (a flag file is created to block repeats). While I agree it's cleaner to put config files in /etc if that works too - and the configs are likely to be the same for all users - it's still not a lost cause if they go in skel/. bl-user-setup does a quick check at every login, notifies the user if there are new files and asks (individually) whether to import them (a diff is offered too). More bother for users but handy during a rapid development phase. @malm you helped me get bl-user-setup written.

johnraff · 2024-07-15 09:57:18

The bunsenlabs-session needs a bit more disentangling.
I was trying to enable lxpolkit as a possible replacement for policykit-1-gnome which will be dropped from Trixie...

For that I put an entry in ~/.config/bunsen/autostart but it didn't launch lxpolkit.

When launching labwc in Wayland, ~/.config/bunsen/autostart is launched from a subshell in /usr/bin/bunsenlabs-session and doesn't get the WAYLAND_DISPLAY envvar (which is set by the compositor), so the tests for a Wayland session don't work.

# Run the window manager.
case "$win_man" in
openbox)
    exec /usr/bin/openbox --config-file "$usr_confdir/openbox/bl-rc.xml" --startup "$bl_autostart"
    ;;
*)
    (
    until pgrep -x "$win_man"
    do
        sleep 0.5s
    done
    "$bl_autostart"
    ) &
    exec "$win_man"
    ;;
esac

See? The loop is trying to make sure $win_man is already running before running $bl_autostart, but as a result $bl_autostart is in a separate subshell and doesn't get the envvars that $win_man is setting. That seemed to work OK on X (although alternative window managers didn't get a lot of testing) but not on Wayland.

First attempt (but see below)
To get round that I created a new envvar WAYLAND_SESSION=true if bunsenlabs-session is called from the bunsen-wayland-session symlink.

case $0 in
    *bunsenlabs-wayland-session)W=true
    WAYLAND_SESSION=true
    export WAYLAND_SESSION 
    ;;
esac

That worked, but meant rewriting the tests in ~/.config/bunsen/autostart

But lxpolkit still wasn't getting started. I guessed it needed to inherit those envvars from the window manager too.

better fix
Eventually read 'man labwc' and made a new line to launch labwc with $bl_autostart as --startup

case "$win_man" in
#openbox
labwc)
    exec /usr/bin/labwc --startup "$bl_autostart"
    ;;
# etc

That worked and made the above envvar unnecessary after all.
But the user autostart still needs more wayland-proofing - I'm out of time now but will have another look tomorrow.

Last edited by johnraff (2024-07-16 01:16:37)

johnraff · 2024-07-16 01:09:27

Unlike /usr/bin/bunsenlabs-session and /usr/lib/bunsen/configs/bunsen-autostart which are mainly edited by developers, $HOME/.config/bunsen/autostart is available for users to edit however they want. For this reason I think we should avoid too many shell expressions and as far as possible just put straight statements in there. The large number of [ -z "$WAYLAND_DISPLAY ] conditions in the suggested bunsen-configs-wbase autostart, while doing the job, make me uncomfortable. Even more than that, the explanation about choosing the window manager is hard to understand, maybe saying that when using labwc on wayland it should be set to openbox.

I'm now thinking that users might be less confused if we shipped two autostart files in $HOME/.config/bunsen/, keeping the current autostart how it is in default BL carbon, and adding an autostart-wayland. I don't think there would be very much duplication of code between the two files, considering a lot of the entries are being disabled under wayland anyway. The system files bunsenlabs-session and bunsen-autostart can be as gnarly and complicated as we want because only devs will be expected to deal with them, but I think we should try to make user settings as easy to understand as possible (to encourage tweaking if nothing else).

A related question is - how realistic is it to provide a mechanism to switch compositors in a BL Wayland session the way we do for window managers in X sessions? The main part (IMO) of what makes BL running on eg awesome WM still BunsenLabs, is that the menu and keybinds stay the same - but considering a standalone menu like jgmenu, or xbindkeys, will not be available, then maybe we should just hard-wire the BL Wayland session to only one compositor, ie labwc? That would simplify the bunsenlabs session scripts a little.

Last edited by johnraff (2024-07-16 01:19:18)

Bearded_Blunder · 2024-07-16 01:42:35

@johnraff Even though I'm not involved in this, that sounds entirely sensible.

unklar · 2024-07-16 08:40:27

johnraff wrote:

I'm now thinking that users might be less confused if we shipped two autostart files in $HOME/.config/bunsen/, keeping the current autostart how it is in default BL carbon, and adding an autostart-wayland. I don't think there would be very much duplication of code between the two files, considering a lot of the entries are being disabled under wayland anyway. The system files bunsenlabs-session and bunsen-autostart can be as gnarly and complicated as we want because only devs will be expected to deal with them, but I think we should try to make user settings as easy to understand as possible (to encourage tweaking if nothing else).

^My thoughts:

labwc brings these files

For me as a user it was (almost always) very easy to see my changes immediately by clicking on 'reconfigure'.

If something went wrong, I could see the errors by clicking 'exit' (logout) again on tty1.
With the introduction of 'nwg-helo' by @mick01, I am no longer granted this (error) view of tty1.

Therefore, as a user, I think that the way should be labwc --> bl-configs and not bl-configs --> labwc.

Last edited by unklar (2024-07-16 08:46:21)

johnraff · 2024-07-17 05:43:37

unklar wrote:

johnraff wrote:
I'm now thinking that users might be less confused if we shipped two autostart files in $HOME/.config/bunsen/, keeping the current autostart how it is in default BL carbon, and adding an autostart-wayland.
...I think we should try to make user settings as easy to understand as possible (to encourage tweaking if nothing else).
^My thoughts:
labwc brings these files
https://i.imgur.com/ozAxujDt.png
For me as a user it was (almost always) very easy to see my changes immediately by clicking on 'reconfigure'.

OK I totally agree that if you're configuring how your WM ("compositor" on Wayland) should behave, then the obvious place to go is that WM's config files. And 'reconfigure' works with openbox in BL just as with labwc (I think). But my suggestion above is about the autostart ie what other apps and commands you want to run on startup. That needn't depend directly on which WM you're using - anyway in BL on X11 you can use ~/.config/bunsen/autostart regardless of if it's openbox, awesome or whatever. Putting autostart-wayland right next to it in the same directory seemed easier for users to find to me. Labwc allows --startup to choose a startup script.

If something went wrong, I could see the errors by clicking 'exit' (logout) again on tty1.
With the introduction of 'nwg-helo' by @mick01, I am no longer granted this (error) view of tty1.

Yes I spent an extra hour or so yesterday because of being unable to see those error messages. I found that if you choose the "shell" option on login and then run a command like "bunsenlabs-wayland-session" (if you're using BunsenLabs) to login, you can see the error messages again after running 'labwc --exit'.

I don't think it's going to be as simple to switch WM on Wayland as it is with BL on X, so we might well fix it to labwc for now.

Anyway this is all still in its early stages...

Last edited by johnraff (2024-07-17 06:05:46)

johnraff · 2024-07-25 09:43:57

@hhh's guide:

hhh wrote:

Here's how I setup labwc today on an 8 year old laptop.

Finally got round to running through this process on a VM, originally Bookworm CLI, basically the same as what D-I would install.

One thing I'm not sure about is that /etc/apt/apt.conf.d/00recommends sets apt recommends to off. Is that supposed to be the case? dpkg knows nothing about the file, nor could I find any reference in /var/lib/dpkg/info/* so it doesn't look as if a package put it there. To check if it was already in my VM before I started I'd have to go back to the snapshot, wiping out all this work.

hhh wrote:

Comment everything out except for the main source. Change that source (and the scr source) to...
sid main contrib non-free non-free-firmware
You can use trixie instead if you want.

I used Trixie, which might account for a couple of small differences.

sudo apt install labwc sfwbar foot bemenu swaybg

sudo apt install firefox ... xdg-usr-dirs

That's xdg-user-dirs of course, but you've got it again lower down.
There's no package 'firefox' in Trixie, only firefox-esr but that's no biggie.

labwc
You should have a blue background and a pointer cursor.

Mine was black. It turned to a rather nice blue after the next install-stuff-reboot

Ctrl+Enter will open foot, a terminal.

This did nothing. Keybinds are tricky on VMs anyway, but a look at ~/.config/labwc/rc.xml suggested it should be W+Enter
That did nothing either, but I could bind the terminal to W+t no problem.
I don't find foot very appealing (is it very lightweight?) so replaced it with lxterminal which is also Wayland compatible. That's the terminal in the above screenshot.

loupe is a wayland image viewer, that will bring in libadwaita/gtk4

Unfortunately, no loupe on Trixie. I left the image viewer for later.

You can adjust volume by right-clicking the volume icon in the panel. Right-click again to close the slider.

For some reason my volume icon is switched off, and the slider won't move. Maybe some library I need to install?

Anyway, generally, yes it works.

Last edited by johnraff (2024-07-26 03:00:08)

cog · 2024-07-26 17:26:00

I've been packaging hyprland and it's sleu of deps on my little project but I'm about to stop maintaining those packages, as debian proper is about to get it. I know @hhh likes hyprland too. Just a FYI in case yall haven't seen it yet.

https://qa.debian.org/developer.php?log … gistorm.in
https://salsa.debian.org/NyxTrail/hyprland

#41 2024-07-14 04:35:23

Re: carbon-wayland

#42 2024-07-14 08:21:37

Re: carbon-wayland

#43 2024-07-14 09:14:53

Re: carbon-wayland

#44 2024-07-14 09:24:42

Re: carbon-wayland

#45 2024-07-14 10:04:57

Re: carbon-wayland

#46 2024-07-14 11:52:49

Re: carbon-wayland

#47 2024-07-14 15:44:04

Re: carbon-wayland

#48 2024-07-14 18:14:55

Re: carbon-wayland

#49 2024-07-14 19:11:57

Re: carbon-wayland

#50 2024-07-14 19:45:49

Re: carbon-wayland

#51 2024-07-15 04:51:06

Re: carbon-wayland

#52 2024-07-15 04:52:52

Re: carbon-wayland

#53 2024-07-15 05:06:44

Re: carbon-wayland

#54 2024-07-15 09:57:18

Re: carbon-wayland

#55 2024-07-16 01:09:27

Re: carbon-wayland

#56 2024-07-16 01:42:35

Re: carbon-wayland

#57 2024-07-16 08:40:27

Re: carbon-wayland

#58 2024-07-17 05:43:37

Re: carbon-wayland

#59 2024-07-25 09:43:57

Re: carbon-wayland

#60 2024-07-26 17:26:00

Re: carbon-wayland

Board footer