On Thu, 23 Nov 2000, Asger K. Alstrup Nielsen wrote:
> On Thu, 23 Nov 2000, Allan Rae wrote:
>
> Dear Allan,
>
> Let me try to summarize some of your points:
>
> 1) Being independent is better, since you'll potentially last longer in
> a changing environment
> 2) Different GUI frontends creates competition, and thus more innovation
> 3) Different frontends attract different developers, that might otherwise
> not be there
> 4) GUII is a better design
> 5) GUII gives better code, because it's reviewed by all front-ends
> 6) GUII makes everybody happy because everybody can choose the frontend
> they prefer, and they don't have to install libraries they don't want
> 7) Then you spent some time to explain why it's not technically restraining
> to do a GUII application.
>
> In short, you try to argue that GUII is worth it.
Actually, there's also:
8) GUII (or some separation) allows core deveopers to concentrate on the
application while others (possibly intermittent) take care of the
GUI's.
> Nobody really takes exception against your points, except for 6 and 7,
> which Matthias objected against earlier.
>
> Indirectly, you acknowledge that Matthias is right about one thing:
>
> GUII takes a long time.
Remember I said extraction of XForms dialogs could be done in week. This
has always been true but needs several developers with a week of fulltime
computing each to do it. The way Angus and I have been working this time
is to develop a solid reference port with a decent class hierarchy and
that has been part-time. Most of that work is down to Angus which is why
I'm happy to hand over the control of the XForms work to him.
As Angus has already noted the separation of the dialogs is so simple
and neat that GUII is effectively a freebie.
It's no coincidence that this is the case. Dialogs have received the most
attention of the different areas that need separation. I've said before
that Toolbars and Menubars are probably not as simple as they should be
but still haven't time to look into it. Remember, dialogs first then
fix something else? Some menubar changes have been made as a result of
Marko's porting them to Gnome. I'd expect even more changes to result
from a port to KDE as another developer, whether it be John, Matthias,
Kalle or someone else tries to use the platform that JMarc setup and
decides they have a better idea.
> The basic question then remains: Is GUII worth it?
> My personal opinion is that I don't think your arguments for GUII weigh
> enough against the claim: If GUII has dropped, you could create more value
> for the same effort.
Different value, but more of it perhaps.
> You seem sceptical that it is not possible to build a long-time
> maintainable and technical sound program without GUII. That's obviously
> not true. In fact, history can argue that the other way is more likely,
> because complexity is the main thing to avoid in a technically sound
> program. GUII spells complexity.
Not if the paradigm is simple. The dialogs are simple. The toolbars and
menubars should also be simple. The complex part with toolbars and
menubars is trying to maintain toolkit independent definitions and
squeezing that into the mould that each toolkit requires. Desktops like
KDE and GNOME and even Windows with its CUA stuff all have slight
differences in their standards. Forcing a "standard lyx" menu upon them
is probably wrong because what someone will do is define a gnome.ui file
or kde.ui defeating the idea of the common lyx menu.
We need to realize one point that Matthias made: each desktop has its own
standards and its own standard ways of configuring stuff.
FormPreferences looks wonderful in XForms but KDE provides its own config
tools and, if I understand it correctly, has its own config file format.
KLyX2 wouldn't just write lyxrc into ~/KDesktop/.../LyX/lyxrc it'd be
called something "standard" with some KDE config format.
If anything we need to realize that we can't control everything and get
GUII easily because of the possible complications involved. I totally
agree with the KISS principle. But I don't see GUII going against that
principle. It is instead an aid to improved separation as a gui porter
only ever needs to look in the src/frontends directory and
src/frontends/$PORT.
If we have to draw the GUII line a little lower for the sake of some port
then so be it. But remember each port is free to do as it pleases. The
KDE2 port could easily define its own config utility, file format etc. and
just convert that to match lyx's internal lyxrc. Nobody is going to force
a KDE2 port to use the toolbar abstraction -- it can use its own if it
likes (although getting access to TOC may be more difficult unless a
Liason function is provided to extract a suitable list on demand). The
only restrictions that really exist (at present) upon a gui port is that
it provides an implementation of Painter and Dialogs.
> And there is certainly many benefits you get by sticking to one toolkit
> that can not be achieved as easily with GUII. So you have to weigh the
> pros and cons on a weight. I think Matthias might be right that at this
> point in time, the weight is in the favour of dropping GUII if the goal is
> to achieve maximum merit for the effort.
Follow Lars' instructional email about CVS branch operations and create a
BRANCH_KLyX2 branch. Work there. Merge from the HEAD to the branch every
so often to get things in sync with LyX development (ie. Lars and Jürgen
running amok with insets). Only work within src/frontends apart from
removal of xforms specific code. Then when you're done in two weeks time
we can make KDE2 the main base and xforms can either be dropped or
continue as a secondary port (or replaced by fltk). The other ports can
also continue, although using KDE2 instead of xforms for the rest of their
dialogs and frontend.
Then when Matthias and Kalle return to their regular work and we take over
the maintenance GUII can continue.
Everybody's happy.
When you've stopped laughing think about it seriously.
The main reason xforms is the main port is because that's what the guts of
LyX is and IMO it makes sense to keep the same GUI toolkit as the main
target until such time as all the gui-specific code is out of the core.
So who wants to do the work of rapidly switching default toolkit? But
must remain with the bounds of the Dialogs GUII work and mustn't change
anything other than gui-specific code in the core of lyx.
> But you can only do this in practice if the developers agree, because
> otherwise you loose the developers that have to make the effort.
>
> Therefore it is relevant informally to ask all the developers:
>
> Would you be still be enthusiastic to participate in LyX development if
> GUII was dropped and focus was on Qt as the main toolkit?
Probably not. GUII is the last great frontier IMHO. LyX does everything
else I need it to.
Allan. (ARRae)
