On Fri, 12 Feb 1999, Roland Krause wrote:
> Jean-Marc,
>
> On 12-Feb-99 Jean-Marc Lasgouttes wrote:
> >>>>>> "Roland" == Roland Krause <[EMAIL PROTECTED]> writes:
> >
> > Roland> All Wxwin ports are native, so speed is not an issue, afaict.
> > Roland> Code bloat is something you will get anyway, either it's your
> > Roland> own code that is becoming bloatet, which means the maintenance
> > Roland> problem is on you, or it is the toolkit code thats bloatet,
> > Roland> then the problem is on the toolkit developers.
> >
> > Another point is that what KDE and/or Gnome need is not a Qt/Gtk
> > application, but a full blown K/G application. And they want to be
> > able to use whichever nifty widget their library provides. I'm not
> > sure WxWindows provides that.
> >
>
> That is a quite dangerous path to walk on.
> I can not use any KDE application on my SGI because, although I have KDE
> compiled and installed, it is extremely slow and hogs an extreme amount of
> memory. I didnt even bother trying Gnome, because of the immaturity of the
> code.
Just because we are aiming for support of KDE *and* GNOME doesn't mean we
won't have any non-desktop specific ports. XForms will surely survive for
some time yet (hopefully to be replaced by fltk).
> O.t.h. I looked closer at the KDE enhancements to Qt at the KDE developers
> site and I can not see such a huge difference. E.g. Instead of QtApp class
> KDE uses a KApp class, allowing for a lot of nifty things, like easy storage
> and parsing of the configuration filed and such.... KDE has a lot of
> improvements
> over plain vanilla Qt but things are changing fast and development of Qt goes
> relatively fast too.
>
> Personally I do not believe in a multi toolkit approach anymore. This has
> nothing to do with LyX, so consider it somewhat off-topic, but from my
> experience :
> Toolkits are not really exchangable, because, as the state of LyX/KLyX
> clearly shows, it is the programmers that have to relearn a different toolkit
> and that is the difficulty. it cant be done on the fly no matter how
> sofisticated your interface is.
I'm not quite sure what you mean here. We may be able to support binary
distributions with multiple (separate) heads and the appropriate head put
on LyX depending upon what libraries are installed on your system but this
is something for 0.15. As for switching interface toolkit on the fly
thats a very big task and one thats unnecessary.
The beauty of being gui independent is that someone who loves LyX and
loves XXX toolkit will be able work on that toolkit and tune it and so
forth with little knowledge of the rest of LyX. Thus with luck we'll get
new developers and the rest of us can concentrate of the internals and let
someone else worry about the interfaces.
> Redoing a thing that already works is something nobody
> really volunteers to do. And the question is always, why do it in the first
> place ?
See above as a small example of why.
Additionally, the X-Windows community has moved beyond toolkit wars and
has entered the desktop wars now instead. There are plenty of people
who run KDE and expect to have KDE-aware apps running on their desktop and
I'm sure there will also be as many if not more who'll want to have
GNOME-aware apps on their desktops. Neither one is going to collapse and
switch to the other desktop. So rather than see multiple forked versions
of LyX I'm prepared to put extra time into gui-indep (when I'd rather be
playing with inset code or dynamic re/loading of layouts or layouts in
general or any of 100 other things).
The one thing we can be sure of is that if you look at Freshmeat you'll
see there are plenty of desktop specific software out there and most of
it is a fork of an existing code base. What a waste of talent and time!
Maybe I'm dreaming but it would be a wonderful thing if we can demonstrate
to the Open Source community and the computing world in general that it is
possible to have your cake and eat it too: by providing a model of how to
achieve gui-indep and avoid forked code-bases.
> Shure XForms is bad, ugly, buggy , non-free, etc. but the reason it was chosen
> in the first place was, that it gets the job done.
And Qt and Gtk never existed in those days. (0.10.7 was ugly but since
early 0.11 I've found LyX to be no uglier than most other apps I use:
granted KLyX is very pretty in comparison though).
> There is from my past experience, coming from Aegis on Apollo Domain computers,
> only one reason that has ever forced me to switch toolkits, which was that the
> old toolkit did not exist on the new platform.
Isn't that most of the problem here too?
XForms isn't KDE-aware nor GNOME-aware and every distribution is now
offering one or the other (or both) desktops. Additionally, lyx has
disappeared off the redhat powertools cd (even though they still have
xforms on it). If we want lyx on any of the distributions we're going to
have to support the stuff they support: KDE and GNOME. That doesn't
preclude support for fltk or Motif/CDE or Windows or OS/2 PM or NextStep
or anything else from being in LyX. In fact the gui-indep work could be
justified for no other reason than to make LyX independent of
X-Windows/Unix so we could finally have a native OS/2 version (or WinXX).
> Sometimes I think if just everybody would have followed Matthias and switched
> to
> Qt/KLyX in the first place, the whole LyX project could be a lot further.
Yes and no.
I think gui-indep might have been harder working from the klyx codebase
because it was already tied quite closely to kde when Matthias announced
it. Sure we would already have had multiple frames and split bufferviews
but a lot of code had been moved or replaced so the LyX developers would
have had to relearn LyX. Besides, when was the last time you heard of a
KDE app running on OS/2? Poor S. Miyata would have had even more layers
of stuff to add to his system in order to continue providing the OS/2 port
(and maybe even more reason for us to push ahead with the gui-indep work).
> Please do not misunderstand this as critique at you guys, I truly admire your
> work, it is just that I think when I read the toolkit discussions, why not
> picking one good toolkit, switching to it with full force and be done with it.
Others (including redhat workers) have suggested the same -- only they
wanted gnome only. We're caught in the middle again...
> Anyway, didnt wanna bother you but its Friday...
>
> Roland
The gui-indep work at present is quite tiring but it does serve a vital
purpose (IMO): keeping the codebase together.
Thanks for your thoughts. If anything its helped me to refocus on why I
started doing the gui-indep in the first place (apart from having fun
playing with signals/slots). With a bit of luck it might even spark a bit
of support from some of the lurkers who want to have their favourite
desktop supported to step forth and help get the groundwork completed so
they can get started on porting.
Allan. (ARRae)
