Re: Fwd: Re: [Setup-tool-hackers] Similar frontends?

[Martijn Klingens <mklingens yahoo com>]

On Sunday 20 May 2001 23:35, Andreas Pour wrote:
> Richard Bos wrote:
> > On Sunday 20 May 2001 23:10, you wrote:
> > > OK, I'll give into the reality that in the real world the interfaces
> > > will not be identical. However, I believe that we would be really
> > > hurting both projects if we didn't at least try. If it doesn't work,
> > > well then as before nothing is really lost. But if it does work, well
> > > then think of how much further along we will be.
> >
> > Wouldn't be possible to define the GUI in XML.  This GUI definition file
> > should be read by gnome, kde, webmin, etc.  In this case the gui file be
> > identical no matter which desktop environment is being used.
>
> Hi,
>
> I agree with the XML layout.  What I see as an ideal solution is that
> the backend has an option to spit out an XML description of each dialog,
> what actions to take when buttons are clicked (e.g., execute a script
> with these arguments, where there is a way to describe form values
> entered by the user) and what permitted values are for each form entry.
> The app can ignore this if it wants to (the information is still
> supplied).
>
> Advantages:
>   (1) less work.  The layout is done once on the backend and all
> frontends can now configure this thing.
>   (2) easier to maintain.  By downloading an arch-ind. Perl script, the
> user can configure something new.  No need to compile for all
> distributions/versions.
>   (3) easier to support.  Tech support people usu. don't see what's on
> the screen.  They want to say "go to the first line where it says XYZ
> and enter PDQ".  This is not possible if each toolkit puts a different
> look on it (well icons are OK but I'm talking about layout of the actual
> form).  If Linux is to be "supportable" by third-party tech support
> departments (like ISPs) and in-house IT departments (where a technician
> has to be certified, e.g.), this is necessary IMHO.
>
> Disadvantages:
>   (1) a bit more work when writing a Perl module.
>
> Note that the application front-end is not *forced* to use the XML, it
> would just be "strongly recommended" for reasons of "compatability" in
> the UI (not API, but UI, that's what's important for users; developers
> care about API consistency, users and tech support care about UI
> consistency).

I'm still tempted to take this one step further, but with lots of caution, 
because I got stuck when I tried this myself (about two weeks before Charles 
announced kde-sysconfig I was toying with it, but no luck as of yet).

If we can define the XML UI in such a way that it doesn't describe widgets, 
but objects we might get a new evolution in user interfaces. Just mark an 
object as string, as ip address or another well-defined object and nest these 
objects in each other. This requires a _lot_ of difficult design, but it 
would in addition to the advantages Andreas mentioned give at least the 
following advantages:

- A UI renderer that doesn't know about widgets can be used. I can think of 
(at least) a text console (set var=value), a braille reader, speech 
recognition and a scripting engine like python. In one step you'd make a UI 
that is litterally 'design once, show everywhere'. The only requirement is a 
proper renderer.

- Since all meta-data is in the XML file, it is easier to track a user's 
activities and adjust the interface accordingly (like by hiding never-used 
components)

- with a bit of additional meta-data it is possible to define groups of 
meta-objects that, when run in order, form an 'action', like, say, 'create a 
new user' or 'add a network card'. These actions can be shown as a small 
dropdown in the UI that, when activated, starts a wizard to accomplish a 
task. The advantage is that only the grouping is needed to create a wizard, 
_all_ of the code is furthermore shared. Not everyone likes wizards, not 
everyone likes dialogs, this would be a good compromise without duplicate 
work.

Disadvantages are plenty too:

- It is harder to design a UI using current tools, because e.g. the Qt 
designer doesn't output the proper format. OTOH, this problem is quite true 
for any XML format, though usually some XSLT magic can do the trick.

- It is hard to get the design right, which is why I am putting my efforts on 
another project right now. I wanted this system to be toolkit independent in 
the core and at the same time offer a proper renderer for every toolkit _and_ 
offer a proper backend interface bindings for the toolkits. In Qt the 
signal/slot mechanism is very powerful and I assume Gtk has a similar 
concept. Thus, a meta-ui that doesn't make use of these features sucks IMO 
and at the same time it cannot and should not be tied to any of these 
toolkits. What I was thinking of was an extra layer that implemented the 
interface bindings, but AFAICS that requires support for interfaces like in 
UML, IDL or Java. Plain C or C++ don't support them though, or I should toy 
with multiple inheritance.

- It is _extremely_ difficult to write, especially the start

Concluding: The advantages are incredible. They allow an app to be runnable 
with Gnome, KDE, ncurses, plain unix console, web server, scripting language, 
speech control or whatever else you can thinking of without writing any code. 
Just write a renderer and all apps that use the API can benefit from it 
immediately. The disadvantages are bad though, really bad. So I don't know.

Like I said, I was thinking of this even before kde-sysconfig started and if 
I can find a proper solution for the disadvantages (and lots of time!) I will 
work on it myself. But if this is possible at all? I can only hope so and 
dream about it right now...

Martijn