tde-devels

devels@trinitydesktop.org

6 participants
3856 discussions

Merry Christmas and a Happy New Year!
by Calvin Morrison 25 Dec '11

25 Dec '11

Greetings All, Almost a year ago, January 31st exactly, I first emailed Timothy Pearson about helping out with Trinity. I wanted to create an improved website and start contributing. Soon I found that I was I could. This has manifested itself in fixing up some bugs, getting trinity on arch, working on the website, planning meetings - everything here and there and in between. Oh my how a year passes. I proudly announce whenever the topic arises that I help contribute and develop the traditional desktop. I am so very proud of everyone involved. For a small development team and limited resources, I think everyone is doing an amazing job. We have a dedicated user base that is growing everyday. Trinity is well on it's way to becoming a Linux household name. Looking back at this year we had some bumps in the road. The release of 3.5.13 was originally scheduled for the first half of the year. Then in June we had a 2 week outage of Tim's servers. We Had a bit of a bumpy (yet successful!) release of 3.5.13 with some mirror problems and we've had to fend off various folks as well as keep the masses calm. But we also release a great product. Trinity Desktop 3.5.13. What a release! It has paved the way for great things to come. We closed a whole host of bugs, and finally have packages available for all of the major distributions, thanks to our dedicated packages. Beta ARM support and other awesome technical feats by timothy have never failed to impress me. The 3.5.13 release has set us up to put out an even better R14 release, and looking into the next year I foresee greatness! Trinity rising triumphantly out of the ashes of the Linux desktop world, soldering in tablet interfaces and lack of configuration. Like a phoenix out of the ashes! ;) But seriously, thank you so much to everyone who has contributed! Thank you to Baho and L0ner, my newly found archlinux packages. To Darrell the unrelenting bug reporter, who has helped us work though many an issue. To Laurent who has provided technical help many a time on the lists. To Robert Xu, my good friend and ally, who has helped lament a season of Chemistry and Physics induced headaches. To David Hare, Kate Draven and Dr Nikolaus Klepp who have helped end users needs by answering repeatedly on the trinity-users mailing list. Thank you to everyone I haven't mentioned, there are simply to many. Most of all I want to pitch my undying support for our tireless leader, Timothy Pearson. His work on Trinity has enabled all of us to come together and move forward. He has guided us through 3 successful releases and will lead us to many more. Tim is an excellent computer programmer and also a amazingly calm and reserved gentleman. Hats of to Tim and a round of applause! I am so excited for R14, and I'm really excited in the direction we are heading, let's make Trinity the best it can be. A Merry Christmas and a Happy New Year, Calvin Morrison

3 2

Building kdeadmin
by Bruce Dubbs 24 Dec '11

24 Dec '11

I've been struggling a bit with building kdeadmin-3.5.13. First the instructions on the HowToBuild page are a bit confusing: 1. Regenerate Autoconf/Automake files cp -Rp <path to your system's libtool.m4 file> admin/libtool.m4.in cp -Rp <path to your system's ltmain.sh file> admin/ltmain.sh make -f admin/Makefile.common Why the -R in the cp command? -R, -r, --recursive all mean the same thing, but are not really meaningful if the source is a file and not a directory. I'm not sure the permissions are meaningful either. I'd just use --verbose. 2. Configure and Build ./configure --prefix=${PREFIX} --sysconfdir=${SYSCONFDIR} \ --libdir=${LIBDIR} make This is where I get into problems. I have qt in /opt/qt and Trinity base in /opt/trinity. Configure fails to find tqt and then thinks it's version 4. It doesn't find qt and fails. This can be overcome with: CPPFLAGS='-I/opt/trinity/include/tqt' \ ./configure --prefix=/opt/trinity ... The --with-qt-includes option does not solve the problem, but the CPPFLAGS can be either before or after ./configure. Environment variables are: PATH=/opt/trinity/bin:/usr/local/bin:/bin:/usr/bin:\ /opt/texlive/2011/bin/x86_64-linux:\ /opt/llvm/bin:/opt/qt/bin:/opt/xorg/bin:/sbin:/usr/sbin PKG_CONFIG_PATH=:/opt/trinity/lib/pkgconfig:\ /usr/local/lib/pkgconfig:\ /opt/qt/lib/pkgconfig:\ /opt/xorg/lib/pkgconfig:\ /opt/xorg/share/pkgconfig QTDIR=/opt/qt Then the make fails in several places. What I finally found that works is: make LDFLAGS='-lqt -lkdecore' \ TQTDCOPIDL=dcopidl2cpp \ TQTDCOPIDL2CPP=dcopidl2cpp This again tells me that configure didn't do it's job. In the Makefile, both TQTDCOPIDL and TQTDCOPIDL2CPP are blank. The LIB_KDECORE variable is set correctly but is not used. LIBTQT_LDFLAGS is set to -ltqt, but that doesn't do the job. There are two programs in /opt/trinity/bin: dcopidl2cpp-tqt and dcopidl-tqt, but they do not work with the input in the Makefile. I did not have any of these problems in KDE3. Is there something I'm missing here? -- Bruce

5 13

Trinity 3.5.13 build for Arch linux
by Baho Utot 24 Dec '11

24 Dec '11

FYI Here is an updated status on my progress on building TDE for the Arch liubx distro. I am going to place all the pkgbuild files into a git repository. I will be starting on some of the apps shortly. Is there a place on the trinity website where the 3.5.13 indivual source tarballs are stored? I need this so I can place the url into the build scripts so that the package management system that builds source on arch linux can download by package as needed. qt3 - complete 2011-12-22 tqtinterface - complete 2011-12-22 arts - complete 2011-12-22 dbus-tqt - complete 2011-12-22 dbus-1-tqt - complete 2011-12-22 kdelibs - complete 2011-12-22 kdebase - complete 2011-12-22 kdebindings - not needed kdeaccessibility- complete 2011-12-23 kdeutils - complete 2011-12-23 kdemultimedia - complete 2011-12-23 kdenetwork - barfed kdeadmin - complete 2011-12-23 kdeartwork - complete 2011-12-23 kdegames - complete 2011-12-23 kdetoys - complete 2011-12-23 kdeedu - complete 2011-12-23 kdegraphics - barfed kdevelop - complete 2011-12-23 kdeaddons - complete 2011-12-23 kdewebdev - kdepim - complete 2011-12-23 kdesdk - complete 2011-12-23 Thanks

5 31

tdelibs git repo error
by Baho Utot 24 Dec '11

24 Dec '11

git clone http://scm.trinitydesktop.org/scm/git/tdelibs pushd tdelibs git submodule init git submodule update git checkout v3.5.13 popd Results in the following errors Submodule path 'libltdl': checked out '6d6796c294ca6e9b7f83c295217817c4bf486031' error: The following untracked working tree files would be overwritten by checkout: libltdl/CMakeLists.txt libltdl/COPYING.LIB libltdl/Makefile.am libltdl/README libltdl/ltdl.c libltdl/ltdl.h libltdl/ltdl.m4 libltdl/ltdl_win.c libltdl/ltdl_win.h Please move or remove them before you can switch branches.

1 0

Missing files
by Baho Utot 24 Dec '11

24 Dec '11

For git v3.5.13 repo I know that the git repo is not ready for prime time but the cmake subdirectories are missing in tqtinterface and the dbus packages If you pull from git those are missing but they are there in the tarballs

2 3

Slow TDE Exit Time
by Darrell Anderson 24 Dec '11

24 Dec '11

I notice that 3.5.13 takes a long time to exit. Normally I login from the command line and start X with the startx script. On my 2.3 GHz dual core system with 4GB of RAM and SATA II hard drives, TDE takes about 7 to 8 seconds to exit and more than once I have seen the system take up to 15 to 17 seconds to return to the command line. I do not have sessions enabled, logoff confirmation is disabled, I don't use eye candy, apps are already closed, etc. My virtual machine takes about 7 to 8 seconds to exit to the command line. On a 350 MHz PII system with 448 MB of RAM and ATA-2 IDE hard drives, exit time is about 16 seconds. I expect longer times but not that much. Yes, a PII is not a speed demon by any modern standard, and such a system pushes the envelope of "old hardware," but if TDE is targeted for older hardware then the long exit time is not a good marketing point, especially on a dual core system. The dual core system uses the proprietary Nvidia drivers. The PII uses the tdfx driver and a first generation AGP card. For the record, 3.5.10 never was a speed demon at exiting either. I just expect more from TDE. :) There is an enhancement request to provide an option to disable displaying the "Saving your settings" dialog box, but even if implemented, I doubt the dialog box is responsible for the long exit delay. What could be the cause? Is anybody else experiencing a long exit delay? Darrell

4 15

Kdesu and $PATH
by Darrell Anderson 24 Dec '11

24 Dec '11

I ran into a stubborn twist. On a couple of test machines I have both 3.5.10 and 3.5.13 installed. 3.5.10 is installed to /usr and 3.5.13 is installed to /opt/trinity. This kind of setup would be similar to having KDE4 installed too. That is, this problem will be seen in those environments too. I have /etc/profile.d scripts add /opt/trinity/bin to the beginning of the $PATH variable and startkde checks for that too. All is well until using kdesu. Kdesu acts like su rather than su -. Root therefore inherits the system default $PATH, which for root is quite limited and does not include /opt/trinity/bin. Nor are any /etc/profile.d scripts sourced because kdesu is not performing a simulated login like su -. Therefore /usr/bin is first in the system $PATH for root and/opt/trinity/bin is not in that search path at all. The 3.5.10 version of kate gets opened. The same thing will happen with KDE4. I can overcome the problem by typing the full path of the app and adjusting shortcuts accordingly. For example, kdesu /opt/trinity/bin/kate. Doable but inconvenient. Is there something obvious I am missing to get kdesu to inherit /opt/trinity/bin as the first directory in $PATH? Darrell

1 0

Donations
by Darrell Anderson 23 Dec '11

23 Dec '11

Is there a way to donate funds to the project other than paypal? Darrell

2 3

Suggestion to drop [t|k]win from Trinity and replace it by KWin4
by Martin Gräßlin 23 Dec '11

23 Dec '11

Hi Trinity developers, first of all: this is a serious suggestion and no try to troll you or anything in that area. Today I did some bug triaging for old bugs reported against KWin. With old I mean bugs reported against KDE 3.1 till 3.5. While I did that I realized how many bugs we fixed in the window manager after the release of KDE 4. All of those bugs are still valid for KDE 3.5 and your users do not benefit from the fixes done by us. The last commit done to KWin 3.5 was on October 3rd 2008[1]. Since then we fixed 617 bugs[2] and implemented 119 user wishes[3]. Just think about theses numbers. All those fixes your users are missing... I also just did a short count on our commits and only last month we had more than 50 commits, although we entered feature freeze. You see KWin is an active, maintained and developed project. Some weeks ago I heard that Krita developers requested a different name for the fork in Trinity, so I did the same for the fork of KWin. Reason was that I had looked at some commits done to the fork some time ago and considered them all in the area from plain wrong to harmful. I just wanted to make clear that we as upstream developers do not have anything to do with the development of this product especially as none of the patches were presented for review (all changes to KWin are peer reviewed). I had been thinking about the Trinity/KWin relationship for quite some time and todays triaging showed me that this just does not make sense. I do understand that you want to provide a KDE 3.5 desktop experience. This is great and I am all for it. But KWin 4 is a clear continuation of KWin 3. It is not a rewrite like other parts of the desktop. It is the same application, with more features, less bugs and in general a better performance. I am only aware of one feature that got dropped from KWin 4 and this could be easily maintained in a separate branch. Working on a window manager and compositor comes with great responsibility. It is one of the most complex parts of the desktop environment and introduced bugs affect all users and can be really harmful and very difficult to debug. Developing a window manager is not trivial and you have to understand how the window manager works, which - with all respect - is not the case in twin[4,5]. This is not surprising - it took me more than two years to learn KWin and there are still many areas where I am glad to have a team which can review suggested changes. Therefore I suggest to you to discontinue the work on twin and instead switch to KWin 4 as provided, developed and maintained by the KDE community. We are currently the window manager to three different desktop environments ranging from mobile to desktop. I am sure that we can support a fourth one which used to be the only one some time ago. For Trinity this gives about 60 kSLOC less code to maintain and develop. It removes one of the most complex parts and gives you the possibility to work on what really matters: providing a KDE 3.5 desktop experience by maintaining and improving kicker and kdesktop. Kind Regards Martin Gräßlin KWin maintainer [1] http://websvn.kde.org/?view=revision&revision=867241 [2] https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allw… [3] https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allw… [4] http://git.trinitydesktop.org/cgit/tdebase/commit/kwin?id=1f40ada72d693d681… [5] http://git.trinitydesktop.org/cgit/tdebase/commit/kwin?id=9cc1e2c1aa2629d49…

11 37

Interesting comment in passing about TDE
by Darrell Anderson 23 Dec '11

23 Dec '11

http://www.dedoimedo.com/computers/linux-mint-mate.html Last paragraph: "And this is exactly the one chance MATE has to make it big or become a collector's item, like Trinity." The author's remark is in reference to his own review some time ago: http://www.dedoimedo.com/computers/trinity-kde.html 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