Re: [gtk-list] Re: PROPOSAL: Automatic wrapping of CLIs with GUIs

[lutterdc cs purdue edu (David Lutterkort)]

> On Tue Jun 16, Marius Vollmer <mvo@zagadka.ping.de> wrote:
> 
> I think it's way cool.

Thanks ! :)

> 
> I wouldn't regard as *the* break-thru idea for finally making the
No ? ;)
> command line accessible to GUI people, tho.  I see as a very solid way
> to quickly whip up a rich GUI for certain programs where this is
> useful.  Encaps is a good example, while ls probably is not.

ls as such is a shitty example, since any file manager does it better
... except it shows that one needs some kind of constraint system to
express all the dependencies of options for command line tools. The reason
I pick on the command line is less that this is the ultimately kool
application, but trying to do the wrapping might teach one a thing or two
about high-level desciption (and generation) of GUIs. The angle I'm coming
from is that I think that callbacks are a serious pain in the butt, yet I
have a hard time conceiving of an alternative to the event-driven model. In
an ideal world, the actions a GUI takes should be described in a
declarative manner, which allows one to keep the bigger picture in
mind. For many simple GUIs, the reactive style amounts to writing a finite
state automaton by chopping it up all over the program and putting one or
two state transitions into each callback. I'm surprised that there isn't
more research done on these issues; the only paper I could come up with is
Mathew Fuchs' 'Escaping the event--loop'.

> 
> Therefore, I would not focus on wrapping individual command line
> programs, but more on convenient access to them, and a simple way to
> rig up good GUIs for them.  Of course this is what wickel is doing
> now, I'm thinking more about its future directions here.  That is, you
> should not necessarily focus on wrapping a single program, with GUI
> features that map one-to-one to command line switches, and embedding
> GUI stuff into man pages.  I see more potential for it as the

Good point. Yes, I want to put something into wickel.scm that lets one work
with the values in the GUI as if they were ordinary variables, without
having to even think about how exactly this integer-valued variable gets
its value. Right now, though, I was only intending to put the notebook
generated through the descriptions of the options into a fairly static
framework and worry about how this could be hooked with user code later. It
seems like a lot of work ...

> ...
> Ahh, there is encaps, let's just wickel a nice GUI around it."
                                   ^^^^^^ :)
> 
> Such a GUI wouldn't need to be everything to everybody because it
> would be so easy to write in the first place, and people could quickly
> adapt it by hacking the source.

Agreed. The description of the options should be separated from the
layout. The descriptions could be kept in some kind of repository and the
layout (and hopefully some actions) can be tinkered with by the user. 

> 
> ... more good stuff deleted ...
> 
> Btw, I really like the "wickel" name!
> 

Huebsch, gell ? 

David