Live data from Hacker News

Trinity Desktop Environment R14.0.9 Release Notes

wiki.trinitydesktop.org

51–56 of 56 posts

Re: Trinity Desktop Environment R14.0.9 Release Notes

#51
post #29

Earlier quoted context omitted.

I still find it extremely buggy. I've been hearing these "KDE 5 is fine now" for the past few months in comments, podcasts, blog posts, etc. Yesterday I gave in and decided to try the latest release. After logging in, KDE greeted me with a plasma crash. In the next few hours of light usage, some more crashes followed. It's working as it always has been for me, since the early days of 4. It's pretty much dead for me n…

> Yesterday I gave in and decided to try the latest release. After logging in, KDE greeted me with a plasma crash. In the next few hours of light usage, some more crashes followed. What distro? New or installed on top of something else? I have run KDE Neon since a few years ago om two (admittedly high end) laptops and it has been very smooth.

> I have run KDE Neon since a few years ago om two (admittedly high end) laptops and it has been very smooth.

I have been using always-latest KDE5 with Manjaro on a very old (Core 2 Duo, Intel graphics) laptop for some years already and it's perfect. Less than 5 crashes a year.

KDE4 would crash as soon as I attached an extra display. KDE5 also crashed often when it was immature. Now it works like a breeze. As somebody who has watched (and tried regularly) KDE since the inception of KDE3, I can say KDE has finally reached maturity (if not perfection) about 1.5 years ago.

Re: Trinity Desktop Environment R14.0.9 Release Notes

#52
post #26

I wonder why this doesn't ship on many mainstream distros.

There seems to be an irrational fear of shipping old toolkits (Qt3) Heck Ubuntu even removed Qt4 from their repos, when I wanted to run an older third party app that hadn't been updated to Qt5 yet, I had to install a PPA with Qt4.

Not shipping a large amount of complex software with few users that went officially EoL long ago and is maintained by a skeleton crew, is hardly irrational.

Re: Trinity Desktop Environment R14.0.9 Release Notes

#53
post #49

Earlier quoted context omitted.

I think that with the exception of the kernel being a layer on top of MS-DOS (but that would be comparing with Linux not with KDE), Win9x was better technically than KDE1. For example I do not think to this day there is anything tech-wise like COM with all of its related tech like OLE (which allows documents to embed objects exposed by other applications which themselves can run in 'embedded mode' to edit said embedd…

Windows 9x was a single user operating system; Linux and KDE/GNOME were and are not. Windows 9x is an absolute security nightmare, including ActiveX. Therefore, the comparison is moot (though ironically enough, X is also a security nightmare).

ActiveX is still available on Windows 10, it has nothing to do with security aside from being shoved into IE4 as a way for Microsoft to lock the web into Wintel back when Java's crossplatform-ness was seen as threatening to their desktop dominance - and thus gaining a bad name because it really wasn't designed for such a use.

ActiveX is just a standardized way to embed controls, in practice it isn't any difference than any desktop application that has support for plugins nor any less (or more) safer than that. COM in general is just a standardized form of a plugin system with a bunch of predefined interfaces (or binary protocols if you want) for applications that weren't written with each other in mind to still be able to work together and share functionality.

Re: Trinity Desktop Environment R14.0.9 Release Notes

#54

Earlier quoted context omitted.

I think that with the exception of the kernel being a layer on top of MS-DOS (but that would be comparing with Linux not with KDE), Win9x was better technically than KDE1. For example I do not think to this day there is anything tech-wise like COM with all of its related tech like OLE (which allows documents to embed objects exposed by other applications which themselves can run in 'embedded mode' to edit said embedd…

What you're describing for a "dbus but for ui" is one of the core KDE technologies still in use today named KPart [0][1]. [0] https://techbase.kde.org/Development/Tutorials/Using_KParts [1] https://en.wikipedia.org/wiki/KDE_Platform_4#KParts

Yeah i know about KParts, however KParts is more limited and the tech is only about KParts whereas COM is used for a lot of things, including even stuff unrelated to the GUI (e.g. Active Scripting). In addition COM defines a binary interface for accessing objects that can be supported by any programming language that can support structs and pointers whereas KParts is only for C++.

Re: Trinity Desktop Environment R14.0.9 Release Notes

#55
post #26

I wonder why this doesn't ship on many mainstream distros.

There seems to be an irrational fear of shipping old toolkits (Qt3) Heck Ubuntu even removed Qt4 from their repos, when I wanted to run an older third party app that hadn't been updated to Qt5 yet, I had to install a PPA with Qt4.

The Trinity folks are maintaining Qt3 as well, so that should not be an issue.

Re: Trinity Desktop Environment R14.0.9 Release Notes

#56
post #55

Earlier quoted context omitted.

There seems to be an irrational fear of shipping old toolkits (Qt3) Heck Ubuntu even removed Qt4 from their repos, when I wanted to run an older third party app that hadn't been updated to Qt5 yet, I had to install a PPA with Qt4.

The Trinity folks are maintaining Qt3 as well, so that should not be an issue.

Do other Qt3 apps run with their fork?
Post reply on HN