On Mon, 27 Aug 2007 07:45:08 +0900
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote:

> > In any event, I never thought that enlightenment_remote was complex...
> > But I imagine that what makes it complex is the fact that it can
> > perform actions; it can immediately alter the behavior of
> > Enlightenment. I imagine that if it only changed configuration, it would
> 
> yes - and the bad bit is - this conflicts with code for the config gui. the
> fact is that almost every app on the planet provides a GUI (built in) to
> configure itself - preferences dialogs for firefox, settings dialogs for gimp.
> almost NONE provide "remote control". most of the time people don't care - and
> don't need it.
> 
> > be very simple. So, if you are telling me that unfortunately I cannot
> > have all the features of enlightenment_remote, can at least we have a
> > tool to edit Enlightenment's binary configuration files via the command
> > line? Most Unix application (including window
> > managers) can be configured by editing text files. And I don't think
> > that's just tradition, I think it is very useful.
> 
> it's a vector for screwing the config, making e's job harder in parsing it and
> sanitising it. this is possible - but in the end - i don't see myself spending
> time on it. you have everything you need or want via gui controls. we are 
> going
> to extend remote control via dbus so we don't need to write a client, and 
> allow
> modules to extend remote control as they see fit. basically put in place the
> ability to have what you want, but we just don't want to sink the time into 
> all
> the code.

Well,  you  know  better  than  me.   It's  just  that  I  thought
that  a  CLI configuration editor would be far quicker to code than a
GUI one, so coding both a GUI and a CLI would be only  slightly harder
than coding only the GUI. It gets even easier when  you consider that
the GUI  and the CLI can share  code. But, I confess that  my knowledge
of  Enlightenment is "a  black box that gets  the job done".

> 
> > One quick example: suppose I decide to make a big change in my
> > keybindings. Am I supposed to use the GUI and change them one by one?
> 
> yes.
> 
> > If I could configure the keybindings through a text file* ,
> > changing dozens of keybindings would probably be as simple as a query
> > replace.
> 
> like what? i hope you know by heart all the x keysym names then! what about 
> the
> modifier your press? do you know if its Meta? Hyper? Super? What's the Keysym
> or Keycode for the play/pause button on your keyboard? what about the 
> "Shuffle"
> button?

Then I add the keybinding using the GUI. And if I desire, I can see
what the GUI has done so I learn how to do that with the command-line.

I'm not a GUI  hater, I think the GUI has its place,  specially when
you are not familiar with the application, but the keyboard is faster
and scriptable.

I see the GUI as "I just  need to get something done, right now,
without reading any manual" and the  CLI as "I want to invest some
time in this application and become efficient in  it".  So for image
editing I use the GIMP,  because I edit images very  rarely so I
imagine  it wouldn't be  worth to learn a  command line tool for that.
But for editing text files,  which I do all day long, I have put some
time into learning Emacs.  By the way, one thing I love in Emacs is
that it has  multiple  interfaces:  the  menus,   the  buttons,  the
M-x  command,  the keybindings...  I can first use the easiest ones
(menus, buttons), and with time I get used to the more efficient ones
(keybindings).

> 
> > * I can do that now by telling enlightenment_remote to dump the
> > keybindings, then edit the resulting file, then tell enlightenment_remote to
> > delete the current keybindings, and then tell enlightenment_remote to add 
> > the
> > keybindings from the edited dump. Sounds like it takes some time, but is far
> > quickier than it would be to use the Enlighenment's GUI and click on each
> > keybinding that needs changing. I do it all the time.
> 
> i really don't believe that. if you are doing this all the time - something is
> deeply wrong. you are literally en-masse changing keybindings all the time?
> why? i might touch them once on setup to add a few (eg my media keys), then 
> not
> know or see the bindings for weeks or months - then need to add another to
> launch some app or whatever. why do you need to keep changing them?
> 

Suppose that I  add a keybinding for  a program that runs under  xterm:
xterm -e alsamixer, for example.  Than after a  week I add another
keybinding for another program running under xterm. Then after  two
months I have 10 bindings for xterm -e something. Then I decide to  use
another terminal emulator.  With a text file for the keybindings, I can
just search for xterm and replace for (say) aterm. If I only  have the
gui, I  would have  to do it  one by  one. Feasible,  but less
efficient than editing a text file.

Of course, if I knew that since the  beginning, I would have come up
with a more intelligent  way of adding  a keybinding  for a  terminal
than  directly calling xterm. But I didn't imagine it.

Because of  these situations, and because  I want to be  able to nuke
my .e and restore the  relevant customizations  (mostly, the
keybindings)  I wrote  a tiny python script that  saves, deletes and
adds bindings from/to  a text file, using enlightenment_remote. And now
that the script is already written, I prefer using it for keybinding
customization  instead of the GUI.

This is just a simple example. The point is, I do believe that having
only a GUI limits  the possible  uses  of an  application.  I  do  like
the  Unix model  of allowing the user to combine several programs in
creative ways.

-- 
Software is like sex: it is better when it is free. --Linus Torvalds

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
enlightenment-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Reply via email to