Suraj, The new release looks interesting. I spent a bit of time yesterday porting my settings over (a bit of a hassle, since I was working on a WMII-type DE using ruby wmiirc setup as a base). I definitely like the breakdown -- it's going to be *very* easy now to do minor edits (e.g. a keybinding) or to bring in all new functionality (e.g. my crazy DE type stuff) with imports. Also, this makes it very easy to share neat-o features people develop.
Here's some notes: * BUG: reload (from /lib/wmiirc, i.e. the menu) does not work -- it attempts to launch ".wmii/wmiirc" (which is $0) instead of the full path, e.g. "~/.wmii/wmiirc" or "/home/fafhrd/.wmii/wmiirc". * ANNOYANCE: It was really surprising to see the defaults for max/stack/default be Mod-z,X. I don't follow HEAD of wmii development (maybe I should), but this really confused me for a minute. Maybe I use column client shifting more than most, but I'll probably be changing this back. (The addition of Mod-z,Shift-X is interesting, btw.) * BUG: Related to above, but Mod-z,s/d don't seem to work right at all, creating new columns willy-nilly (although Mod-z,m seems to work). For e.g., if I have 2 columns, the right most with 4 clients, and one is focused, then I do Mod-z,d, I get a new middle column with 3 clients, and the focused one of the 4, is now in its own column, rightmost. * ANNOYANCE: the default move of cycling through tags went from Mod-b and n to Mod-, and .. This would've been fine, but Mod-b is now "move to temporary view", which was confounding for a minute as I made sense of the new environment * BUG: running ~/.wmii/wmiirc doesn't return -- not /explicitly/ a bug, but I'd expect it to do so, after killing/cleaning up the last instance. I do agree with Emmanuel's point, that generally, editting Ruby-code in the YAML file is somewhat irritating. Hopefully, as this reorganization and cleanup continues, we might be able to massage that a bit. Thanks for your efforts in Ruby + wmii! Cheers, __armando On Mon, Jan 4, 2010 at 12:41 AM, Suraj Kurapati <sun...@gmail.com> wrote: > On Sun, Jan 3, 2010 at 7:33 PM, Emmanuel Oga <emmanuel...@gmail.com> wrote: >> On Sun, Jan 3, 2010 at 5:32 PM, Suraj Kurapati <sun...@gmail.com> wrote: >>> I'm pleased to announce the next evolution of my YAML-based Ruby wmiirc: >>> >>> http://github.com/sunaku/wmiirc >> >> Thanks a lot for your hard work. I just recently started using your >> ruby based wmiirc and I'm enjoying a lot being able to configure my >> wmii with ruby so easily. > > Thanks for the kind words. I'm glad this project was useful to you. > >> At the same time, I must point out that I find very annoying the usage >> of YAML for the configuration files. I suppose you choose to use it >> because it seemed to make sense for a configuration file. > > Yes, since the problem domain here is to describe a > configuration, YAML felt like a better tool for the job because it let > us describe the configuration declaratively, with minimal added syntax > to distract us from the task at hand. > >> But this configuration is so overcharged with ruby scripts that IMHO >> is not very practical to use YAML. wmii audiance is clearly >> programmers, and I think so called power users need to know at least a >> little about programming to be able to use the wmiirc. > > Good point. Mauricio Fernandez's ruby-wmii took the full-Ruby approach > in the past, providing an internal DSL to configure wmii. And wmiircs > written in other languages (Python, Lua, etc.) have basically followed > the same approach. I guess I just wanted to try something different. > > However, I did not intend to "dumb down" the configuration by using YAML > (and I do not think of it that way) because I consider myself as the > primary target audience. i.e. I eat my own dog food, and like it. :-) > >> Using YAML, the scripts end up looking like python (i.e., how you use >> white space matters), which is very annoying. > > I'm sorry to hear this. I was happy with the declarative YAML exterior > and imperative Ruby cream filling because they felt like a good balance > of both worlds (i.e. using the right tool for the job): declarative to > get straight to point and imperative to do the heavy lifting. > >> I had a goal to convert your YAML scripts to plain old ruby code, ... >> good thing I procrastinated it this time, now I'll be able to use your >> new code as a starting point! :-) > > Sure, this sounds interesting. I would imagine that only the interface > through which we humans describe our configuration to the machine would > change: from an external DSL to an internal one. Hopefully we can share > the internals beneath these two interfaces. > > Cheers. > >
