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

... oh, one more thing.

* BUG: Given the README doc located at the github repo
(http://github.com/sunaku/wmiirc), it'd be nice if the example crash
recovery .xinitrc supported a "clean shutdown" -- i.e. if I select
"quit" from the menu, then wmii should always quit, without asking if
I'd like to restart the window manager. In this instance, all my
clients are dead anyway, so restarting wmii at that point is somewhat
pointless.

__armando

On Mon, Jan 4, 2010 at 2:41 PM, Armando Di Cianno <armando_AT_goodship.net> wrote:
> 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:57:12 UTC