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

[Miroslav Silovic <silovic zesoi fer hr>]

lutterdc@cs.purdue.edu (David Lutterkort) writes:

> > I wouldn't regard as *the* break-thru idea for finally making the
> > 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'.

Perhaps you could solve the problem using high level of Scheme abuse,
namely the fact that you can put a function anywhere where data is
normally expected. So, how about this approach (I'm not using wickel
syntax here, just an ad-hoc thing to demonstrate the point):

Suppose you have an option foo that can only be set if the option bar
is set to #t. Then I'd use a specifier like this (note keyword
arguments, using Maciej Stachowiak's optargs.scm):

(option "Fully normalize input" 'boolean
	#:false-if (lambda () (eq? (get-option "Normalize input") #f))
	#:reevaluate-on-change '("Normalize input"))

This would pass a function that'd monitor another option and calculate
the constraint. And the function would get reevaluated whenever the
option "Normalize input" changes (as controlled by the other
option). The key issue here is that you might be able to use proper
contraint programming model, rather than callbacks, with contraints
being closures.

-- 
I refuse to use .sig