On Sat, Apr 29, 2006 at 10:44:23PM +0400, Alex Elide wrote:
> On Sat, Apr 29, 2006 at 06:42:39PM +0200, Anselm R. Garbe wrote:
> > Nah, that is somewhat over-engineered to my taste as a default ;)
> > Though thanks anyway.
> ---end quoted text---
>
> and what do you think about this function?
> --
> unset KEYS ACTIONS
> function bind_key(){
> KEYS[$(([EMAIL PROTECTED]))]="$1"
> ACTIONS[$(([EMAIL PROTECTED]))]="$2"
> }
> --
>
> it is very simple to bind keys
> --
> M=$MODKEY
> C=Control
> bind_key $C-Return 'aterm &'
> .....
> bind_key $M-d 'xw /view/sel/mode default'
> bind_key $M-s 'xw /view/sel/mode stack'
> bind_key $M-m 'xw /view/sel/mode max'
> --
>
> then, you can easily define active hotkeys with
> --
> for i in "[EMAIL PROTECTED]"; do echo "$i"; done | wmiir write /def/keys
> --
>
> process hotkey events with
> --
> # in event loop
> case "$type" in
> .......
> Key)
> for i in `seq 0 [EMAIL PROTECTED]; do
> [ "$1" = "${KEYS[$i]}" ] && eval
> "${ACTIONS[$i]}"
> done
> ;;
> .......
> esac
> --
>
> I think, this is better, then necessity to maintain two
> separate list of buttons and actions in two different places
> in wmiirc.
I agree that maintaining two places for shortcuts (first place
the defintions and second place the event messages) in wmiirc is
a bit messy and not optimal, but it is the way which sucks less
in my eyes. Your proposal doesn't look to be sh-compliant, I
doubt that it would run in old plain sh or ksh on a BSD without
trouble, thus it cannot be a default (even it it might be POSIX
sh compliant).
Also, all approaches I can guess which only use one place to
define and catch the shortcuts (the most portable and elegant
approach was an awk-based one I recently saw on IRC), lack to
support straight-forward execution of multiple commands in the
event catching loop (beside being somewhat cryptic and awkward).
Currently I can easily do:
key)
foo -bar
bar -foo
baz -foo=bar -bar=baz -bank
xwrite /ctl wtf
xterm -e foobar &
a=`whatever`
xwrite /ctl $a
;;
It might be possible to handle such kind of stuff in such kind
of function like your in bind_key(), but it would look very ugly
and very cryptic.
That is why I favorize a simple approach. What would seem more
straightforward in my eyes than trying to handle all this stuff
in a shell script (and I'm curios that nobody proposed something
like the following idea already) is to use a generator-language to
generate wmiirc - which seems much simplier than doing nasty
stuff in sh.
Anyway, I don't ask anyone to bother his time to do such stuff,
because using yet another generator language as default is not
planned, because this means yet another layer and dependency.
Thus I personally think, that the current approach sucks less
after all.
Regards,
--
Anselm R. Garbe ><>< www.ebrag.de ><>< GPG key: 0D73F361
_______________________________________________
[email protected] mailing list
http://wmii.de/cgi-bin/mailman/listinfo/wmii
