Tabby: a tabbed-tiling wayland compositor

Trilby · 2021-09-05 18:58:48

Tabby started life as a X11 window manager and remained that way up through version 1.0. It's now on a journey of recreation in wayland. Version 1.1 was never a tagged release as it was experimental and full of shortcuts that would not have worked on more diverse systems from my own development machine. Version 1.2 should be viable for more general use, though there will still be some growing pains as Tabby is in active development. Feel free to see the "Roadmap" file to see what goals are currently on my radar.

UPDATE: Many posts below are relevant only for the 1.x line. Sustantial changes were made for 2.x versions for which the discussion starts here. Original post continues:

Tabby provides it's own bar with optional left and right status regions and window title bars in the middle. All three regions are highly configurable both through scripts / programs you can run to provide input to each status region and through format strings that you can adjust to completely change the color and layout of any of the text in the statuses or title regions. This may be best understood by seeing the examples and comments in the default config file.

There are a range of highly configurable tiling modes available, though for the next week or so I'd advise against any attempts at configuring tiling modes as the code behind it is getting a major overhaul and is currently very fragile (i.e., it works great if you use the tiling modes as listed in the default config file, but it can come crashing down if you attempt to make changes and get one number out of place).
edit: tiling code is now in good shape, but tabby now requires a data file to define tiling modes. The format of this datafile is yet-to-be-documented, so for now it's not likely viable for users to write there own. Documentation of the *.algo file format will be ready within the week.

You can learn more about Tabby here:

https://code.jessemcclure.org/tabby

Or try it out by getting it from the AUR here:

https://aur.archlinux.org/packages/tabby-fossil/

Last edited by Trilby (2022-10-04 21:06:29)

Docbroke · 2021-09-06 03:01:07

1. Is there a xwayland support (i guess it is not planned but still asking to confirm) ?
2. How to configure input ( tap to click etc., ) and outputs ( background, multimoniotr etc. ) ?

EDIT: I must add tabby feels snappy.

Last edited by Docbroke (2021-09-06 03:13:43)

Trilby · 2021-09-06 04:53:54

1. Nope, no xwayland, and it's not planned. I plan to expand support for many features, but see Xwayland as an anti-feature: I prefer to rip the bandaid off ... and I figure if wayland lacks an important tool, we should get onto creating it, not running Xorg in wayland. Xwayland support really adds a boatload of code as all sorts of functions end up being duplicated with one version for wayland clients and another for X11 clients. You can, however, still run an X session under Tabby (just as you can run any compositor from within another compositor). You'd just lack the ability to copy/paste between the X11 clients in the nested X session and wayland clients outside of it. XWayland is a crapton of code to really just enable that little convenience.

2. Configuring input and output will come in stages and there are some limited notes on this in the "Roadmap" file in the source repo.

2A: Options to set the background are the criteria for a 1.4 tagged release - and despite the current tag just being 1.2, I expect background setting will actually come fairly soon (within a week or two) as long as setting it through tabby is acceptable (the experimental wayland interface that would allow other programs to set a wallpaper may or may not ever be fully implemented, that's TBD).

2B: Multi-monitor support is also a targetted feature, though that will take a *little* longer. Being able to use multiple monitors with their default / primary resolutions should come first, then more settings will be added for adjusting resolution / settings.

2C: Input configuration is also a goal, but will likely be after all of the above. Much general input configuration for keyboard layout / mapping should be able to be done through xkbcommon / libinput independent of the compositor - and for any setting for which that is the case, I'd not plan to add options to tabby for. I *think* tap-to-click can be set via libinput (the actual `libinput` command) directly. If so, you can add an 'exec' line to your config for the relevant libinput command to be run at startup.

Last edited by Trilby (2021-09-06 04:56:43)

Docbroke · 2021-09-06 06:01:54

Thanks.

Regarding libinput, afaik, there are no configuration methods/commands for wayland, excluding config through desktop environment.

One more question, when I try to run mako (notification daemon), it tells me

compositor doesn't support zwlr_layer_shell_v1

Is there any known supported notification daemon.

I had trouble gettting my pdfviewer run ( mupdf/llpp doesn't seem to work with wayland), however qpdfview works.

progandy · 2021-09-06 06:25:37

Docbroke wrote:

Regarding libinput, afaik, there are no configuration methods/commands for wayland, excluding config through desktop environment.

You can use environment variables to set the default keyboard layout, other options need compositor support:
XKB_DEFAULT_RULES, XKB_DEFAULT_MODEL, XKB_DEFAULT_LAYOUT, XKB_DEFAULT_VARIANT, XKB_DEFAULT_OPTIONS

Docbroke · 2021-09-06 06:42:07

I am actually looking to set "tap-to-click" for my touchpad

Docbroke · 2021-09-06 09:54:24

When running tabby, $DISPLAY is empty, this creates some difficulites in scrtips that needs such information.

Trilby · 2021-09-06 13:15:53

Layer Shell

The LayerShell protocol is an odd duck at the moment - quite a few compositors provide that interface, and quite a few clients require it (including my launcher menu Silo), but it's apparently not even to the level of being considered experimental or unstable yet: the protocol definition is not included in the wayland-protocols package (it is part of wlr-unstable).

I'd very much like Silo to work under Tabby, so I have my own strong motivation to support the layer shell protocol and when I started converting Tabby into being a wayland compositor LayerShell support was in the defintely-will-do category. But as I've looked into it, I'm really not pleased with what is in the not-yet-even-experimental protocol. It's kind of a mess on the compositor end. The protocol proposal itself is confusing ... a specific critique is that like many wayland protocols, they would be very well served by applying the terminology of rfc2119 to their protocol definitions - but the LayerShell xml file is particularly bad in this regard*. This led to LayerShell support being moved from the definitely-will-do-category, to maybe, to probably-not-in-it's-current-state.

I am, however, working on simple mechanisms that can provide users alternatives for some of the more common needs of LayerShell.

That said, I'll promote LayerShell support from "probably not" to "maybe" again if it makes it into the actual wayland-protocols. And I'll promote it from "maybe" to "definitely" if it becomes categorized as "stable" under the wayland protocols. While it's certainly not there yet, I do have a goal of tabby supporting ever relevant stable wayland protocol (relevant meaning for desktop use, so not the in-vehicle shell).

Given it's popularity and already broad usage I think it's inevitable that the LayerShell protocol will make it into the stable protocols. I'm just hoping it undergoes some major revision before that happens. My biggest hope for revision is that it is split into two protocols, one for the actual layers (which would really help launcher menus and OSD notifications) and another for all the exclusive zone stuff. Despite both being required by a few types of clients, they really are two different beasts. If that split were to happen, I'd get tabby to support the layer protocol ASAP and put the exclusive-zone protocol in the 'probably not ever' category.

I'm still thinking about trying to provide partial LayerShell support for the above effect, but this might be problematic as it would effectively falsly advertise to clients that the exclusive-zone content was supported when it isn't.

Also note I'm not pushing off this issue. If you have a look at the curren Roadmap, now that I've reached the goals I felt were required for releasing the 1.2 wayland-functional version of tabby, addressing the layer-shell issue is my very top priority. I just can't commit yet to how it will be addressed and I'm tinkering with a few options.

The above-mentioned background setting, despite being father down in the Roadmap may actually come first. I've been frequently surprised in switching from X11 wm writing to wayland compositor writing how some of the things I expect to be hard are very easy while things I expected to be easy are a total PITA. So goals / priorities in the Roadmap have been swapped around a few times.

DISPLAY

DISPLAY is empty because there is no X11 display running. WAYLAND_DISPLAY is set. Any client that requires a DISPLAY variable is an X11-only client.

Tap To Click

While I don't have a touch screen device to directly confirm, as I've looked into it, tap-to-click appears to be one of the options that is indeed configured via the libinput client (e.g., /usr/bin/libinput which functions a bit like xinput with commands to list-devices and properties including tap-to-click as well as enable / disable them). If this is not the case, then yes, tabby will eventually provide a mechanism to enable it, but it if is the case,then I'm not going to reinvent the wheel. Most DE settings window options are really just toggles for things you could set manually via a CLI interface anyways.

So another way of saying this should actually be encouraging for anyone who needs tap-to-click: if it's not already available via libinput's cli interface, I will commit to adding options to Tabby to support it when I get to the input config part of the goal list. But I'm pretty darned sure it's already available via the cli interface - either way I've added it as an explicit goal in the Roadmap so I will remember to revisit the topic when I work on input configs.

*note: my concerns with the layershell protocol may boil down to it being less of a protocol definition and more of an implementation description. I do not want to sound like a critique of the sway/wlr team as they are absolutely awesome, and tabby wouldn't exist without wlroots or without the tinywl example compositor they've provided. I also give them a lot of credit for being a major driving force behind turning wayland from a interesting idea that could never really work to a viable protocol for a desktop system. But in the case of the layershell protocol, I am critical - not at all of it's goals - but of the fact that it pretty much says "hey, here's what clients can do under sway" but says very little about the compositor's role or responsibility; so every other compositor essentially just copies sway's code for it. That's not a protocol definition; that's a cargo-cult implementation.

Last edited by Trilby (2021-09-06 14:35:49)

progandy · 2021-09-06 15:43:32

(e.g., /usr/bin/libinput which functions a bit like xinput with commands to list-devices and properties including tap-to-click as well as enable / disable them)

the libinput cli has no settings, it is only a tool to list and debug input devices and events. All libinput settings have to be performed by the program owning the device fd, i.e. the wayland compositor with library calls. An generic xinput like tool would require a new wayland protocol or another IPC mechanism like dbus. sway has chosen to extend the i3 ipc protocol already implemented.

Docbroke · 2021-09-06 15:53:44

WAYLAND_DISPLAY is good enough for scripting. I was just not aware of it. Thanks.
As progandy already posted above, tabby will probably need to provide for libinput config support.
I will try to find other notification daemon that may work without layer shell protocol.

Trilby · 2021-09-06 17:45:37

Thanks prograndy - then I will add these options when I get to that point.

There aren't any notification daemons that will work (if by working you mean popping up a small floating graphical window) without a protocol to do so agreed upon by the client and the compositor. I'm tinkering with ways in which tabby could provide notification-type information - this would work well if 1) you like how I implement it, and 2) you can use it in any script or command you'd want to be notified about. But it will not make existing graphical notification tools functional.

This is why the layershell protocol was proposed - it fills a very important roll in the wayland ecosystem. This is also why so many projects have adopted it despite it's issues and non-standard status. It's the only game in town at the moment for anything remotely like override-redirect windows under X11. I couldn't even have implemented the bar that tabby displays if it were a separate process from the compositor itself. Tabby's bar is not actually a "window" - there is no xdg_surface and not even a wayland wl_surface for it. It's just a graphical texture (raw image data) that is written to the display output in tabby's rendering function.

At the moment the only "floating" surfaces that tabby supports are ones that list another toplevel xdg-surface as their parent. And these windows/surfaces are only visible while their parent is visible (this latter point is a design choice I made for tabby not a restriction of the protocol). This allows for dialogs/popups within a ~~running client~~ mapped client's surface, but not otherwise.

[side note, I'm waiting for someone to write a "Wayland != X11" article to parallel the "Linux != Windows" article ... it really is so different that the language many of us have grown acustomed to with X-based graphical systems really gets in the way of discussing Wayland.]

Last edited by Trilby (2021-09-06 17:50:27)

progandy · 2021-09-06 18:22:55

For simple notifications you could probably let a modified statnot write to the statusbar: https://github.com/halhen/statnot/blob/master/statnot
Edit: https://github.com/jpentland/NotiD or https://github.com/Sweets/tiramisu

Edit: taiwins has its own protocol for desktop panels and widgets, but it doesn't lend itself for more general adoption: https://github.com/taiwins/taiwins-prot … -shell.xml

Last edited by progandy (2021-09-06 18:32:57)

Trilby · 2021-09-06 18:28:06

Sure - anything (that the user configures) can write to the status bar. So there's no issue getting notified about things. I get email notifications and warnings about low battery power. The issue is whether off-the-shell graphical popup notifications can work. And without at least partial LayerShell support, they cant. Whether they'd error out completely or just fallback to presenting a "normal" surface that tabby would tile like any other surface is up to how the client deals with layershell not being available.

EDIT: ah, I see, those tools link up the "desktop notification specification" to the stdout. Yes, that'd be handy to connect existing notification-generating clients to the statusbar.

The option I'm working on right now will make the statusbar input type of notification *much* easier. Essentially the "keybar" module I'm working on will be able to turn the title bar area into a transient text-input / display space. My use case for this would be to have it be a launcher menu like dmenu/bemenu/silo/etc. But it would be well equipped to also display text notifications.

Come to think of it, I could build in a little OSD display widget in a similar way I did the bar, and I could hook this into the normal desktop notification events. So Tabby would play the role of a notification daemon - but it still wouldn't allow *other* notification daemons to display *their own* popups on screen. Na, scratch that idea. That could be done, but I don't like it. Integrating better into the existing status bars or the potentially-upcoming "keybar" system is worth supporting, but Tabby will not be creating any sort of "popup" displays.

Last edited by Trilby (2021-09-06 18:44:55)

Docbroke · 2021-09-09 02:13:08

I have noticed two things,

1. Sometimes I am not able to input text in weaver while using tabby ( this happens only with tabby ). It gets solved when I do reboot. logout-login doesn't solve this.
2. While trying seth's sqriptor, I noticed that I am not able to click buttons in dialog ( view -> settings -> font) when used with tabby. It works fine with sway without xwayland.
EDIT: I just found out that same problem with dialog occurs when using libreoffice too.

Trilby · 2021-09-09 02:47:29

I encountered the second issue you mentioned earlier today. It seems to happen with toplevel xdg surfaces that list another as a parent surface. I've been investigating it over the past couple hours. I'm stumped by it at the moment, but I am able to consistently replicate it so I should be able to track it down soon enough. I am able to avoid this issue by reverting the code that prevents these dialogs from being tiled: when tiled, they are clickable. The odd thing is there is nothing at all in this code that should affect whether they receive clicks ... none - it's just different sizing. So I'm a bit confused at the moment.

For the first issue, are there certain websites it occurs on? I've not encountered this (yet).

EDIT: D'Oh, I think I actually know why the second issue (dialogs not being clickable) is happening ... I should be able to get this sorted soon.

Last edited by Trilby (2021-09-09 03:04:28)

Docbroke · 2021-09-09 02:54:17

First issue occurs on every website, when it occurs. I am not sure yet, but I think it occurs when I am running two WMs, either simultaneously or one after another, so probably it is related to server input being attached to one WM. I will investigate further on that line and update here.

Trilby · 2021-09-09 05:13:19

The dialog mouse-focus issue should be fixed. Please let me know if an upgrade doesn't resolve all symptoms of that issue.

For the other one I'd like to try to replicate it. Do you mean you are running two compositors? Which other one is running and which is the parent vs child (e.g., which one is run from the tty)? Or are you running them on different ttys?

Last edited by Trilby (2021-09-09 05:13:50)

Docbroke · 2021-09-09 09:29:01

Yes dialog issue is fixed.

I did a small test just now, like this
--> started tabby in tty1,
--> started weaver, no input issue
--> started hikari on tty2,
--> started weaver with hikari, but window opened on tty1
--> now, on tty1 I am not able to input any text, and I noticed issues with keybindings too.
--> restarted weaverserver on tty1, issue solved, even with wayland compositor running on both tty.
--> run "weaver duckduckgo.com" on a terminal in tty2, window opened on tty1, but still no input issues.

Trilby · 2021-09-09 12:21:15

Ah, thanks. Most of those symptoms are due to how weaver works. When you first start the weaver server (`weaver -d` or calling WeaverServer directly) it starts the only graphical process. Any further invocation of weaver by the same user connects to the running instance. This is why the window opens on tty1 when you try to run weaver from hikari. You *can* run multiple weaver server instances on different tty's, but you'd need to explicitly start it on a different port. At the moment that can only be done by modifying the config file ... but yours is a use case I hadn't considered for weaver and would be a good reason to add a command line option to override the port setting (so a second instance of the server could be launched).

The resulting lack of input is still odd though, as once a weaver server is running, commands can be sent over the socket from *anywhere* and they are treated the same - you should be able to open weaver windows on your primary computer from another computer shelled into it.

Would you be able to do a similar test with another compositor: e.g., run sway on tty1 and hikari on tty2 to see if you get similar results. I'll start testing with sway and tabby running to see if I can replicate the symptoms (so far I'm not able to replicate any input issues w/ sway and tabby running and opening weaver windows on the other compositor). My first goal would be to identify if this is more of a tabby or weaver issue.

Last edited by Trilby (2021-09-09 14:32:18)

Docbroke · 2021-09-09 16:54:16

I tried for half an hour, running tabby, sway, hikari and cwm on four different tty and still not able to reproduce problem with input.
I will report again if I find a consistent way of reproducing this issue. I am not sure if updating tabby has changed something. I had not faced this issue before starting to use tabby.

Docbroke · 2021-09-11 01:24:37

Today I had same issue with firefox, input stopped working. So this appears to be a tabby issue, when occasionally something hangs, and input stops working.
I am also seeing occasional hangs while watching videos ( both with mpv and browser ), when audio keeps playing but screen freezes. If I stop the player tabby becomes normal in few seconds.

Trilby · 2021-09-11 01:34:07

If you could get logs from any of those instances, that might help - to do so you could redirect stdout and stderr to a log file when you start tabby.

As a long shot - are you running any processes for status bar input?

Docbroke · 2021-09-11 01:45:07

No I am doing nothing with status bar. I will try to get logs today.

Docbroke · 2021-09-11 03:57:09

https://termbin.com/4ukge

Here using weaver I opened hdfc bank site, and I was not able to input my username, next I opened this very page and was not able post anything. So I copied log and restarted weaver server to post here.

There is nothing running on another tty. Here is my start-up file for tabby.

#!/bin/sh
##
#conky -d -c .config/conky/conky-desktop_hikari &
##
export QT_QPA_PLATFORM=wayland-egl
export QT_WAYLAND_FORCE_DPI=physical
export SAL_USE_VCLPLUGIN=gtk3
export SDL_VIDEODRIVER=wayland
export XDG_CURRENT_DESKTOP=unity
export MOZ_ENABLE_WAYLAND=1
#mako &
export QT_SCALE_FACTOR=1.5 && weaver -d &
telegram-desktop &
aria2 &
pulsemixer --set-volume-all 50:50
export QT_SCALE_FACTOR=1
## SYSTRAY
#stalonetray --tint-color black --tint-level 130 --dockapp-mode none --geometry 150x28+1760+1054 --grow-gravity NE --icon-size 24 --parent-bg true --sticky true --transparent true &
ibus-daemon -drx &
doas tor &
#sleep 2
#nm-applet &
#sleep 2
#blueman-applet &
#sleep 2
#pasystray &
##
#trayer --SetDockType true --heighttype pixel --height 24 --align right --transparent true --alpha 150 --tint 0x000000 --widthtype pixel --width 150 --SetPartialStrut true &
#export ENV=$HOME/.env.sh &
#scim -d &
#feh --bg-scale /home/sharad/Pictures/SAM_3193_Pangong2.JPG &
#connman-ui-gtk &
#autocutsel -fork &
#autocutsel -selection PRIMARY -fork &

EDIT: I just had tabby hang while playing video on youtube(weaver). I was watchin a video, and suddenly screen froze, with audio still playing. This may be RAM full issue, as after I paused, tabby become responsive in 4-5 seconds. Anyway here is the log. https://termbin.com/io2a

Last edited by Docbroke (2021-09-11 08:45:45)

Trilby · 2021-09-11 12:32:09

There's nothing out of the ordinary in those logs - though I gather you don't have any tiling modes in Tabby, if you want other tiling modes please see the change to the "tiling" setting in the new default config. The five or six tiling lines in your config should be replaced by a single line that includes a tiling algorithm file. (EDIT: nevermind - those lines can be removed as they are now ignored, but if no tiling algorithm file is explicitly provided, the default is used anyways.)

After the next hang, can you check the journal and dmesg for recent activity?

When there is a freeze like this, can the mouse pointer still be moved around?

Would you mind temporarily adding a status input that changes frequently and in the next freeze / hang check whether the status is still updating, eg.:

status right    while :; do date '+%H:%M:%S '; sleep 1; done

You also mentioned something about potentially high RAM use. Is this out of the ordinary for you, or do you run low on RAM in other compositors / environments? Tabby should use *very* little RAM. Weaver on the other hand is a beast with RAM: qt5-webengine is a memory hog in the best of conditions, and on (most?) intel graphics systems is has a nasty memory leak which is excacerbated under wayland - but you've said previously that you're not experiencing that.

Last edited by Trilby (2021-09-11 13:17:11)

Arch Linux

#1 2021-09-05 18:58:48