Trinity Desktop R14.0.11 Released For Continuing To Improve Upon KDE 3.5

[Berniyh]

Trinity will only have a future if they do like MATE and update to the latest possible Qt.

It took KDE about 10 years to migrate away from Qt3 completely (meaning getting rid of qt3support). It's a huge task and they have much more manpower than Trinity.

No, Trinity is – and always was – a dead end. There no point in investing time in it.
If you don't like current KDE stuff, look for some other DE that suits you. There are so many to choose from.

Could add that quote about the dead horse and stuff …

[Berniyh]

Is Trinity DE much lighter on resources than Plasma 5.23?
Does it use less cpu and memory?
I find plasma to run very well on the older computers i have at hand but this maybe is for computers that is 20yr old or so.

Why is memory still such a big deal? We're not talking embedded devices here. 8GB+ is absolute standard these days and was since about 10 years ago.

And cpu … hard to tell, hard to measure (for proper comparison). But since Trinity uses the CPU to render the desktop instead of the GPU, it's very likely that it'll consume more CPU than Plasma.

[Vistaus]

What made KDE 3 great was the synergy of KWin + Konqueror + KIOSlaves.

I'm fine with Trinity being based on the QT3 UI library, so long as they recognise that at some point they will need to port QT3 to modern APIs.

KHTML has been dead in the water for a decade and a half, so Konqueror can't render most of the Internet any more. ie it is at a Firefox 2.0 level of compatibility. "TDEHTML" is a branded euphemism for KHTML. The $2000 2012 project to migrate to WebKit... well yes there was a WebKit plugin for Konqueror (not even done by Trinity Devs) but it hasn't been maintained, so we're back to (cough) "TDEHTML". Let's be fair to them. It's ostensibly better than IE6.

The KIOSlaves need to be updated to support modern TLS. ie I can't open many remotes in the file manager because of a lack of cypher support. KIOSlaves support at best TLS 1.3 with ECDHE-RSA/AES256.

Relying on XWayland as a shim in order to keep using QT3 for its lightweight resource usage, is self-defeating.

They have extended Qt 3 with newer API's already.

Also, how exatcly is Konqueror dead? It now uses QtWebEngine and it sees frequent commits.

Edit: oh wait, you were talking about Konqueror on Trinity. Yes, it should be replaced, however, you can install any browser you want. Even Falkon, which uses Qt 5.

[Vistaus]

It took KDE about 10 years to migrate away from Qt3 completely (meaning getting rid of qt3support). It's a huge task and they have much more manpower than Trinity.

Why would they need to move anyway? They extended Qt 3 with newer API's, so they're supporting it quite well.

[Vistaus]

I like this project a lot. The programmer is even considering integrating the gtk2 thumbnail patch to it.

Nice, but Phoronixers will not like it as they think you can't maintain such a project by yourself, which is also what they're saying about Trinity's Qt 3 fork. Hell, even with more people onboard, like that Qt 4 or 5 fork, Phoronixers still don't trust it.

[Berniyh]

Why would they need to move anyway? They extended Qt 3 with newer API's, so they're supporting it quite well.

Qt3 and KDE3 are each a big bunch of code. They haven't gotten enough manpower to support either and surely not to support both (at a good level).
Even KDE (and they have much more manpower) wouldn't be able to take on the additional burden of Qt3/4/5 without help.

This was already pointed out by other people listing a big bunch of known bugs and vulnerabilities which were known to not be fixed in Trinity.
Known, because they were fixed in KDE4/Plasma 5 or Qt4/5 already. In some cases the Trinity devs were even pointed to these and nothing happened.
Basically what they are doing is just retro code masturbation …

[aht0]

It'd be nice to have on FreeBSD. KHTML is probably bypassable by using Firefox or Chromium..

But if they are hostile to BSD's then fuck them..

[kylew77]

Why is memory still such a big deal? We're not talking embedded devices here. 8GB+ is absolute standard these days and was since about 10 years ago.

And cpu … hard to tell, hard to measure (for proper comparison). But since Trinity uses the CPU to render the desktop instead of the GPU, it's very likely that it'll consume more CPU than Plasma.

I wish computers all came with 8GB of RAM, all the desktops I build get 8GB but what about laptops that can't be upgraded because of sodered in RAM. My Chromebook is stuck at 4GB of RAM forever!

[Berniyh]

I wish computers all came with 8GB of RAM, all the desktops I build get 8GB but what about laptops that can't be upgraded because of sodered in RAM. My Chromebook is stuck at 4GB of RAM forever!

Ok, that sucks, but I'm not sure if Trinity is the solution then, if you additionally have to use Falkon or Firefox as a webbrowser, which then means that you just load more libraries than necessary.
In such a case it might be more effective to use Plasma or LXQt in combination with Falkon and get effectively lower RAM consumption.
Or similar combinations on top of gtk+.

[schmalzler]

Ok, that sucks, but I'm not sure if Trinity is the solution then, if you additionally have to use Falkon or Firefox as a webbrowser, which then means that you just load more libraries than necessary.
In such a case it might be more effective to use Plasma or LXQt in combination with Falkon and get effectively lower RAM consumption.
Or similar combinations on top of gtk+.

WebEngine is so memory consuming, you won't see a big difference when using falkon or chrome.
I actually used Brave-browser with plasma5 on a laptop with 4GB Memory. Went fine (if I didn't open dozens of tabs).
Text editing, libreoffice etc went without issues. Even some programming (if I didn't get too excited with C++ metaprogramming).
In the end it just started to fail on too many ends (keyboard, trackpad, USB port) that I needed something new - now happy with 16GB on a ryzen 4650G And plasma5 is running as fine as always.