Re: [gtk-list] Re: PROPOSAL: Automatic wrapping of CLIs with GUIs
- From: Jeff Dike <jdike karaya com>
- To: lutterdc cs purdue edu, mvo zagadka ping de
- Cc: gnome-list gnome org, gtk-list redhat com
- Subject: Re: [gtk-list] Re: PROPOSAL: Automatic wrapping of CLIs with GUIs
- Date: Tue, 16 Jun 1998 20:52:43 -0300
> firstname.lastname@example.org (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
(begin (and (enum "Orientation:" orientation
(file ("File to print:" file)))
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
The program might call "(wickel-layout gimme-a-file)" where gimme-a-file is
the description above, and get back something like
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.
] [Thread Prev