Berry is a healthy, byte-sized window manager written in C for Unix systems

I've actually met the author of HerbstluftWM at the Konferenz der Informatikfachschaften (national student association meeting in computer science). Very approachable person. Coincidentally, the original author of Rack (Ruby) and the kind of inventor of tumblelogs was also there. Then again, where else would you meet people like that!

A really fun feature of herbstluftwm that I’ve not seen replicated is that monitors are virtual and can be reconfigured on the fly, so you can have e.g. a monitor that is bigger than your physical screen, or a little virtual monitor that you can pop in and out of your screen as a kind of notepad.

As someone who spent many years writing C, every time I go back to it, I wonder why people still write things in C.

(I'm exaggerating; of course I know why people still write things in C, but I would have a hard time justifying starting a new project in C these days.)

Puns on the name.

I had assumed it to mean “actively maintained”, but I think the other commenter is right, it’s just a joke about the name “Berry”.

It's fine for most cases, just don't get clever with the calls to the macro.

Unless some abstraction layers have been added while I wasn't looking, Wayland doesn't have a notion of window manager - only of compositors. These compositors incidentally also manage windows (although that's not the Wayland term I think), but I think the correspondence of compositor and window manager is still 1:1. Thus it is safe to assume that anything called a "window manager" is for X11.

I downloaded the latest release as a zip file here - https://github.com/JLErvin/berry/releases

FWIW, it’s 34KB and while it’s only the source, that seems pretty small. I haven’t gone through the build process to figure out the executable though.

Its also referring to the relatively small codebase (2300 lines of C). Something like i3, for instance (although that is certainly more feature complete) is around 25,000

this is my project, so I can speak to this :)

I wrote this as a sophomore in college after finishing the intro computer science sequence (which goes into basic data structures/algs topics like binary trees, recursion, etc). This was my first real project outside of school, and to be honest didn't require a ton of pre-requisite knowledge. Mainly it just required a familiarity with event-based architecture and linked lists (all the window stacking is represented as linked lists). The difficult part with writing a window manager, imo, is getting familiar with the necessary specs and APIs. This is built using XLib, which relies on the X11 protocol. I also had to learn about ICCCM and EWMH, since many program rely on them as well. It was good practice learning and implementing specs.

I also added features throughout college as I took more classes. The smart window placement feature, for example, is implemented using a dynamic programming algorithm I thought up after taking a formal algorithms class. You can read about it on my blog if you're curious: https://www.josherv.in/2019/06/27/dp/.

For me:

1. Learn C.

2. Read the source code to evilwm.

It makes a lot more sense if you have multiple screens, and want to effectively have certain windows open in particular groups.

It's useful when you have a large screen with multiple windows that are tiled and dedicated to a single work function. For example a terminal on one side and a browser on the other that's dedicated to specific work. You may then have another virtual desktop dedicated to messaging, video editing, whatever...

In well designed WMs like i3 each desktop is typically bound to a key for instant switching, unlike the full screen atrocity of macOS where there is an unremovable delay when switching.

I really like to use virtual desktops to isolate windows for a particular task: one for programming, one for social media, one for music notation, one for writing. Sometimes I have one of my kids making a Minecraft texture pack or something like that on my computer, and I'll stick that on a desktop of its own. It may be that I'm easily distracted, but I really love that feature.

I get the motivation behind it, but I have to agree with you. I tried virtual desktops several times back when I used Linux desktops and the habit never stuck. What's more important to me is being able to easily switch between apps. Maybe there was a time where virtual desktops made more sense, but so many apps use tabs now that VDs seem pointless.

The way that I use workspaces might be helpful in explaining their usefulness. I dedicated one workspace to each application and run that application maximized in the workspace. So: email, slack, calendar, browser, vscode, terminal, each in their own workspace. I will actively reorder the workspaces depending on where my focus is at the moment. For example, when programming I make the terminal, browser, and editor workspaces adjacent. However, when dealing with management situations, I’ll bring slack, calendar, email, and the browser together.

Full screen applications, adjacent workspaces, and a simple left or right swipe to switch workspace allows me to find relevant apps using our fast spatial reasoning wetware and avoids the problem of having to context switch into a hunt for the right window mode.

I've been using a 3x3 virtual desktop setup for 20 years on my Linux system. Upper left for email, lower left for a real time view on system logs (useful for debugging), lower right for long running programs in on the CLI, the middle row for work; the rest on an ad-hoc basis. By now it's muscle memory to switch screens (it doesn't hurt that it's easy to switch spaces via the keyboard). It's what you get used to.

Here's how I use workspaces (I am on KDE by the way):

I have 1 workspace dedicated to programming. It has all the terminals, the code editor, and everything else.

The 2nd workspace is for browsing. Incidentally this also includes web app preview (if I am working on a web app).

I have mapped the Ctrl + ` for easy switching between the 2. So I make a change in the editor, press a key and see the preview. Nice and easy. My code editor is never minimized or in the background so all good.

I have to do all this when I am working on a small laptop screen where switching between windows is too annoying. I am aware that there are other ways to accomplish somewhat the same functionality but workspaces work for me.

I really don't get how you can not appreciate the potential utility of virtual desktops.

In my window manager I took virtual desktops a step further and added contexts, each of which has its own set of virtual desktops. Windows, virtual desktops, and contexts all get kept in most-recently used (MRU) order.

So when I'm working within a virtual desktop, usually it's kept to a very localized specific topic involving multiple windows, Mod+Tab switches through those windows with the hot ones always staying at the top of the MRU-ordered list. Sometimes I end up with a slightly tangential set of windows so I spin up a virtual desktop within that context and keep those windows there, and the virtual desktop switching within the context can be achieved with Mod+Space, also in MRU-order.

But I also usually have multiple contexts active, each with one or more virtual desktops. Those contexts are for entirely disparate topics. Usually one context is communications, I'll have email, IRC, browser, etc. in one or more virtual desktops within that context. Another context will be one development project, with one or more virtual desktops full of terminals, kcachegrind, testing, etc. Usually I have two or three active development contexts repeating that mess. I can switch between the contexts using Mod+Grave, also in MRU-order.

The major value this all brings to me is it organizes my virtual spaces in the same way I organize my thinking and logically switch contexts. Due to everything always being kept in MRU-order, and having explicit keyboard controls for switching to the next recently used {window,virtual-desktop,context}, whenever I switch between these things, what's put immediately in front of me is the last item I was focused on within that context/virtual-desktop. And when I'm cycling through just windows or virtual-desktops, I don't get distracted by ever seeing the stuff put elsewhere.

But I do somewhat agree in the sense that many window managers offering virtual desktops utterly fail to deliver the obvious potential workflow advantages. It's totally ubiquitous for Mod+Tab to cycle window focus in MRU-order, but for some unclear reason nobody seems to do the same for virtual desktops, and I've never seen any before that grouped virtual desktops into another MRU-ordered and iterable/focusable thing which I've termed contexts.

Something I've come to really appreciate with how my window manager works is I'll sometimes spend over a month just living within the three MRU contexts getting shit done. Then I'll finally come up for air and hit Mod-Grave that fourth time without releasing Mod and rediscover that project I was working on last month still sitting there waiting for me to resume working on it, with the last focused window still sitting on top and focused ready to go. The entire month I spent in the top three MRU contexts I didn't have that backburner context's windows/virtual-desktops entering my cognition one iota, despite it being there all running and waiting happily.

Keeping a certain layout in tiling wms is the main thing I'd say. And also it's just a faster way of organizing windows compared to alt tabbing, it just takes a bit of getting used to since most people grow up with single workspace OSs.

How do you find the relevant window? Alt-tabbing or searching by name sounds like more work than “I know which workspace it’s in, so I just go to it (1 keystroke for me) and then find the window” (much less alt-tabbing when there are only a couple of windows in a workspace vs. dozens in a no-workspace arrangement)

With most tiling WMs, multiple workspaces are necessary since there's often no way to minimize windows. So without virtual desktops you'd quickly run out of space.

If you're using a standard overlapping window system, virtual desktops are more of an optional workflow preference than an absolute necessity.

I use virtual desktops/workspaces for context switching. Because I don't like to micromanage opening and closing a multitude of windows each time I switch tasks, I just... leave everything open until I'm done with it. My computer is powerful enough that it doesn't usually struggle with that. Even if it'll be hours until I'll use a certain context, I just leave everything up on that virtual desktop/workspace until I need it next. So, I have a workspace for each of:

- Leisure (browsing Hacker News, reading the news, listening to music, chatting with friends, etc.)

- Play (usually an idle game I enjoy)

- Software development (code editor, terminal, browsing code documentation, debugging tools)

- Virtual office work (writing documents, checking email, managing my calendar, managing projects)

- Learning (these days that means formal schoolwork as I've gone back to school to chase a graduate degree)

I love workspaces. My top-left one is my "home" workspace where I keep a browser window with mail, calendar, chat, etc., as well as any other random browser windows/tabs with "general" personal stuff.

Then the other three workspaces (I just have four arranged in a 2x2 grid) are for a particular topic or project. One of them is devoted to some ESP32 rust hacking I've been playing with. Another has a window open for a consulting gig I was working on recently (though that project has concluded, so I can probably clean that one up). And the fourth one is for a different coding project I'm working on.

I find this much easier organizationally than having them all in the same workspace, and having to dig through the various windows to get things where I want it when I switch context.

Perhaps I'm a little odd, though: this is a laptop with a 13" screen, and I do all my work and play on it, without an external monitor. So keeping unrelated things separate is useful for me to keep clutter down.

I've always been more of a fan of the "grouping" motif that WMs like cwm have.

If you are switching between 3 applications placing each in turn maximized on your display indeed I would see no benefit from virtual desktops in this instance however the benefit is proportional to the average work needed to switch between states * the frequency of such a switch.

With the complexity of keeping track of which together rising with the number of windows.

If S1 consists of a single window maximized and S2 a different window maximized the cost of switching workspaces is just as high as clicking on say a taskbar or hitting alt tab.

Let us consider a very simple stacking window manager with 2 workspaces and a task bar.

Let us first disregard the second workspace.

Suppose one has taken the trouble to size 7 windows to fit on 3 monitors. First you drag one window to the left-hand side of the leftmost monitor. Then we drag one side then the other. Repeat 7 times over for each window to be placed on each monitor.

Now suppose we only have 3 applications we ought to be able to see together separate from the other 7. This is easier as they can be dragged to a display and maximized.

Now consider the hassle to recreate the state repeatedly. You don't need to resize it but you have to manually select first 7 then 3 then 7 then 3 applications to bring them to the forefront.

Now what if you want to show 3 windows from the rightmost monitor then put them back. Now we are stuck resizing each in turn.

Now let us fully utilize the workspaces and separate the states on different desktops. Suddenly the switch between S1 and S2 is a click. The operation of moving the applications displayed on one end of S1 and showing them on the other end of S2 is of course just as much of a hassle as it ever was because workspaces encompass all monitors at once.

Now let us lastly switch to using per monitor workspaces. Now the last operation is as trivial as the first at the expense of making the process of changing all 3 at once more expensive. To decide which makes sense we would consider how frequently we want to do each operation.

If we find that we frequently need to switch multiple monitors at once we can trivially add that back but not the reverse.

I'm self employed, so keeping different client stuff separate from my general business development stuff separate from coffee break stuff is a no brainer.

Back when my screen was 800x600 I used to have hotkeys that would let me switch between virtual desktops in an instant. It was super useful to have the reference page up on one screen and the code down on another. There wasn't enough space for both at once. I would also have other code windows open on different screens. People sometimes commented that it was impossible to watch me work because the screen kept flashing to different things.

I've not bothered with that setup in many years. I have enough pixels that it is no longer necessary or even helpful.

> having to navigate to other workspaces/desktop just wastes time when you can just find the relevant window

How are you navigating to another workspace, that it could possibly be slower than finding the right window if they're all piled one on top of another?

Since forever (early 90s), I've use 9 workspaces in a 3x3 grid. Because that conveniently maps to the numeric keypad on the keyboard (which I've never used for number entry). So it's one keystroke to jump to any of the nine workspaces, nothing could be faster.

Each workspace is dedicated to a specific project or workflow, so when I switch working from something to something else it's just one keystroke away to have all those windows in their correct locations ready to go.

I think it could be because some people love hierarchies, and others hate them; most are somewhere in between, and I would certainly expect those who are more hierarchically-oriented to prefer working with the virtual desktops than those who want a flat "everything at once" model. You can see this in how different projects' source code is organised too --- some are full of deeply-nested directories and very "branchy", while others have lots of files in one directory, or few files with lots of code in them. I'm personally on the "flat" side; I prefer there being fewer levels of hierarchy, with more on each level. Even tabbed browsing, which seems quite popular, is something I make little use of --- I'd rather open new windows so I can see them all in the taskbar among everything, and switching is thus a single action rather than two.

is this rhetorical?

Edit: Benefit of the doubt, it's a command line json processor written in 2013 mostly in C.