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

[Jeff Dike <jdike karaya com>]

lutterdc@cs.purdue.edu said:
>> (or cancel
>>     (begin (and (enum "Orientation:" orientation
>> 		      ("Landscape" landscape)
>> 	  	      ("Portrait" portrait))
>> 		(file ("File to print:" file)))
>> 	   ok))

> Very nice idea. But again, I think the functionality should be
> completely separated from all presentation issues;

This does separate form from function.  It does nothing but describe a set of 
information that's needed from the user.

Given that description, wickel-layout might return
        ((orientation landscape)
         (file "print-this.ps")
         ok)
which says "the user chose an orientation of landscape and the file 
"print-this.ps", and then hit ok".  The "orientation" and "file" ids were 
given as part of the description to provide tags for the information coming 
out.

The interaction of the outer program with wickel might look like (in 
pseudo-scheme):

(define gimme-a-file <the above description>)

...
(let ((print-info (wickel-layout gimme-a-file)))
  (if (is-ok print-info)
      (let ((orientation (wickel-value print-info 'orientation))
	    (file (wickel-value print-info 'file)))
	 ... print the file... )))

This makes a dialog box look a lot like a procedure call, which ties in with 
your previous comments on doing away with the death of a thousand callbacks.

I'm unsure to what extremes this could be taken.  You could imagine doing this 
with an application's top-level interface.  In this case, the application's 
main loop would call wickel to get the next user request, and then go into a 
huge switch statement to dispatch the request.  This doesn't seem all that 
modular to me, but it might be reasonable if the actual functionality were 
well modularized.

A bigger problem would be functionality which has to run before a user's 
request is completed.  This would include stuff like validating input and 
confirming requests.  It might be reasonable to put hooks in the interface 
description to allow some application callbacks to be used.

> I wasn't shooting for a full fledged layout engine ... oh well; this
> sounds like something a GUI builder would have built in,

The output of wickel could be used as the input to a builder for tuning the 
interface.  What I had in mind, though, was that there would be a 
wickel-specific tuner that would tell you what decisions were made in 
producing the proposed interface, and allow you to change them.

So, you would be able to say things like:
	"represent this choice with an option menu rather than a radio box"
	"put this particular set of information in a separate sub-dialog box
		rather than inlining it"

With a builder, you couldn't tweak the decisions like that.  You would have to 
delete the old stuff and put in the new stuff by hand.  The fact that the 
tweaker has a relatively high-level notion of what the dialog box is about 
would give it the ability to implement fairly sophisticated operations on the 
interface.

				Jeff