tde-devels

devels@trinitydesktop.org

7 participants
3840 discussions

[Fwd: Re: [trinity-users] A Memory Comparison of Light Linux Desktops]
by Timothy Pearson 19 Apr '13

19 Apr '13

Cross-post for those not subscribed to the users list... ---------------------------- Original Message ---------------------------- Subject: Re: [trinity-users] A Memory Comparison of Light Linux Desktops From: "Timothy Pearson" <kb9vqf(a)pearsoncomputing.net> Date: Thu, April 18, 2013 7:15 pm To: trinity-users(a)lists.pearsoncomputing.net -------------------------------------------------------------------------- > On Sat, 13 Apr 2013 01:54:25 +0200 > SlÃ¡vek Banko <slavek.banko(a)axis.cz> wrote: > >> Hello everyone, >> >> you might also be interested in: >> >> http://l3net.wordpress.com/2013/03/17/a-memory-comparison-of-light-linux-de… >> http://l3net.wordpress.com/2013/04/09/a-memory-comparison-of-light-linux-de… >> >> It surprised me Razor-qt. I have to say that this environment is not >> nearly as complete and comprehensive as Trinity, but memory >> consumption is staggering. That would be a consequence of using Qt4? >> The choice to remain in Trinity with Qt3 => TQt3 seems to be a very >> good decision. >> >> Slavek > > I have obtained pretty much the same test results while struggling to > find a TDE alternative(s) using a "features / resource consumption" > scale. I saw no competition between the TDE and Razor-Qt, because of the > reasons you have mentioned. As the time passes new actively developed > projects like Razor-Qt tend to grow larger, not smaller, so I assume > the gap will only widen in the future. > > It's still too early to guess, but I (wish|expect) to see E17 as a major > rival of TDE in 3-4 years from now. > > Regards, > Sergey. This discussion brings up a long-standing idea I have had. I would like to add a "Why TDE?" page to the website; this should contain a brief set of paragraphs explaining why users like yourselves have chosen to use TDE versus another desktop. Entries should not engage in bashing other desktops, but should instead highlight unique features of TDE that, singly or in unison, have swayed you to choose TDE for use in a particular setting. Thoughts on this? Thanks! Tim --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

1 0

BLFS trintiy instructions.
by l0ner 18 Apr '13

18 Apr '13

Hi. If I remember correctly there was someone who was writing instructions for BLFS book on compiling and getting to work TDE on LFS. I remember using those instructions while writing PKGBUILDs for arch, since those instructions were nicely detailed. I wanted to look at them, now that I'm trying to compile TDE on my Gentoo installation. But now they have vanished and I can't find them anywhere. Any hopes on mirrors or direct contact with the person that was writing them? l0ner

1 0

Friendly notice: Big patch push coming
by Darrell Anderson 18 Apr '13

18 Apr '13

Hi folks, I will be pushing patches to update docbook related files. The reason for the changes is to avoid potential conflicts with files of the same name in KDE4 as reported in bug report 1446. These patches affect GIT main trunk only. The core of the changes are to the common/admin directory and renaming files in tdelibs, although many modules are affected by this renaming. The changes to the common/admin files is the reason for this notice because the main servers have to replicate those changes to all other submodules. Updating your entire local GIT repository during this period could mean build failures. I tested the patches with full build runs and found no problems. All help handbooks compile and work as expected. From a user perspective nobody will notice any differences. These patches only affect compiling. I plan to push the patches after posting this message. Before updating your local repository, please allow ample time for the main servers to replicate the changes in common/admin to all modules --- usually performed overnight. After resyncing your local repository, a simple test to verify all files have updated correctly is to grep your entire local repository for kde-chunk.xsl. There are other changes too, but there should be no such occurrences because the file is being renamed to tde-chunk.xsl and all internal references as well. Please let me know here should you notice build failures or problems related to the help handbook (docbbook) files. Probably a good idea to spot check the handbooks after installing updated packages. :) Thanks! Darrell List of all affected modules: common: ------- admin base: ----- tdelibs tdebase tdevelop libraries: ---------- kipi-plugins libkdcraw libkexiv2 libkipi libksquirrel libtqt-perl applications: ------------- adept basket bibletime compizconfig-backend-kconfig digikam dolphin filelight filelight-l10n gwenview-i18n k3b-i18n kaffeine katapult kbarcode kbookreader kchmviewer kcmautostart kcpuload kdiff3 kdirstat kdpkg keep kerry kile kiosktool kmplayer kmyfirewall kmymoney knemo knetload knetstats knights knowit knutclient koffice koffice-i18n konversation kopete-otr kpicosim kpowersave kpowersave-nohal krename krusader ksplash-engine-moodin ksquirrel ksystemlog ktechlab ktorrent kuickshow kvkbd kvpnc piklab potracegui smb4k soundkonverter tde-systemsettings tdeio-apt tdeio-umountwrapper tderadio tdesudo tdmtheme tellico twin-style-crystal yakuake tde-i18n: --------- tde-i18n

1 0

Re: [trinity-devel] konqueror no file names on nightly
by Darrell Anderson 16 Apr '13

16 Apr '13

>>they work just fine > >What about dolphin? Not to use full time, just to provide more >debugging data. Try krusader too. Darrell

1 0

Re: [trinity-devel] konqueror no file names on nightly
by Darrell Anderson 16 Apr '13

16 Apr '13

>they work just fine What about dolphin? Not to use full time, just to provide more debugging data. Darrell

1 0

Re: [trinity-devel] konqueror no file names on nightly
by Darrell Anderson 16 Apr '13

16 Apr '13

On Tue, 16 Apr 2013 12:53:25 -0500 "Calvin Morrison" <mutantturkey(a)gmail.com> wrote: >Hmmm, that works correctly. How about file-picker dialogs, such as opening a file in kate? Darrell

2 1

Re: [trinity-devel] konqueror no file names on nightly
by Darrell Anderson 16 Apr '13

16 Apr '13

>I was thinking a little bit different way - for example: > >[R14 XDG Updates] >Updated=R14.0.0 > >or (maybe better - can cover also changes during development >versions and also easier for comparison in shell) > >[R14 XDG Updates] >Updated=20130407 > >Where timestamp is not date of the conversion for user, but the >internal date of r14-xdg-update script, which make conversion. Makes sense. Or use the time stamp of tdelibs/tdecore/tdeversion.h or TDE_VERSION_STRING from tdeversion.h Darrell

2 1

Re: [trinity-devel] konqueror no file names on nightly
by Darrell Anderson 16 Apr '13

16 Apr '13

>This is from the quickbuild nightly builds on quantal (might be an >issue as well) Could be. What happens when you press F4 to open konsole in the respective directory and then type the ls command? Darrell

2 1

Re: [trinity-devel] konqueror no file names on nightly
by Darrell Anderson 16 Apr '13

16 Apr '13

>> What happens in icon view? > >The icons appear, but no text. > >Also the system menu in kicker is blank, icons but no file names. Rings a bell. I checked the bug tracker and found nothing. Found nothing in the mail list archives. Who built the packages? Darrell

2 1

Re: [trinity-devel] konqueror no file names on nightly
by Darrell Anderson 16 Apr '13

16 Apr '13

>I have one small suggestion. Script r14-xdg-update writes to the >configuration key Updated. If the script could contain internal >version >number (or timestamp), it could to key Updated write this value >and then >this value use to decide whether to execute again or not. > >Such solution could cover any subsequent updates. And it would not >depend on testing the specific renamed files. What do you think? Sounds like a good idea. I never envisioned needing the script long-term, but I'm horrible at predicting the future. Hopefully by the time R15 is the main trunk in GIT we no longer need the script. Until then, perhaps we should embrace your suggestion. :) Currently we use the following: [R14 XDG Updates] Updated=true Perhaps change that to: [R14 XDG Updates] R14.0.0-Updated=true If we do that then what mechanism do we use in the script itself to track this? I'm thinking of corner cases such as a user updates from 3.5.13.1 to R14.0.2 or something like that. Corner cases always ruin parties. :) Darrell

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels