5 ms·

Some projects seem missing from the site. For example, this used to be the home of wmi[1] and wmii[2], the ancestors of i3. There's quite a bit to see if one b

• deleted 6y ago
  [deleted]
• tfolbrecht 6y ago
  You’re probably thinking of dwm. Another great tiling window manager.
• LukeShu 6y ago
  If i3 is descended from wmii, that's news to me. wmii moved to Google Code[1] before becoming abandonware before Google Code shut down. Nevertheless, I continue to use wmii as my daily driver (as it has been for just a few months shy of 10 years), but it's really starting to wear on me that bugs won't be fixed unless I fix them[2], which I no longer have the gumption to do. [1] https://code.google.com/archive/p/wmii/ https://code.google.com/archive/p/wmii/ [2]: https://code.google.com/archive/p/wmii/issues/270 https://code.google.com/archive/p/wmii/issues/270 (when Google Code archived, a lot of users got weirdly anonymized? "Swift Bird" is me, apparently?)
  • jolmg 6y ago
    > If i3 is descended from wmii, that's news to me. I meant as heavily inspired by it, not as based on the same code. From https://i3wm.org/ https://i3wm.org/: > Based upon the experiences we made when wanting to hack/fix wmii, we agreed upon the following goals for i3... Also, from the manpage i3(1): > i3 was created because wmii, our favorite window manager at the time, didn’t provide some features we wanted (multi-monitor done right, for example), had some bugs, didn’t progress since quite some time and wasn’t easy to hack at all (source code comments/documentation completely lacking). Still, we think the wmii developers and contributors did a great job. Thank you for inspiring us to create i3. > wmii moved to Google Code[1] before becoming abandonware before Google Code shut down. Both wmi's and wmii's code can also still be obtained at https://dl.suckless.org/ https://dl.suckless.org/. Those are packages, though. It's great that the repo for wmii is still available. Thanks for those links.
  • nebula3 6y ago
    If you did switch away from wmii, what window manager would you switch to? I’m in the same situation where after using wmii for so long none of the other tiling window managers feel right.
    • jolmg 6y ago
      Not LukeShu, but I skimmed the guide for wmii from the WaybackMachine and found its idea of events quite unique and interesting (though I'm not sure I can think of a good use for it). i3 seems like it might have something like it, but that particular feature doesn't seem to be well documented. Anyway, I wanted to ask you both, what do you like most about wmii that you'd miss by switching?
      • LukeShu 6y ago
        "Configuration as code" is a concept that really speaks to me. It's the ethos of Emacs (which I also use), and wmii does it as well. <tangent>In fact, for a long time (now I'm not so sure) I even thought wmii did it better than Emacs: Instead of being tied to one language and one process, wmii exports everything as a filesystem, and you configure it by writing a program that inspects and modifies that filesystem. Instead of being tied to operating on in-memory objects in Lisp, you're operating on in-filesystem objects in the language of your choice. (Today, I still think configuration by exporting a 9p filesystem is a powerful idea, but I've come to realize some of wmii's assumptions are a little opinionated to where I'm less sure about "better than Emacs"). I'd previously used StumpWM, which is configured in Common Lisp and is very similar to Emacs; I wasn't very comfortable in Lisp (and am still not terribly comfortable in it, though much more than I was), and also at the time StumpWM wans't packaged in the main Arch/Parabola repos and wmii was.</tangent> It's my understanding that most wmii users use one of the standard/example "wmiirc" scripts, and fuss with a few variables and make minor tweaks to customize it to their liking. My wmiirc (while inspired by the stock one), is written entirely by me. My code reads events from a socket on the filesystem, and then manipulates other files in the filesystem in response. It's like, even without taking the time to fully understand wmii's codebase, I feel like I have a very robust understanding of exactly what it's doing, as if I did understand the full codebase; because every action it takes is because of a line of code I wrote. And related to that, I'm pretty sure no other human in the world has their window manager keybindings set like I do; how it's configured is very personal and "mine". I don't want a static configuration file, I want a dynamic configuration program. As a stupid example of "configuration as code": For most of the last 10 years I had a file of hex color codes to configure the color theme for wmii. Usually what would happen is I'd switch my Emacs color theme, then some time later adjust the wmii theme to match. A month or two ago, I got sick of that, and adjusted it to dynamically use `emacsclient --eval` to just query Emacs about the colors of its current theme, so I never have to deal with it again.