Re: XML front-end ideas

[David Joham <djoham criadvantage com>]

I'm still not convinced that using an XML GUI description is a good idea.
Here are my concerns:

If we go back to the server for *every* GUI action, the user experience for
the client will not be very robust. Say I want to add a couple of DNS
servers to my system. This action could take the following steps:

1) click new
2) Add the IP and click save
3) click apply
4) click new
5) Add the IP and click save
6) click apply

This simple action will require 6 round trips to the server. In between each
of those round trips the GUI needs to be completely torn down a rebuilt.
This is going to cause flickering and a wait that our users will hate. Also,
this is one of the simpler GUIs that I can imagine. Can you imagine trying
to configure Apache?

I'm also concerned that we would need to implement a rather complex and rich
XML GUI description in order to make the user experience pleasurable. This
would include layout management, i18n, l10n and a host of widgets and
actions. This is going to be hugely complex. I looked at the DTD that you
linked to and it's a good start, but its not there yet. Plus, not only would
we need to do the definition of the XML, we would then have to implement the
XML GUI in each and every GUI toolkit we wanted to provide. This is a
non-trivial task and considerably raises the bar in who can help with this
project. 

We also need to take into account the fact that the Ximian guys already have
their GUI. An XML GUI would basically be asking them to drop all of the work
they've already done to this point and start over. If they're not willing
(and I don't know if I was in their place I would be) the idea of an XML-GUI
for just one toolkit (and maybe curses) really looses its attractiveness...

I contend that if we attempt to do something of an XML GUI that we ditch XML
entirely and go with an HTML rendering solution. In this case, the parsing
is written for us (Konqueror/Mozilla/Galeon) and the code that we write
(JavaScript) will be cross platform as well. However, this still leaves us
with a rather un-optimized client solution and a severely restricted widget
set.

I actually don't see what's wrong with writing the GUIs in their native
tools. I can whip up a good GUI in QT designer in a jiffy. The same goes
(I'm sure) for GLADE. In this case, I have a rich widget set I can use that
has already taken into account all of the items in the paragraphs above. The
only widget limitation would be to ensure that we use QT and GTK widgets
that have similar functionality so that consistency is preserved. Yes, we're
writing the code twice. But so what? We use *nix. I personally would have
preferred that the GTK and QT folks would have gone out back and solved the
problem of multiple widget toolkits with a six paces, turn and shoot
approach. The winner would be the toolkit we would all write to, for better
or worse. That not being the case, we live with reinventing the wheel to our
preferred look and feel.

Another issue that I have is separation of talents. I don't know Perl. I
don't want to know Perl. However, with the XML GUI idea, the GUI is going to
be defined in Perl scripts by (shudder) Perl hackers. The same Perl hackers
who generally consider the GUI a secondary piece of this application. I can
see many problems in the future with situations like this:

GUI_GUY: Hello PERL_HAXOR, I have a problem with this GUI not working.
PERL_HAXOR: That's nice. Come back next week when I'm finished getting
OBSCURE_XYZ_DISTRO working
GUI_GUY: But I just need you to fix one simple thing
PERL_HAXOR: I will, but later. Or you could fix it yourself
GUI_GUY: OK, I'll ping you next week.
PERL_HAXOR: Don't ping me, I'll ping you...

The moral of the story here is that there are many different talents here.
Mine happen to lie in the GUI world. I personally don't care too much about
the Perl scripts as long as they work, but if the GUI looks bad, I believe
the whole project looks bad. We need to ensure that the people who feel the
way I do can contribute to the code, or we'll end up with another LinuxConf.
Also, with a proper division of talents, each person will be working on the
section of the code they deem most important. This would further encourage
quality from both the front end and the back end. 

The last issue that I have is time. I want to ship this project at some
point in the future. I contend that the XML GUI will take considerably
longer in the near term. We'll have to design the protocol, implement the
parsers and figure out how to do this from scratch. A standard UI will allow
for a much faster time to market. In the long run, it may take more
cumulative time, but we'll also have the luxury of having more GUI designers
capable of working with the code. I believe that will more than offset the
added time of writing the interface for each toolkit.

I guess the primary issue I have with the XML GUI lies in the fact that I
want a rich, non hacked-up GUI for this project. The Mozilla project has
been universally criticized for doing their own widgets and not just
building a renderer that other widget sets can use. In fact, people dislike
the way Mozilla does things so much they've created the native wrappers
anyway. Look at Galeon, QMellon and the like. Now I know we won't have our
own widgets, but if we proceed down the XML GUI path we will basically be
making the same design decisions as the Mozilla team. I don't think our
users will approve.


Best regards,

David