Tabby: a tabbed-tiling wayland compositor

Trilby · 2022-02-12 15:45:52

bgc1954 wrote:

Wondering if you'd consider adding an option for the status bar to be on the bottom of the screen? I believe I asked for this in Alopex as it is just a personal preference.

Sure - that should be pretty easy. Though I have a very busy week or two coming up at the dayjob - so it might be a week or so, but I'll put this at the top of my todo list for tabby (because it's a lot easier than all the other todo items!)

bgc1954 wrote:

I looked in the config file and the title line was still Tabby 1.3

I fixed the sample config. That number doesn't come from tabby, it's just an example status line in the config. I'm surprised you've kept that as the left-status ... it's really meant as a placeholder for users to change.

bgc1954 wrote:

Trying out wayland compatible browsers and on my system, at least, epiphany is much zippier than firefox. Wonder why (retorical question)

Can one answer rhetorical questions? (and is that another one)

It's not at all surprising. Epiphany uses webkit2 as the rendering engine which is very fast if / when it works. Firefox uses their own gecko rendering engine which tends to handle rendering of a much wider range of websites, but is - as a result - a beast. If you want really fast, but limited capacity, use a gopher or gemini browser

Also, FWIW, I'm not sure "wayland-compatible browser" really means much. Pretty much all web browsers are wayland compatible - in fact I'm not sure I could think of a single example of a currently-mantained browser that isn't (or even any that could still compile and run). Most browsers depend on either gtk or qt, and both of these toolkits support wayland - the browser code itself generally would not specifically require wayland or x11. So browsers can't really be wayland-compatible, they are wayland-agnostic.

Now, "wayland compatible pdf viewer" definitely means something, as simple pdf viewers often don't use one of the big toolkits, so they actually need to be ported from x11 to wayland. I've been looking into updating freeglut's "wayland" code (which is really weston code) so that mupdf could run on other wayland compositors - but that code is a bit of a mess. So I started making my own wayland pdf-viewer from scratch.

Last edited by Trilby (2022-02-12 16:00:09)

bgc1954 · 2022-02-14 16:54:40

Trilby wrote:
Sure - that should be pretty easy. Though I have a very busy week or two coming up at the dayjob - so it might be a week or so, but I'll put this at the top of my todo list for tabby (because it's a lot easier than all the other todo items!)

Thanks I'll be patiently waiting.

And as far as browsers go, I tried several and as you mentioned, it was more functionality I expected and didn't get.

Docbroke · 2022-02-15 03:00:14

Trilby wrote:

Now, "wayland compatible pdf viewer" definitely means something, as simple pdf viewers often don't use one of the big toolkits, so they actually need to be ported from x11 to wayland. I've been looking into updating freeglut's "wayland" code (which is really weston code) so that mupdf could run on other wayland compositors - but that code is a bit of a mess. So I started making my own wayland pdf-viewer from scratch.

zathura(gtk3, with zathura-pdf-mupdf) and corepdf(qt5 https://gitlab.com/cubocore) works on wayland, if you haven't tried them.

Trilby · 2022-02-15 03:42:06

And those rely on the major toolkits which is far from simple and fits the point made about browsers and reliance on major toolkits.

Last edited by Trilby (2022-02-15 03:42:31)

Trilby · 2022-03-12 23:34:14

Tabby 2.0 has just been released!

There hasn't been much activity in the source repo for a bit as many of the changes that I wanted to make required a full rewrite almost from scratch - and I had to do a bit of testing to ensure all the different co-depdendent pieces worked before any of them could be released.

This update includes major changes behind the scenes. The end results for usage need not change much, but your configs will need to be updated. Notably the bar has been separated out into it's own binary and it has it's own config file (and can be positioned on the top or bottom). There is also no more built in wallpaper, but rather a tabby-bg binary to set a background. Both the bar and background setter require the nkk library (the project I had to make in order to make tabby what I wanted it to be).

There is also a revamped IPC system `tabby-cmd` so you can issue various commands at runtime to change any configuration setting - or do full live reconfigurations.

I've added to new tiling layouts as well: in addition to the original which is now called tabby-tiles, there is an rstack-60-40 which is a dwm-like rstack with the primary panel taking up 60% of the width and the stack on the right getting 40%, and bstack-50-50 which is a top primary panel of 50% height and a bottom stack taking up the other 50%.

Also, the main motivation for these changes was to implement layer-shell support. While bugs are likely to crop up, I'm successfully using various layer shell clients just fine (the bar and background setters are layer-shell clients). The tabby-menu interface has been removed as it is obsolete with layer-shell support meaning you can use any wayland launcher (bmenu, silo, etc). As an aside, I'm in the process of rewriting 'silo' so that it will no longer depend on qt5 (which was only needed as I didn't know how to write wayland clients at the time I created silo).

Much documentation is needed ... but so is much sleep as this has been a bit of a manic process of getting all these updates ready. The example configs included are not commented, but I hope much of their content may be self-explanatory at least for anyone who has used previous versions of tabby.

Last edited by Trilby (2022-03-12 23:38:08)

Docbroke · 2022-03-15 09:40:02

Nice, I will try it soon.

Docbroke · 2022-03-17 02:58:03

I am not able to change window, "win+left" key works but "win+right" doesn't, also "win+(num)" keys doesn't work. This happens with default config too.

Trilby · 2022-03-17 12:30:01

Odd, very little has changed with those actions*. First can you clarify what works and doesn't, I think there may be a typo in your first sentence. Also confirm that the windows focus really isn't changing and it's not just the bar display failing to update (these would be hard to distinguish if you had fullscreen terminals open with nothing different on them).

If focusing left or right fails, does moving the window left / right also fail (mod4+shift+left or mod4+shift+right with the default /example config). Also whether moving to a numbered position (mod4+shift+NUM) would be good to test.

EDIT: *I suppose I did add one tiny convenience function to determine offsets into the window list for the four focus/move-to/rel actions. This is a likely candidate for where the problem may be, but more information on when and how it goes wrong would be useful. Especially if you can test with many (half a dozen or so) windows open and see if any of these attempted focuses or moves fail at the intended action but actually do something else instead (e.g., if attempting to focus the 3rd window actually focuses the 5th, etc).

Last edited by Trilby (2022-03-17 12:36:54)

Docbroke · 2022-03-18 07:44:04

I tested bit more.

mod4 + (num) does nothing
mod4 + left, takes to first window, not the window left to the current window, as it shall do
mod4 + right does nothing
mod4 + shift + (num) works as expected
mod4 + shift + right/left works as expected
other keybindings using mod4, like mod4 + enter to open terminal works as expected.

Last edited by Docbroke (2022-03-18 07:44:48)

Trilby · 2022-03-18 12:30:41

Thanks - that actually rules out what seemed like the most likely candidate. Oddly I'm not able to replicate this on either of my machines running tabby.

Other tests that would be useful is 1) whether alt+tab cycles windows properly (the key binding for alt+tab calls the same function as mod4+right), and 2) whether mod4+right can be bound to some other action successfully (e.g., change the line to `bind mod4 Left exec alacritty` or some other program).

Also if this is on alpine a quick check of the following might be helpful (I'm not sure if this could matter, but it'd be good to rule out):

grep 'KEY_\(Left\|Right\|1\|2\) ' /usr/include/xkbcommon/xkbcommon-keysyms.h

Docbroke · 2022-03-18 14:10:11

I tried binding focusto function to "mod4 Return" to focus 2nd window, but it did nothing

bind mod4 Return focusto 2

while

bind mod4 Return exec ${TERMINAL:-alacritty}

works.

Then I tried binding mod4 left to open terminal, and it works.

So my conclusion is "focusto" and "focusrel" are not working somehow.

I guess this doesn't matter anymore but there is no xkbcommon directory in /usr/include, and I am running alpine.

Trilby · 2022-03-18 15:35:12

Thanks. If you're able could you rebuild with the code I just pushed which includes extra logging for those functions (and another related focus function). Then restart tabby capturing all output (e.g., `tabby > ~/tabby.log 2>&1`). Attempt a couple of the bindings that *should* focus different windows, then share the log, or at least the output of `grep FOCUS ~/tabby.log`.

This output will - among other things - check whether the syscall clock_gettime function is not doing what I expect. After a quick search, it seems some versions of musl may not properly support this function (e.g., support "time64"). This would definitely explain your results - however, it would not explain the change, as tabby has been using timestamps from clock_gettime for quite a while for window focusing.

Also please let me know if you are using multiple monitors / outputs by any change. A lot of code has been written to support multiple monitors, but it is completely untested and very fragile - there is a possibility that these symptoms *might* arise from a multi-monitor based issue.

Last edited by Trilby (2022-03-18 15:48:18)

Docbroke · 2022-03-19 02:59:39

I am using my laptop, no multimonitor. I will update once I compile and test the latest code, currently I am using tabby-2.0 from alpine/testing repo.

Trilby · 2022-03-19 12:23:53

Oh ... yeah, they seem to be grabbing the code from a bad commit. The 2.0 tag accidentally got applied to the last commit prior to the 2.0 code which is before the full rewrite. So it's really the same code that had been around for months for the last 1.x version.

Edit:

I've just fixed the tag in the source code repo, and I emailed the alpine packager - hopefully they'll get that updated to more recent code soon. However, I am finding and fixing bugs still at a fairly rapid pace. If you are not equipped to occasionally rebuild based on new commits, I'm not sure how pleasant the 2.0 line will be to use.

Edit 2:

I've exchanged a couple emails with the alpine packager. The current code builds and runs, but the packager is seeing other serious issues running tabby on alpine. There may be a bit of work to do to get tabby functioning properly on a musl system and / or the alpine wlroots build.

Last edited by Trilby (2022-03-19 19:55:50)

bgc1954 · 2022-03-19 17:45:52

Late to the party, as always. First, thanks for the bottom bar although I'm having a little trouble figuring my tabbybar.sh script problem. It seems that the output is there in black but the background is transparent so at first I thought it wasn't displaying at all. So you don't have to go back searching , I'll just post it again. It's likely the fg/bg have a new iteration in 2.0 but I'm not savvy enough to figure it out yet.

!/bin/sh

while :; do

printf '  %s Up:%s %s' \
        "$(date "+{fg=7}%b %d %l:%M%P {fg=4}")" \
        "$(uptime | sed -n 's/.*up \([^,]*\).*/\1/p')" \
        "$(awk '{printf "%d° ", $1 * .0018 + 32}' /sys/class/hwmon/hwmon*/temp1_input)"

sleep 30

done

Trilby · 2022-03-19 19:52:55

Yup, the new bar uses a different syntax which is not documented yet - but I *think* there were some examples in the repo. Colors are now set with {fg:XXXXXX} or {bg:XXXXXX} where the X's are hex color codes. These can be 6 or 8 hex digits, if the latter the first two digits are the opacity, then the remaining 6 are 2 each for red, green, and blue level. A revision of that script for a slightly off-grey background that I often use and foreground colors based on what the previous default colors 7 and 4 were would be as follows:

#!/bin/sh

while :; do

printf '{bg:202428}{fg:AAAAAA}  %s {fg:AAAAEE}Up:%s %s\n' \
        "$(date "+%b %d %l:%M%P")" \
        "$(uptime | sed -n 's/.*up \([^,]*\).*/\1/p')" \
        "$(awk '{printf "%d° ", $1 * .0018 + 32}' /sys/class/hwmon/hwmon*/temp1_input)"

sleep 30

done

bgc1954 · 2022-03-19 20:11:49

No wonder what I was trying didn't work. I was using the old fg= or bg= with a 6 digit color instead of fg: bg: and thanks again for the bottom bar. Us old guys tend to be resistant to change.

For some reason the kill command isn't working here. I had changed it to alt q since that was what I'm used to but even going back to alt F4 didn't help. And I added alt+shift q keybinding to quit as one isn't provided in the new config file.

Trilby · 2022-03-19 21:24:31

Ah ha! There's a bug I can replicate I can confirm that "kill" is not working for me either. Being able to replicate the problem I suspect I'll be able to fix it quickly. edit: I just pushed a fix for the failing "kill" command.

As for the 'quit', wayland compositors must implement *everything*: there is no ability to change to another tty or get any other control of the system if the compositor isn't responding. So there should be a built-in or hard-coded 'quit' key combo in case the user config fails to load or the user doesn't provide one otherwise one could get stuck with no option but a hard power-off. So there is a built in alt+Esc to quit, but you can add additional bindings for that as well.

Last edited by Trilby (2022-03-19 21:30:30)

bgc1954 · 2022-03-20 02:10:58

Can confirm that kill is now working here. I'm still keeping my keybinding for quit cause that is hard-coded in my brain. Now I know there is a hard-coded quit that I can also use if I remember it.

Docbroke · 2022-03-21 14:59:08

I tried to build using latest commit, but it is failing with

tabby-bg.c:4:10: fatal error: nkk.h: No such file or directory
    4 | #include <nkk.h>

I am having following as makedepends, wayland-dev wayland-protocols wlroots-dev pixman-dev cairo-dev pango-dev, in my APKCONFIG, am I missing something.

Trilby · 2022-03-21 15:27:34

Tabby 2.0 is quite different from previous versions - you'll need to update your APKBUILD following the changes to the PKGBUILD. That specific error is due to missing the nkk dependency:

Trilby wrote:

Both the bar and background setter require the nkk library (the project I had to make in order to make tabby what I wanted it to be).

Nkk is, aparently, already in alpine's testing repo, and the packager has updated tabby in the testing repo to be the proper 2.0 code (though still using a fixed snapshot).

Last edited by Trilby (2022-03-21 15:33:53)

bgc1954 · 2022-04-27 13:52:34

Just noticed something peculiar and it happened the other day as well but I just thought it might be a one of. Using foot as terminal and doing sudo pacman -Syu and there were quite a number of packages to upgrade. Everything seems to be going alright and then it seems to stop or freeze but it does complete the operation. Just can't see the final lines.

edit: and just fyi, I am using a bottom bar.

Last edited by bgc1954 (2022-04-27 14:12:06)

Trilby · 2022-04-27 14:15:07

The foot terminal freezes, or the compositor? Can you open other terminals / programs? Does the mouse cursor respond to movements?

bgc1954 · 2022-04-28 16:04:04

I don’t think anything freezes and I can open another terminal or program. I just can’t see the last several lines from the pacman output. I know it has finished the update because I can open another terminal and do sudo pacman -Syu and everything is done.
Edit: and yes the mouse works fine. Strange.

Last edited by bgc1954 (2022-04-28 16:05:20)

Trilby · 2022-04-28 16:19:21

Is the affected terminal able to scroll (mouse wheel scrolls by default in foot)? If so and you scroll down, are the lines there or not? If not, does the terminal ever properly redraw (e.g., if it's layout/screen placement is moved or it is obscurred then revealed)?

So far this isn't sounding much like a compositor issue but perhaps a foot issue.

Arch Linux

#126 2022-02-12 15:45:52

Re: Tabby: a tabbed-tiling wayland compositor

#127 2022-02-14 16:54:40

Re: Tabby: a tabbed-tiling wayland compositor

#128 2022-02-15 03:00:14

Re: Tabby: a tabbed-tiling wayland compositor

#129 2022-02-15 03:42:06

Re: Tabby: a tabbed-tiling wayland compositor

#130 2022-03-12 23:34:14

Re: Tabby: a tabbed-tiling wayland compositor

#131 2022-03-15 09:40:02

Re: Tabby: a tabbed-tiling wayland compositor

#132 2022-03-17 02:58:03

Re: Tabby: a tabbed-tiling wayland compositor

#133 2022-03-17 12:30:01

Re: Tabby: a tabbed-tiling wayland compositor

#134 2022-03-18 07:44:04

Re: Tabby: a tabbed-tiling wayland compositor

#135 2022-03-18 12:30:41

Re: Tabby: a tabbed-tiling wayland compositor

#136 2022-03-18 14:10:11

Re: Tabby: a tabbed-tiling wayland compositor

#137 2022-03-18 15:35:12

Re: Tabby: a tabbed-tiling wayland compositor

#138 2022-03-19 02:59:39

Re: Tabby: a tabbed-tiling wayland compositor

#139 2022-03-19 12:23:53

Re: Tabby: a tabbed-tiling wayland compositor

#140 2022-03-19 17:45:52

Re: Tabby: a tabbed-tiling wayland compositor

#141 2022-03-19 19:52:55

Re: Tabby: a tabbed-tiling wayland compositor

#142 2022-03-19 20:11:49

Re: Tabby: a tabbed-tiling wayland compositor

#143 2022-03-19 21:24:31

Re: Tabby: a tabbed-tiling wayland compositor

#144 2022-03-20 02:10:58

Re: Tabby: a tabbed-tiling wayland compositor

#145 2022-03-21 14:59:08

Re: Tabby: a tabbed-tiling wayland compositor

#146 2022-03-21 15:27:34

Re: Tabby: a tabbed-tiling wayland compositor

#147 2022-04-27 13:52:34

Re: Tabby: a tabbed-tiling wayland compositor

#148 2022-04-27 14:15:07

Re: Tabby: a tabbed-tiling wayland compositor

#149 2022-04-28 16:04:04

Re: Tabby: a tabbed-tiling wayland compositor

#150 2022-04-28 16:19:21

Re: Tabby: a tabbed-tiling wayland compositor

Board footer