StumpWM is so awesome! And I'm really happy to see this release!!!
I love StumpWM because it does not force a workflow on me! I have configured it to work the way I want it to! And as far as I know I cannot have this workflow in any other tiling window manager!
If I want to open firefox I press `F9` and then `f`.
Let's start a terminal window... `F9` `t`
Let's open emacs... `F9` `e`
Now I want to go back to firefox... `F9` `f`
Press `F8` if you want to switch between last 2 windows (emacs & firefox)...
F8 ... and I'm back at my emacs window...
Neat ha?
Oh, and I forgot to mention that everything is in full screen! 29" of real estate for every app! No tiling or stacking windows.
There are no numbers, tags or anything to remember. Too bad this will never work on a mac... everything starts with an i... just kidding! :)
Edit: Actually, most all of this could be implemented in X11 keybindings outside of your window manager. Just the full screen part that the WM is needed for. And that can be implemented in any WM and probably most DE
Yes, you can. StumpWM uses a keybinding system that is very much inspired by Emacs. You can bind any keypress to any action, or even another keymap in order to create multi-key commands.
You can easily define new commands by using the "defcommand" macro. Here's an example from my config file that creates a floating group (untiled windows) and starts Android Studio in it (or switches to it if it isn't already running):
(defcommand android-studio () ()
"Start Android Studio in its own group"
(select-group-or-create ("Android Studio" :float t)
(run-shell-command "~/src/android-studio/bin/studio.sh" nil)))
StumpWM isn't just about being a great tiling window manager. It's all about the configurability. Just like Emacs without any configuration is a decent editor, but can easily be challenged by other editors, it's the ability to make it behave just the way you want to that really makes it shine.
As an example, I have built a Dbus integration module for StumpWM. It's a work in progress, but useful for daily work. It's nice to be able to exactly control which notifications are displayed and how long they stay on the screen (I'm looking at you, IDEA compilation notifications).
The kind of flexibility offered by StumpWM is hard to beat, and combined with the ability to connect SLIME to it in order to have a REPL running in Emacs directly working with the running window manager makes it, in my opinion, better than any alternative.
With all due respect: I don't have time. I just asked because this was an issue last time I tried sway, and I was curious about improvements since then. It was not meant to razz on your wm :)
As a maintainer and contributor to several projects I already use (and thus see the return on) I already see myself too short on resources to follow up everything I'd like to.
Trying to fix shortcomings in projects which (for me) are not yet production ready just doesn't make it onto my TODO list. I hope someone does help you fix this though.
Really. No harm meant. Hope it didn't come off that way.
That's fine, sticking with X is a totally acceptable option. If they _want_ to move to Wayland, though, and it's missing something they need, then of course they should help work on that thing.
Given that these issues has persisted for so long and that they seem solved in Gnome and KDE...
Not accusing you of full NIH, but are there any technical reasons for not just reusing/leveraging kwin or whatever Gnome uses, instead of creating your own compositor library where all these issues has to be solved, yet again?
kwin and Gnome's solutions aren't reusable on other compositors. Gnome is awful at making their stuff reusable. KDE is much better, but their clipboard stuff isn't reusable, and Sway's likely won't be either due to the nature of the problem. There are plans to collaborate more with KDE on reusing KDE components in Sway and other compositors, which both parties are excited about.
I've been using Wayland on Fedora 25 GNOME sessions for a few weeks now. I've not noticed any hiccups on copy/paste and I've definitely been doing it across Wayland-native and XWayland applications.
Sway works great as long as you have a system that can handle Wayland. I've been having terrible luck with NVidia hardware lately -- proprietary drivers are known not to support Wayland, and Wayland / Nouveau has been unstable with the hardware I use. But AMD and Intel systems are rock solid, and I've switched over to sway there.
> Wayland is just super nice compared to X11 for enough tasks to justify using it.
I'd like to hear what makes it better for you in terms of day-to-day experience. I can look at feature lists, but those often don't give a good picture of the reality that people experience. Given your enthusiasm for Wayland, I'd like to hear it!
Wayland is smoother, does not have graphical glitches and everything performs consistently.
Take this (slightly contrived) example: In Gnome 3 you can "zoom" out to panarama view all your running applications, while you have a HTML5 video running in your browser and everything just runs flawlessly, with almost no system-load, and no tearing or any nonsense. All this while you zoom in and out on whatever app or desktop or workspace you want to focus on.
A less contrived example: Vertically scrolling a document in your browser or whatever should never ever tear. Ever. On X11 it often does. On Wayland it doesn't.
My best simple comparison would be iOS vs Android. There's something about that extra little bit of responsiveness on iOS, that jerkyness you immediately notice on Android when you've gotten used to consistently smooth 60fps interfaces... That difference is something you feel.
After using Wayland for a while, you'll notice that feeling yourself on your desktop too.
Sounds like your graphics card isn't configured correctly, maybe?
I use X11 (StumpWM, actually) on three computers with different graphics cards and system configurations, and I don't have jerkyness, tearing while scrolling, or graphical glitches on any of them.
I'm using factory config on well supported Intel GPUs. I can see the difference pretty clearly. Especially when dragging a full-screen window playing youtube or whatever.
This works fine with Wayland. With X11 I get tearing. I'm pretty sure this is what everyone else is complaining about too.
>Take this (slightly contrived) example: In Gnome 3 you can "zoom" out to panarama view all your running applications, while you have a HTML5 video running in your browser and everything just runs flawlessly, with almost no system-load, and no tearing or any nonsense.
Same with a good compositing X11 window manager. In fact wayland does not dictate gpu accelerated rendering nor compositing. And there is much more to look at when talking about wayland vs X11, many details and a few major things.
But in general, no, wayland is still not ready. The people leading the desktop wayland parade have to all take a step back and think, while nvidia needs to agree with kernel people on how to manage memory. Then we can start thinking about replacing X (start, as there are still many more details).
These all sound like things that benefit heavyweight desktop environments and don't really impact tiling window managers at all.
I use DWM, no graphical glitches, no tearing, no jankiness, absolutely consistently quick (which actually kind of removes "smoothness" from the equation; everything is pretty much instantaneous).
Scrolling a document in Chromium very rarely pauses, but only ever when there's some bad JS blocking the UI, which isn't related to the window manager at all.
I want to use Wayland, but it breaks a few tools I use (Autokey [0], marathon [1]) as they depend on X-specific tooling/APIs (for marathon: wmctrl, xdotool). So I'm disabling Wayland for now even though I'd like to use it (for starters, simply to roll with GNOME's boat, since Wayland is the default on Arch).
--> Are there Wayland equivalents to wmctrl and xdotool? Any plans for them? If no, does Wayland provide a complete-enough API to write similar tools for Wayland?
Is Wayland actually that much nicer than X11? Like, I know the architecture and code and nicer, but as the end user, do you actually experience anything different?
It's actually nice to open a repository of an application with a complexity like that one and just see a few files, no crazy folder structures, no insane build scripts or similar.
I've found that to be true in general for Common Lisp projects.
With StumpWM, it's nice in terms of finding where certain functionality is implemented so I can rework it in my ~/.stumpwmrc. Having easily-accessible source code was invaluable for me adding gaps between tiled windows (and has helped me get 90% of the way done with adding a second modeline to hold WindowMaker-style dockapps).
I've been using stumpwm for quite a while, and in my opinion, the best possible setup is stumpwm as a repalcement for the xfce4 window manager (xfwm4).
This way you get a nice winwdowing environment but still have tiling wm.
This looks incredibly similar to a WM I'm writing.. except mine is written in Go using literate programming, as an excuse to try to do something substantial with LP.
In the last screenshot, what's the header at the top of the screen? Is that from the WM or the program running inside of it just drawing at the top of the screen? (It's too low resolution to tell..)
StumpWM is manually tiled, ish. It's based around splitting panes into smaller panes (rather than the fully-manual approach used by, say, subtlewm), but it's separate from the process of opening a program, so by default new windows will stack on top of one another until you split and/or move them yourself.
I used this for a few years, and loved it -- it's my favorite of all the tiling window managers I've tried, for conceptual simplicity, extensibility, and ease of use. It was dog-slow, though, and often couldn't keep up with my commands. I switched to i3 (and sway when I'm feeling adventurous) and have enjoyed that. Making window splits still isn't as brain-dead simple as it was in StumpWM, though. Maybe I'll try the new release and see if it goes any faster.
One consideration might be which Lisp you're using. SBCL is known for its speed compared to other CL implementations, for example, so using it (especially now that it's the one recommended Lisp to use with StumpWM) might help considerably.
I personally don't notice any significant performance issues, even on old single-core 32-bit hardware.
Many Lisp implementations are in the speed range of SBCL. When you look at such an application, the super optimized part of the code is not that large. Equally, if not more, important is the robustness of the runtime system against all kinds of errors, the speed and responsiveness of the memory management system and the speed of compiled code which runs with full safety checks. Also if a Lisp system would use much of CLOS, the speed of the CLOS implementation and the library one writes with CLOS becomes important.
If there are speed problems in an application like Stumpwm with the current Lisp systems, it is definitely not the raw micro-bench speed that's a problem, but more likely something else (architecture, threading, GC, event handling, bugs, ...).
While I have no idea what caused your problems at the time, I can assure you that it's nothing like that today. There is zero delay anywhere in it, and it's as fast it can be (in other words, I don't know of anything in it that, if made faster, would even be noticeable)
Come to think of it, I recall some performance issues that supposedly existed if SBCL was compiled with threading support. It's since been resolved, though, as far as I can tell.
I went far enough down the rabbit hole to conclude that the source of the trouble was threading. If that's been fixed, then I'm going to give stump another shot right now.
No one's looking at this page anymore, but I happened to have the tab open and think it's an interesting question...
StumpWM handles windows a little differently than i3. In Stump, every new window simply piles on top of the existing windows. There's no stacked/tabbed/split layouts to switch from. You switch windows with a fuzzy-matching text-completion thing.
When you want a split, you give a "split" command, either vertical or horizontal. The top-most (ie visible) window goes into the new split, and the next window down the stack becomes visible in the leftover space. Removing a split is another single command. Pulling a different window into a split is another single command.
Almost the only times I want to split windows is where I need to look at something side-by-side really quickly, for whatever reason. In Stump that's one command to split, and another to remove the split.
In i3, it's "create a split container", "move to another window", "move this window into the split container", do what you need to do, then "move this window up/out of the split container", then "move the original window up/out of the split container". I regularly get tangled up in the various containers, and have a hard time getting out of them.
I freely admit I may be doing it wrong, but I haven't yet figured out how to do it right.
The tiling part of it isn't the important bit: what's important is that they keep your windows placed in a useful manner for the task you're performing, tiling in various ways being one of the ways in which they achieve that.
Normal window managers are akin to a desk where everything is tossed around, whereas tiling window managers are like desks that automatically organise whatever is on them.
It's indeed actively maintained!... lots of changes and updates recently. They're cleaning up the code base.
After using it for over 12 years, I'm still amazed just how incredibly flexible fvwm is. You can even mimic tiling with a bit of effort (see here: https://www.youtube.com/watch?v=xdSgf-IykIo ).
If you're using Linux, it's worth just trying one. On OSX, it usually means running X11 instead of the Mac display manager which is usually not really a great thing. If you're using Windows, the options are worse.
For me, the advantages of a tiling window manager [xmonad] are:
1. Keyboard control of app switching that is easy to setup in a 'habitual' configuration yet flexible enough to change on the fly.
2. The ability to quickly switch via keystroke to and from full screen views of an application. And when I switch via keystroke from the full screen view to a view of multiple applications the multiple application view is presented in a sane and consistent way right away.
3. The ability to switch via keystroke immediately to a view of two or more applications side by side or one above the other.
There is a learning curve and as with all things that occur up until the year of the linux desktop, there is a configuration curve. But basically, a tiling window manager lets me make my windows dance to whatever tune I choose.
> If you're using Linux, it's worth just trying one. On OSX, it usually means running X11 instead of the Mac display manager which is usually not really a great thing. If you're using Windows, the options are worse.
Yes and no. Windows 10 has some tiling wm features, try win-leftarrow, win-rightarrow, win-uparrow and win-downarrow.
Ed: and mouse-drag to resize the split(s).
Ed2: Also try with more than one screen. I actually think ms have struck a tremendous balance between tiling power-user, and basic computer literacy users. I still prefer a pure/proper tiling wm.
But for Vista, I've had a daily driver with every version of Windows since 3.1. Windows 10 is a big step forward with multiple desktops. It's not comparable to Xmonad in my use case because of:
1. Xmonad's predictability.
2. Xmonad's ability to keyboard shortcut between window configurations.
3. Xmonad utilizing home position keys rather than the arrows for primary manipulation.
Anyway, the alternatives I see mentioned for Windows are based around AutoHotKey.
> On OSX, it usually means running X11 instead of the Mac display manager which is usually not really a great thing
If you're using OSX, you may want to try Amethyst[1] which provides Xmonad-like experience (at least the tiling part of it, under OSX-specific restrictions) in native Cocoa environment.
- I can completely disable all controls, notifications, status bars and the like. This leaves me with less noise and allow me to focus on the applications at hand. But usability does not suffer, I can display whatever information I like, when I like with a simply shortcut. F.e. If I need to take a look at the date I just hit `C-t d` and it shows up.
- I can assign shortcuts to applications. For example, wherever I am, whatever is on the forefront I can hit `C-t f` and Firefox will show up, I hit it again and it will go to another Firefox window if there is one, terminal is `C-t c` and so on. I stop doing window management altogether and work on higher level.
Note also that StumpWM does manual window management, while it sounds tedious, in fact it is a delight. You have all your stuff exactly as you like it without the WM trying to guess anything.
What a tiling WM does in this situation is remove the part of the equation where you have to think about maximizing your windows. Instead of mouse interactions with GUI controls for window placement and scaling, you just use a couple of hotkeys to cycle between window layouts and navigate workspaces (i.e., if you want side-by-side windows for a moment during some task, you hit a key once or twice, then do the same to get back to maximized windows). This may not seem like it's much cognitive load to get rid of, but for me at least, going back after a few months of having the WM just handle things felt clumsy and primitive.
It will also ruin you for using most standard desktop environments, and I personally burn probably a solid day a year porting my WM config to some new environment. These have been a worthwhile trade-offs for me, but probably something to consider if you have to use systems you don't control very often.
It's more of a shortcut-driven automanagement of windows. When I see people in "normal" windowing environments work, the workflow goes: open an app, drag it to the correct monitor and corner of that monitor, and then optionally manually resize it. Bonus points for taking a few seconds to fish for the exact edge of the window's frame when resizing. Or misclicking when aiming for the title bar and opening a menu instead or hiding the window because you clicked on some other window it was hovering over.
Tiling window managers: open application, and the window manager puts it in a sensible position most of the time. Use shortcuts to quickly correct its placement, if necessary. Typically shortcuts are something like
- switch to master pane (the biggest pane on the screen)
In terms of a command line metaphor, it is the keyboard shortcuts for accessing history or editing the text of a command. It is not a command line in the sense of options to grep.
But what it is most like (switching to simile) is Emacs window manager...by which I mean that Emacs uses a tiling window manager.
I'd say it's more like a terminal multiplexer for window management, if you're familiar with screen or tmux. (Using XMonad for windows and using tmux for collections of shells / terminal apps have followed similar tracks in my life.)
Your windows will never overlap. If you always have your windows maximized, then you can definitively benefit from a tiling window manager since it will always open new windows maximized.
I also have my windows maximized and have each window assigned to a different workspace. Switching is as easy as pressing alt + 1, alt + 2, etc ... (in i3wm)
It's kind of like having everything maximized, but more flexibly. For example:
* You can have two editor windows "maximized" into two halves of your screen, letting you compare things side-by side
* Expanding on the above, my typical development workflow on my laptop is to dedicate one half to an editor window, then split the other half, with the top for git (I use Emacs w/ Magit) and the bottom for a terminal window (usually for actually running my project). I'll then add editor windows to the left half and terminal windows to the bottom-right as needed. All windows are maximized into their little compartments.
* Your "maximize everything" workflow is actually the default in StumpWM (which doesn't split windows unless you tell it to split windows), and is how I typically work when I don't need to be viewing multiple things at once.
The main advantage I find is that I don't need to use the mouse to manage my windows. I split my screen to have my emacs session and terminal/browser etc., side-by-side. I can move the windows using key bindings: snap them, split the screen etc.,.
Also extremely light-weight when compared to DEs like Unity/Gnome.
Maximize stops to make sense at some point when your screen gets large enough. You can have at least two windows side by side and maybe a console below without having to sacrifice some sidebar in your IDE or whatever.
I have the habit of maximizing the browser on windows, but on most pages that leaves a lot of empty space to the sides that isn't used anyway.
Under i3 on the other hand I keep the browser on maybe 1/3rd of the screen width because managing the whole layout (not just one window at a time) is so much easier.
And the alternative, overlapping/floating rarely seems useful for me.
They're simpler than desktop environments in every way.
I have found that I use 10% and absolutely require 0% of the larger DEs' features, so using a simpler system makes sense.
Your use case seems like it would work well with tiling window managers, since you can just arrange things so that you have a single fullscreen window per workspace.
I used Xfce and switched to i3. I can't imagine going back whenever I'm in Linux. My work environment is MacOS and its frustrating having to manually move windows and like others have said is just plain clunky after having used a tiling window manager. It did take a bit of time to get used to i3, but once I did it was glorious.
I love StumpWM because it does not force a workflow on me! I have configured it to work the way I want it to! And as far as I know I cannot have this workflow in any other tiling window manager!
If I want to open firefox I press `F9` and then `f`.
Let's start a terminal window... `F9` `t`
Let's open emacs... `F9` `e`
Now I want to go back to firefox... `F9` `f`
Press `F8` if you want to switch between last 2 windows (emacs & firefox)...
F8 ... and I'm back at my emacs window...
Neat ha?
Oh, and I forgot to mention that everything is in full screen! 29" of real estate for every app! No tiling or stacking windows.
There are no numbers, tags or anything to remember. Too bad this will never work on a mac... everything starts with an i... just kidding! :)
If you are interested in my stumpwmrc file:
https://github.com/seyedip/my-stumpwmrc