Re: [dev] Re: [ANN] Ruby wmiirc - YAML import feature

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 <sunaku_AT_gmail.com> wrote:
> On Sun, Jan 3, 2010 at 7:33 PM, Emmanuel Oga <emmanueloga_AT_gmail.com> wrote:
>> On Sun, Jan 3, 2010 at 5:32 PM, Suraj Kurapati <sunaku_AT_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.
>
>
Received on Mon Jan 04 2010 - 19:41:02 UTC