If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Trinity Does New Release To Let KDE 3.5 Live Om

Phoronix: Trinity Does New Release To Let KDE 3.5 Live Om

While KDE 4.0 has been around for nearly four years (and most complaints regarding the initial KDE4 fallout have been addressed) and the last KDE 3.5 stable snapshot (v3.5.10) came three years ago, the Trinity Desktop Environment has issued an official release today to keep the KDE 3.5 desktop living...

I don't understand why anyone would prefer Qt 3.x over Qt 4.x. If they want to maintain the features, L&F and functionality of legacy KDE3, that's fine, but they should at least upgrade the code to use Qt4.

AFAIK, "KDE4" is not only based on Qt4, but it completely redesigned its internals, its APIs, etc... it was basically a rewrite, with a re-designing of all the features too.

It may be possible to do a "straight port" of KDE 3.x to Qt4, maintaining as much functionality as possible. It'd be like making Gnome2 run on GTK3/GLIb3, although with Qt4 the transition will be slightly rougher because of the even bigger changes in Qt between versions 3 and 4.

Anyway, I don't think it makes sense to have your entire development library (with extremely useful things like collections, networking, etc) stuck on Qt3, when the future of Qt is clearly with Qt4.

I think that Trinity is more than welcome to focus on maintaining the look/feel/functionality of KDE3 and its applications, but I think it is a very bad idea to rely on the probably-not-really-maintained Qt3, because of all the potential for bitrot, security bugs, failure to compile on modern systems, etc. And the bitrot problems will only get worse, if the Trinity project does not become a major contributor to Qt3 to bring it up to the high standards set by Qt4. But if they're going to do that, then they may as well just use Qt4 directly anyway.

Imagine your favorite KDE3/Qt3 app. Now imagine it working exactly the same way, with the same features, but with Qt4 beneath it. Sound nice? Yeah.

I don't understand why anyone would prefer Qt 3.x over Qt 4.x. If they want to maintain the features, L&F and functionality of legacy KDE3, that's fine, but they should at least upgrade the code to use Qt4.

On their website they claim Qt4 is too buggy.

Anyway, I don't think it makes sense to have your entire development library (with extremely useful things like collections, networking, etc) stuck on Qt3, when the future of Qt is clearly with Qt4.

Qt5 actually.

I think that Trinity is more than welcome to focus on maintaining the look/feel/functionality of KDE3 and its applications, but I think it is a very bad idea to rely on the probably-not-really-maintained Qt3, because of all the potential for bitrot, security bugs, failure to compile on modern systems, etc. And the bitrot problems will only get worse, if the Trinity project does not become a major contributor to Qt3 to bring it up to the high standards set by Qt4.

One of the developers said they were in the process of eventually moving to Qt4. They're creating some kind of compatibility layer that will let them port more easily over multiple Qt versions, it's just not ready yet.

Porting to Qt4 is not as easy as it apears at first.
Even if you use just the Qt3Support classes you could open a can of worms in some cases.

But let's look at a purposefully easy example: Porting QStringList to QStringList.
QStringList was a QValueList in Qt3, that is a linked list.
In Qt4 QStringList is a QList.

Now what is different? The iterator handling. QList's iterator handling is similar to that of a vector.

Originally Posted by qt3 QValueList docs

If some member of the list is removed, only iterators pointing to the removed member become invalid. Inserting into the list does not invalidate any iterator.

Originally Posted by qt4 QList::iterator docs

However, be aware that any non-const function call performed on the QList will render all existing iterators undefined.

The later is most likely a little excessive and not true for all non-const functions.

In any case this means that you have to look at every occurance of QStringList, QValueList, QPtrList and friends that no iterators are used a way that could be unsafe with QList _or_ create your own QStringList, QValueList, QPtrList that derive of QLinkedList and provide the [] operator, at etc.

As you can see, something that looked quite easy at first is not that easy at all. And this is just the start.

AFAIK, "KDE4" is not only based on Qt4, but it completely redesigned its internals, its APIs, etc... it was basically a rewrite, with a re-designing of all the features too.

You need to separate libraries from applications. Yes, the workspace (plasma) and a number of applications were rewritten. But many of the underlying KDE libraries are very similar, if not exactly the same. Not all, but quite a few.

Originally Posted by allquixotic

It may be possible to do a "straight port" of KDE 3.x to Qt4, maintaining as much functionality as possible. It'd be like making Gnome2 run on GTK3/GLIb3, although with Qt4 the transition will be slightly rougher because of the even bigger changes in Qt between versions 3 and 4.

It would be even easier just to implement the missing features in KDE SC 4 and port missing applications to KDE SC 4. There would be a lot less for them to do that way (only need to do the bits that they need rather than the whole thing). As it stands they have a fairly small development community trying to maintain both Qt and KDE, not to mention keep it up to date with changing technologly (udev now, probably wayland down the road).

I'm still using an old version of Xorg to go with my old Catalyst drivers that ATI discontinued.. The catalyst drivers still perform 30% better across the board than the latest gallium drivers even though the Catalyst drivers are ancient..

Wish Trinity made a release for Debian Lenny, but I can understand why they didn't. I think they're mainly looking at running old versions of KDE on newer distros, which I'm not all that interested in as KDE 4.7 is actually pretty good and I would run that if I wasn't stuck on old Xorg to get max performance & battery life on old hardware using discontinued Catalyst drivers.