I like that the whole WM is implemented in two files, a .h for configuration and a .c. The code looks clean and has embedded ascii-art. This looks like a project made with love.
Thank you, this is my first proper C project so I have learnt a lot and have come a long way. I have really enjoyed working on it and would certainly describe it as a labour of love.
Really dislike software with configuration baked into the code, every key binding and experiment requires recompilation which prevents managing it sanely through a package manager.
I get the appeal of "minimal" in this case, but it just doesn't work for me.
I understand that it isn't a nice idea having code and configuration mixed together and that splitting them would be preferable. However, howm takes less than 1 second to compile on my laptop, once you have a configuration that you like you'll rarely change it and I feel that having the configuration in code makes it easier for hackers to find subtle new ways of customising howm.
A downside that I can see to using a header file for configuration is that a compile is required for installation and configuration. I don't see this as being too much of an issue as I don't plan on making howm available as a binary, so a compiler would be required anyway.
I think we can all agree that once a good setup is found, you don't change it that much; recompiling is ok as long as it's fast.
The point of GP is that since config.h is part of the standard distribution, any local modification should be overwritten (or discarded) upon updating the software, or the user has to maintain a local "fork" with his custom config.h.
You should get inspiration from what suckless does [0]. It uses the same idea of config through header, and the "solution" is workable for all involved parties.
The benefits of this model include less attack surface area and much leaner code resulting in less bugs. It doesn't fit every project, but the "configuration" code for this WM would likely be larger than the WM itself.
It's not "we need to keep compile time down to seconds, therefore configure in the source"; it's "compile time is seconds (if that), so there's not much difference between configuring in the source and configuring in a file except complexity". One part of the motivation for the best practice you cite is that compiling can be complicated and take a long time, and configuration changes should be quick. This is a solid argument against that portion of the motivation. Following practices because they are known as best practices when the motivations for those practices don't apply has another name - cargo culting.
Edited to add: Which is not to say that this best practice should be simply discarded, but to say that the appropriate response is to point to the other motivations for it and determine whether they are more important than the upsides of configuring in the source.
> Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though.
I think I explicitly stated that I was not covering the whole story. The above would be another consideration - with both pros and cons (of which suckless, of course, stresses the pros) - which should be factored in. There are others as well.
I really love vim keybindings and I use them wherever I can (firefox with vimperator, the shell etc), however I'm not sure that modes make sense on a window manager. In my opininon it doesn't have that many operations, and they don't differ that much from each other, I think that having to think which mode you're on and which one you need to use would only introduce friction and slow you down (in this case the normal mode is not that normal, i switch windows as often or more than I create new ones or switch layouts).
Another thing is that the operators, motions, and objects each need its modifier keys; in my opinion that just misses the point of having modes and one of the strong points of the vim keybindings. Because of that it was really hard for me to understand how to use Howm:
the first time around I skipped the configuration part and went directly to the examples, and you don't mention anywhere there that q4c (for example) is really Alt_L+q, Alt_L+4, Alt_L+c. When I read the configuration part and the configuration file, to see each keybinding I got it, but still it took some googling to figure out that I needed to use xmodmap to know which keys are the MODXMASK.
EDIT: It seems you do mention that the operators, motions and objects need a modifier key, I missed it. Still, I think that it would be clearer if the keys to press were explicitly indicated (like Alt_L+q, Alt_L+4, Alt_L+c)
I have some more ideas for operations to add, this is the first release I have done and so it is lacking some features. I agree that some people might not find certain commands to be in the correct mode. You can change that from the configuration file though. I certainly take your point on board about moving being in normal mode and will have a think about whether or not this should be the default.
That's really great feedback about the documentation, I'll make it more obvious which modifiers keys need to be held down. Again, you can change the modifier key used for operators, counts and motions so that howm only uses one modifier key. This is how I had it for most of howm's development. I changed to using two modifier keys as I felt that it was nicer to have a logical separation between the commands and the operators, motions and counts. It also meant that some keys could be reused but with different modifiers.
I think they shouldn't use modifiers at all, ideally you would enter the mode with MODIFIER+modekey and then press the normal keys: q2c. I don't know if that's possible with your current program but that's what I meant.
It's a cool project but again I'm not sure what I would gain from the modes, counts and motions. Right now I use Awesome WM which is really similar to howm without changing modes, and without using the motions and counts (but I don't really find myself wanting to use counts to move windows).
One of the reasons I continue development work predominantly in windows OS is its vast support for mouse-free operability. I love vim for the same reason. I tried ratpoison in linux but found it to interfere with application keyboard shortcuts. I also tried AwesomeWM but it wasnt as graceful as the windows key in windows.
If someone was to solve this issue elegantly it would compel me to reconsider moving my daily development activities back to linux
Have you tried other tiling window managers ? i3 [0] comes to mind, but XMonad [1] and Awesome WM [2] are 2 other popular choices in this domain. There are plenty of others to pick from, too [3].
Thats a great list thank you! I never heard of i3wm I promise to read the docs.
Yes, microsoft windows. I use version 8.1 and while most end users loathe the interface I've studied the "windows" key and "context menu" key and found it quite fast to perform all my daily operations (except web browsing) mouse-free.
My experience with linux is that some programs are great but too many dont follow standard on very common keyboard operations such as search, tab navigation, context menu. Also it seems many of these desktop windows managers such as ratpoison come with default key mappings that conflict with many of my application's default key mappings which forces me to re-configure.
I invested some time customizing key mappings that would alleviate the issues, but I have a large stack of actual programming work I need to get to, and after awhile I just felt like I was trying too hard at it and decided to go back to the system that works for me. I would like to learn a little more about developer's mouse-free success with linux, vim, browsers and ides such as intellij. 2 years back when i researched this it didnt seem like a very important issue to many people, but to me the little bits of speed gained from keyboard shortcuts add up into great savings in time and cuts in repetitive movement and I consider it to be a crucial part of any development system.
I use awesome WM and I didn't need to customize any of the keyboard shortcuts; it uses the windows key as the modifier key and as far as I know no other program uses it.
Also I don't get how the Windows 8.1 window management comes even close to the 2 programs you mentioned (Ratpoison and Awesome WM). With both of those (or any other tiling manager) you can do much more than just maximize and snap a window to the sides. (you have virtual workspaces, automatic tiling, better switching, etc)
Maybe I need to invest a little more time into it. I agree with you that the docking keyboard shortcuts are far less powerful in windows. In practice however, this limitation doesnt really become an issue for me. Maybe it is because I have tunnel vision but 2 programs per monitor with a quick means of switching things around hasnt left me wishing I could have 3,4+ programs per monitor
I must admit I stopped my knowledge of Windows at Windows 7, which already has some tiling thingies but nothing even remotely close to the WMs I linked to earlier.
The thing that is the most visible to me is virtual workspaces. It allows you to create fixed layouts of programs (editor on the left, terminal to test on the up-right corner and tail -f of the relevant log on the down-right corner) grouped within a user-defined context ("code on project1", "code on project2", "mail", "browser").
The idea is to switch from activity to activity, rather than from application to application. It's extremely important, because when you start piling up activities, you accumulate applications, and you don't want to switch through all of them within your activity.
I think serious Linux users going for mouse-free and / or using tiling window managers designate one of the Windows / menu / command / Apple keys as "window manager" key as well.
It's nice though that MS made this a default for Windows, while Linux still wants to ignore that MS ever managed to get those keys added to the keyboard. I've been using them for years, one as wm-key and the other as compose key to be able to write special characters (ë, ø, €, etc.) easily on a default qwerty keyboard. That still leaves one spare key on most keyboards
which was his blog, and there are not archive.org copies from 2009 and before. He had a lot of very thought provoking and iconoclastic things to say about OSS and the OSS movement that I found very interesting.
ion3 is one of the tools that you start to appreciate only after you use it for some time and you can't just explain it by enumerating features. Because alone those features don't sound that impressive and distinct. But it's the combination that matters.
In Windows, Alt-Space gives you a menu that lets you move and resize windows without using the mouse. Also in Windows 7 and 8, holding the Windows/Super key and tapping "left" or "right" causes apps to take up half the screen, and "up" maximizes.
Having been stuck working with a couple Windows 8.1 servers, through remote desktop from a mouseless linux box, I can confirm that Windows has got surprisingly usable without a mouse. IMO, though, my ratpoison setup still beats it by miles (at least for my work flows).
"I tried ratpoison in linux but found it to interfere with application keyboard shortcuts."
Huh? Rat poison is the only window manager I've used that interferes (meaningfully) with precisely zero application keyboard shortcuts. This is because it only intercepts one key, and having pressed that you there is a key bound in the next map to send the original key. And of course you can pick that top level key.
Edited to add: Though having said that, does anyone have any thoughts as to why my compose key doesn't work in ratpoison? I'd like to cut out the switch to unity when I want to study Polish...
I use xmonad when I'm on linux. Now that I'm required to use windows, I use python-windows-tiler[0]. The one thing I sorely miss about xmonad is its multi-monitor support. You get nine workspaces. Each of these is monitor independent. It is trivial to put ws1 on m1 and ws2 on m2, then switch m2 to have ws7. The tiling window managers I've found for ms Windows simply don't have any concept of having workspaces independent of monitors. Every workspace always take up all of your monitors.
On linux I'll usually have a browser workspace, an ide workspace, an email/chat workspace, a console workspace, etc. And I'm able to rapidly put any combination of workspaces on my set of monitors.
I have used the awesome window manager (http://awesome.naquadah.org) for a long time. I think most of the big tiling window managers (DWM, xmonad) are similar.
The only things I ever use a mouse for on my linux computers is browsing the web.
>The only thing I use my mouse for is browsing the web.
I love vimium and vimperator. The only thing I use my mouse for is browsing pages with flash or embedded video. Some other browsing as well, but it's nice to be able to pop back and forth between term and browser, scroll the tutorial page down then pop back without a mouse.
It's been a while since I used vimperator/pentadactyl. I recall it not being compatible with newer versions of firefox, but from what I gather those issues seems to be resolved. I should take another look.
Most of my day is spent using OSX, and I am quite alright using a mouse in that environment for most things.
Yeah, I haven't really had any issues with it over the last year. I don't always browse with vimporator but it's nice to have the option to follow a link, go back a page or scroll up and down without a mouse. It really depends on the workflow I'm in.
Until my daughter was born, I wanted to do everything without a mouse and I worked hard on that. But then I started getting annoyed that I needed both hands to work the machine. Now I have both workflows down pretty well and with my WM I can do most things with either.
Harvey, your code looks very nice and expressive with appropriate comments. There is some space for improvements on this matter (well, there always is) but I found it very good to read and easy to follow!
Thanks for the kind words! It'd be great if you could tell me what improvements you think would be best, I'm trying to make howm's code as nice as I can. I know that having everything in one file is frowned upon, but I quite like the simplicity of it.
It's loosely inspired by dwm in that it uses a similar configuration file and keybinding system.
On a technical level, howm uses xcb- a more modern and efficient X protocol binding. dwm uses xlib.
From a user's perspective, howm has multiple modes for manipulating different kinds of windows as well as operators, motions and counts. This means that multiple windows can have the same operation performed upon them. For example (assuming that the correct modifier keys are being pressed) pressing "q4w" will lead to 4 windows being closed.
howm also has some features that dwm only provides as patches, such as useless gaps and a grid layout.
