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

[lutterdc cs purdue edu (David Lutterkort)]

> On Tue Jun 16, Jeff Dike <jdike@karaya.com> wrote:
> 
> mvo@zagadka.ping.de said:
> > I think it's way cool. 

> Me too.  I would have to agree with Marius' other comments, too.  It
:) I'm starting to like this 

> shouldn't be used in a program of giving every Unix command its own GUI.
> It would make more sense to use it to quickly provide a GUI to some area
> of interest, and it would end up encapsulating how ever many Unix
> commands it took to cover that area, whether that's 1 (as with encaps) or
> >> 1 (as with a file manager).

Agreed. This essentially means that the declarations of the command line
options has to be separated from (1) the layout and (2) the actions
associated with the GUI. 

>  This looks related to something I've been thinking about for a while.
> I've been thinking about having a GUI description language that described
> the actions that a user would take to fill in (say) a dialog box.  It
> wouldn't contain any references to any particular widgets, just
> particular actions and types of information.  This description would be
> passed for layout into wickel, which would map actions and pieces of
> information onto widgets.

The layout and the actions should be kept as separate as possible. I think
for almost all but the most simple tasks, one needs a GUI Builder to
generate the layout. The actions should be hooked to widgets in the current
layout and only need a minimal amount of information about which widgets
they are hooked to etc. The layout routine I have in wickel currently was
only meant to get something going fast, it's a long shot away from anything
suited for complicated tasks. As far as layout goes, there should always be
the possibility of using a GUI builder as a last resort, without the
actions having to know about that.

> For example, something like this might describe a small subset of the encaps 
> dialog box:
> 
> (or cancel
>     (begin (and (enum "Orientation:" orientation
> 		      ("Landscape" landscape)
> 	  	      ("Portrait" portrait))
> 		(file ("File to print:" file)))
> 	   ok))
> 
> This says the user must cancel or do something and then hit ok.  The
> (and...)  says that the user has to choose an orientation and a file in
> either order.  The "cancel" and "ok" would be special in the sense that
> wickel's layout knows about their purpose and puts two buttons in the
> appropriate places in the dialog.

Very nice idea. But again, I think the functionality should be completely
separated from all presentation issues; I would write your example as
(with-gui-fields (cancel ok orientation output-file)
  (or cancel
     (and orientation
	  output-file
	  ok)))

where all the gui-fields are declared to have a certain type (bool, symbol
(for orientation) or file here) and 'and' and 'or' know how to enforce a
certain result. _How_ these elements are represented on the screen should
be done separately. This way, the actions don't even have to know that the
value of orientation is gotten from two radio buttons labeled "Landscape:"
and "Portrait:". 


> ...  
> It also opens up the possibility of implementing styles in something
> other than a style guide.  Wickel's layout engine could know (or be told)
> about a number of predefined actions like "open-file", "exit", "copy",
> "paste", and "about", and a style description that implemented a style
> that's common today would put "open-file" as File/Open..., "copy" as
> Edit/Copy to Clipboard, and "about" as "Help/About".

I wasn't shooting for a full fledged layout engine ... oh well; this sounds
like something a GUI builder would have built in, since it has to have some
internal representation of the widgets. Does anybody know something about
that ? 

David