Trinity Desktop Environment Version 3.5.13.1 Released !
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
A few people participating in this forum created 3.5.13 packages for Slackware 13.37. Search the forum and look for links for their build scripts. I suspect those build scripts will work just fine with 3.5.13.1.
Caveat: 3.5.13.1 still uses HAL, which Slackware 14.0 no longer supports. The Trinity R14 development branch uses its own standalone hardware libraries. They work quite well, despite officially still being in development. A separate HAL package could be built for Slackware 14.0. I tinkered a bit with that and some patching is needed. Most of my Trinity R14 testing with Slackware 14.0 has been with the new Trinity hardware libraries. Of course, 3.5.13.1 will work fine with Slackware 13.1 and 13.37 that already has HAL installed.
I don't have slackbuilds for 3.5.13.1 but I have scripts for the R14.0.0 development branch:
I have been using the Trinity R14 development branch full time for about two months. As a development branch there are bugs and "paper cut" issues, but nothing I find intolerable or haven't found a work-around. Although I'm part of the testing team and could seem biased, I nonetheless offer that the R14 branch is stable. Very stable.
I have R14 installed on Slackware 13.1 32-bit (with HAL) and 14.0 64-bit (without HAL). Typically I build and install an updated package set about weekly.
Note: My build scripts are not cookie-cut from the slackbuilds.org template. I perform a lot of testing for the Trinity project and therefore my build scripts support those needs. Anybody familiar with Slackware build scripts would be able to copy the relevant parts into a slackbuilds.org build script template. As noted at my web site, my build scripts all are retooled to support the development branch and will not work to build 3.5.13.1.
HAL is deprecated, but the last version is still available and being maintained in Debian. You can build it from source and install it in Slackware, unsupported does not mean impossible.
Software on the scale of a desktop which depends on obsolete software like Qt 3 or HAL is likely to be at a dead end in a short space of time.
My system is old and crap (P4 3.4GHz, nvidia 7300GT, 1.5GB RAM) and runs KDE 4.8.5 very nicely. If you disable the nepomuk/akonadi stuff, it gives a significant performance boost to lower end machines.
For myself, a while back I tinkered with building my own HAL package for Slackware 14. The package built but I did not test in depth because my first focus was with debugging the new TDEHW libs support in Trinity R14, which is the development branch. (I'm using Trinity from GIT and not 3.5.13.1.)
Quote:
Software on the scale of a desktop which depends on obsolete software like Qt 3 or HAL is likely to be at a dead end in a short space of time.
Only if nobody supports the software. Trinity supports both HAL and its own hardware layer. The Trinity team has taken over maintenance of the free/libre version of the Qt3 libs. I'm running Trinity GIT (development branch) with no ill effects and I used KDE 3.5.10 for several years after the release, simply by applying patches for updated versions of gcc, glibc, etc. I'm not a trained coder or developer, just somebody who is determined to scratch his itch.
I'd give an eyetooth to have this Trinity on my system! I miss KDE3 terribly. I'll have to wait though for it to come out as a package of some kind...I'm no developer/programmer or anything else like that, I just like Slackware and Linux and am just a simple ol' user - on dialup! I just got my 14.0 installed and working after having used 13.37 for 8 or 9 months. If I can remember, I'll check on this project once in a while as I'm excited to hear that it's happening and doing well.
I'd give an eyetooth to have this Trinity on my system! I miss KDE3 terribly. I'll have to wait though for it to come out as a package of some kind...I'm no developer/programmer or anything else like that, I just like Slackware and Linux and am just a simple ol' user - on dialup! I just got my 14.0 installed and working after having used 13.37 for 8 or 9 months. An eyetooth? Owie!If I can remember, I'll check on this project once in a while as I'm excited to hear that it's happening and doing well.
An eyetooth? Owie!
I have a build environment package that includes build scripts and patches for Trinity GIT:
But you'll need to recreate a local GIT repo, which is 4 to 5 GB of hard drive space, which on dialup would be a painful experiment.
The build scripts support tarballs, which I make here locally, and require about 430 MB of storage space. Still a good chuck of storage space.
If you are comfortable with build scripts, possibly you could find a "bandwidth buddy" to download the GIT repo to a DVD, which you could then copy to a local hard drive. Thereafter keeping the local repo updated could be tolerable.
Typically I rebuild a fresh full package set weekly. As a development branch the software has the some expected bugs and "paper cut" issues, but I've been running GIT for a few months and am pleased. I'm using Trinity GIT on both 13.1 32-bit and 14.0 64-bit.
I'm willing to provide weekly binary packages but I need a place to upload them.
A package set with many extra Trinity app packages requires about 800 MB of space. The same package set provided in Slackware 12.2 along with a few additional packages requires about 690 MB. Because I'm supporting the development branch, this storage space includes debug packages, which do not have to be installed --- although they help create back traces to help debugging. Without the debug packages about 490 MB is needed.
It's just a tooth. The gods saw fit to give me a whole slew of them, so I have some to spare. (yeah, a cheapshot at the line in the movie 300)
Heh...half of what you're talking about goes right over my head like a jet at mach 2, lol.
As for the space, I've got 90GB on my /home partition, so I'd have the room to build....I think, and 59GB on /.
Unfortunately I don't know anyone with a fat connection. Besides...I tried to read about that chroot thing on your website, and it only confused me even more. Not sure why I should or shouldn't be comfortable with build scripts. Do you mean can I run them? Like doing 'sh <build_script>', and then waiting for it to do whatever it's supposed to do? (see what I mean by not having a clue about dev/programming stuff?).
I unfortunately don't have any place for you to upload stuff to either. I live on a piss poor disability check and by the end of each month I'm scraping the bottom of the barrel...there's just no such thing as 'saving up' in my situation, at least not after paying bills and rent and such. I did try once, quite a few years ago, to download some app I can't remember the name of. It was around 180MB +/-. That was real fun...it only took two *full* days! lol Let's just say that that's not gonna happen ever again.
Martin Graesslin has been on an anti KDE3/Trinity crusade from the beginning. He seems incapable or unwilling to exercise true freedom of choice and let the Trinity folks alone.
Linux.tar.gz wrote:
>>A Slackbuild anyone ?
>>It would be great to install it through sbopkg.
Sorry if this is off topic, but I have installed the 13.0 packages of kde3
from the 'unsupported' directory, and they seem to work fine on 14.0.
I just tried kounqueror/kpoker/kpat/kshisen though.
This blog-post-gone-wrong illustrates a factor that seems to become a nagging problem in the GNU/Linux and FOSS biosphere: perennity. My business relies solely on FOSS solutions, both on servers and desktops, and it's becoming increasingly hard - but not impossible - to choose components in a perspective of perennity.
Opting for a desktop environment like Xfce, for example, I can be sure it will still be around in five years, updated with small incremental changes and without any shocking or otherwise revolutionary changes under the hood. The same thing counts for the Slackware base, where I know changes will only be introduced when they are actually meaningful and/or necessary.
On the other hand, when I look at the release rate of a majority of big FOSS projects (no names), my head is spinning and my blood pressure goes up. I want to yell a big "STOP!" at the developers and remind them to first squash all the bugs that have been around for years sometimes before moving on to introducing new features.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.