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

[Andreas Pour <pour mieterra com>]

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

Ciao,

Dre

> 
> --
> Richard Bos
> For those who have no (/)home the journey is endless

-- 
Ciao,

Andreas Pour

http://www.kde.com/ :  Everything KDE
http://apps.kde.com/:  The Latest in KDE Applications