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

[Jeff Dike <jdike karaya com>]

mvo@zagadka.ping.de said:
> lutterdc@cs.purdue.edu (David Lutterkort) writes:
> So, here are some of the questions racing through my head: Would this
> be a
> useful program ?

> I think it's way cool. 

Me too.  I would have to agree with Marius' other comments, too.  It 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).

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.

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.

The program might call "(wickel-layout gimme-a-file)" where gimme-a-file is 
the description above, and get back something like
	((orientation landscape)
	 (file "print-this.ps")
	 ok)

Since this is generic wrt widgets, this would make porting to a different 
toolkit a lot cheaper.  Not free, but maybe close to it for common cases.

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".

If someone then comes up with a major UI breakthrough that involves organizing 
the menus differently, then a style description for it would be the only thing 
needed to make applications start conforming to it.

				Jeff