tde-devels

devels@trinitydesktop.org

8 participants
3849 discussions

Bugs, bugs, bugs
by Darrell Anderson 07 Mar '11

07 Mar '11

When are bugs going to receive attention? I don't eat my own dog food. Despite some enhancements, I continue using KDE 3.5.10 rather than Trinity 3.5.12. I expended a lot of energy last autumn packaging Trinity 3.5.12 for Slackware 12.2. My personal schedule prevented further packaging efforts, but now that I again have some time, I am not motivated to package for recent releases. Why? There are many usability bugs that render Trinity frustrating. Many of which do not exist in KDE 3.5.10. I filed bug reports for all of the problems after discussing them in this list. Not a single bug I filed in the bugzilla has been touched. I don't know C++ and that frustrates me because I can't fix the problems. Some of the bugs in Trinity are carry overs from KDE3 and have existed a long time. Consider the bug of using kdeconfig as root user. Every time root uses kdeconfig, the applet creates a .kde folder in the system root directory. I have to add special lines to my rc.local to check and delete that directory. Could I use Trinity despite all the usability bugs I reported? I could but I won't. For example, the kdesu bugs I reported leave me quite frustrated. I use kdesu many times each day and that tool works as expected in KDE 3.5.10. A primary reason cited by many people for liking KDE3 is the desktop is highly configurable yet simple. No cruft like KDE4. People do not have to run a sqlite database in the background just to check email. People running KDE3 are not interested in a social or semantic desktop. Reading reviews and comments indicate overwhelmingly that many users detest Nepomuk, Strigi, and Akonadi. KDE3 is far more configurable than Xfce or LXDE without the cruft of KDE4. KDE3 can be run on more older hardware than KDE4 can ever hope. In other words, KDE3 is already a good desktop. Hence the dismay by many with the utter abandonment by the developers. Trinity brought hope to such users. Many users of Trinity and KDE 3.5.10 do not want additional bling. They want a highly configurable yet stable desktop. In other words, the immediate focus should be bug quashing. I appreciate the effort to move to a more modern build environment with cmake and interoperability with QT4. Those are good long-term goals and should continue, but I suspect those efforts have little to nothing to do with the immediacy of swatting bugs. Usability bugs are solved at the code level and not the build level. If the reason for not quashing bugs is a lack of C++ coders, then Trinity is doomed right now. My Slackware 12.2 system remains usable. Yet as time moves forward I cannot install or update certain packages because of the typical but awful lack of backwards compatibility found in free/libre software. Therefore I am facing the unpleasant decision of updating to a more recent release of Slackware. That means moving to a different desktop environment. I don't relish that decision, which is why I supported Trinity. With the lack of bug quashing my enthusiasm for Trinity has diminished. Time for the rubber to meet the road. I am studying KDE4 and preparing for a possible migration. I would rather support Trinity but I have to face reality. So do all end-users who might prefer Trinity. Packages must be readily available for end users. Other than Debian/(K)Ubuntu and Slackware 12.2, no other systems are listed as being supported. Such a short list supports the idea that Trinity is a niche product. With the release of KDE 4.5.x series, and now 4.6, some people have written that KDE4 is ready for serious usage and has surpassed KDE3 in quality. Doesn't matter whether the proclamations are true or tainted --- the typical end-user believes the statements. Regrettably, such proclamations relegate Trinity to the status of niche product and the majority of users are not going to follow. Therefore any hopes of wide scale Trinity usage is fighting windmills. The only hope for Trinity is to provide a superb product for those who choose Trinity. Long-scale survival efforts such as with cmake and QT4 support are noble efforts but does nothing to push Trinity now. End-users don't care how packages are built. They only want to download and install packages. End users have to ask themselves a basic question: is Trinity a viable choice for desktop environments? Being stable and bug-free goes a long way toward spawning interest in Trinity. As KDE4 increases in popularity and pushes Trinity further into niche product status, people will use Trinity because they do not want the massive cruft of KDE4 or the limited flexibility of Xfce and LXDE. Yet if Trinity is buggy then willingness to use Trinity disintegrates. That is now my unfortunate position. I'm willing to support this project and have proven as much in the past. Many of the build issues that were fixed to allow building on a non-Kubuntu system were a result of my testing last summer. For many weeks last summer I think Tim and I were the only ones actively working with Trinity. I single-handedly created packages for Slackware 12.2. I can continue adding value in that respect, but I can't fix bugs without a healthy understanding of C++ and the overall desktop environment. Obtaining that level of knowledge and expertise requires many months of study. I likely have stirred a hornet's nest with these comments. Yet so many bugs remaining untouched is a troubling sign. I am willing to try to package Trinity for the next Slackware release, but not until many bugs are quashed. The Ubuntu people had a project called 100 Paper Cuts. I plea for the Trinity 101 Paper Cuts Project. Darrell

5 26

Re: [trinity-devel] Bugs, bugs, bugs
by Calvin Morrison 07 Mar '11

07 Mar '11

Darrell, Your call to arms is quite convincing. A bug squashing day is in order. Currently there are alot of small problems that can be resolved easily. What is the problem? Lack of developers. Cmake migration is a seperate team so that is not impeding our efforts, a lack of C++ devels is. Sorry for a breif response, typing on a phone is difficult. Calvin Morrison Darrell Anderson <humanreadable(a)yahoo.com> wrote: >When are bugs going to receive attention? > >I don't eat my own dog food. Despite some enhancements, I continue using KDE 3.5.10 rather than Trinity 3.5.12. > >I expended a lot of energy last autumn packaging Trinity 3.5.12 for Slackware 12.2. My personal schedule prevented further packaging efforts, but now that I again have some time, I am not motivated to package for recent releases. Why? There are many usability bugs that render Trinity frustrating. Many of which do not exist in KDE 3.5.10. > >I filed bug reports for all of the problems after discussing them in this list. Not a single bug I filed in the bugzilla has been touched. I don't know C++ and that frustrates me because I can't fix the problems. > >Some of the bugs in Trinity are carry overs from KDE3 and have existed a long time. Consider the bug of using kdeconfig as root user. Every time root uses kdeconfig, the applet creates a .kde folder in the system root directory. I have to add special lines to my rc.local to check and delete that directory. > >Could I use Trinity despite all the usability bugs I reported? I could but I won't. For example, the kdesu bugs I reported leave me quite frustrated. I use kdesu many times each day and that tool works as expected in KDE 3.5.10. > >A primary reason cited by many people for liking KDE3 is the desktop is highly configurable yet simple. No cruft like KDE4. People do not have to run a sqlite database in the background just to check email. People running KDE3 are not interested in a social or semantic desktop. Reading reviews and comments indicate overwhelmingly that many users detest Nepomuk, Strigi, and Akonadi. KDE3 is far more configurable than Xfce or LXDE without the cruft of KDE4. KDE3 can be run on more older hardware than KDE4 can ever hope. In other words, KDE3 is already a good desktop. Hence the dismay by many with the utter abandonment by the developers. > >Trinity brought hope to such users. Many users of Trinity and KDE 3.5.10 do not want additional bling. They want a highly configurable yet stable desktop. In other words, the immediate focus should be bug quashing. > >I appreciate the effort to move to a more modern build environment with cmake and interoperability with QT4. Those are good long-term goals and should continue, but I suspect those efforts have little to nothing to do with the immediacy of swatting bugs. Usability bugs are solved at the code level and not the build level. > >If the reason for not quashing bugs is a lack of C++ coders, then Trinity is doomed right now. > >My Slackware 12.2 system remains usable. Yet as time moves forward I cannot install or update certain packages because of the typical but awful lack of backwards compatibility found in free/libre software. Therefore I am facing the unpleasant decision of updating to a more recent release of Slackware. That means moving to a different desktop environment. I don't relish that decision, which is why I supported Trinity. > >With the lack of bug quashing my enthusiasm for Trinity has diminished. Time for the rubber to meet the road. I am studying KDE4 and preparing for a possible migration. I would rather support Trinity but I have to face reality. So do all end-users who might prefer Trinity. > >Packages must be readily available for end users. Other than Debian/(K)Ubuntu and Slackware 12.2, no other systems are listed as being supported. Such a short list supports the idea that Trinity is a niche product. > >With the release of KDE 4.5.x series, and now 4.6, some people have written that KDE4 is ready for serious usage and has surpassed KDE3 in quality. Doesn't matter whether the proclamations are true or tainted --- the typical end-user believes the statements. Regrettably, such proclamations relegate Trinity to the status of niche product and the majority of users are not going to follow. Therefore any hopes of wide scale Trinity usage is fighting windmills. The only hope for Trinity is to provide a superb product for those who choose Trinity. Long-scale survival efforts such as with cmake and QT4 support are noble efforts but does nothing to push Trinity now. End-users don't care how packages are built. They only want to download and install packages. End users have to ask themselves a basic question: is Trinity a viable choice for desktop environments? > >Being stable and bug-free goes a long way toward spawning interest in Trinity. As KDE4 increases in popularity and pushes Trinity further into niche product status, people will use Trinity because they do not want the massive cruft of KDE4 or the limited flexibility of Xfce and LXDE. Yet if Trinity is buggy then willingness to use Trinity disintegrates. That is now my unfortunate position. > >I'm willing to support this project and have proven as much in the past. Many of the build issues that were fixed to allow building on a non-Kubuntu system were a result of my testing last summer. For many weeks last summer I think Tim and I were the only ones actively working with Trinity. I single-handedly created packages for Slackware 12.2. I can continue adding value in that respect, but I can't fix bugs without a healthy understanding of C++ and the overall desktop environment. Obtaining that level of knowledge and expertise requires many months of study. > >I likely have stirred a hornet's nest with these comments. Yet so many bugs remaining untouched is a troubling sign. I am willing to try to package Trinity for the next Slackware release, but not until many bugs are quashed. > >The Ubuntu people had a project called 100 Paper Cuts. I plea for the Trinity 101 Paper Cuts Project. > >Darrell > > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net >For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net >Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ >Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting >

4 5

Re: [trinity-devel] flooding the devel list is a bad idea - weekly meetings?
by Calvin Morrison 07 Mar '11

07 Mar '11

Darell, I agree with you, and I also agree with him. I think meetings would be a good place to come together and collaborate as well as get to know eachother, have fun, get profess, make announcements etc. the mailing list however is definitely a place for errors and such, after all this is the development list. :) Calvin Morrison, Sorry for top posting, I can't fix it on my mobile. Darrell Anderson <humanreadable(a)yahoo.com> wrote: >> Because the trinity-devel list is flooded so much with >> cmake problems >> and such, we're showing the lack of coordination within the >> project. > >That's not embarassing to me. Or bothersome. > >You folks do what you want. I'm still posting here when I have problems. > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net >For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net >Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ >Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting >

1 0

Condensing our Thoughts
by Robert Xu 07 Mar '11

07 Mar '11

On another note. I've gotten a few complaints that progress is fragmented (people don't know where someone else is making progress, and they don't want to duplicate work) (yet another reason for weekly meetings, but i digress) Please check this checklist (repetition!) and add on, modify, or comment! http://lincom.ietherpad.com/9 Make sure to use the pad etiquette noted at the top. -- later, Robert Xu

1 0

Building tqtinterface fails
by Darrell Anderson 07 Mar '11

07 Mar '11

I'm trying to build Trinity from SVN. I'm still using my old build scripts with automake. As I have not tested my build environment since last autumn, I wanted to make one run to ensure everything still works before trying other things. Basically, start with a known good environment. According to recent list conversations, building with automake should still work with distros using older autotools. Building tqtinterface failed immediately: ============================================ cp: cannot create regular file `admin/libtool.m4.in': No such file or directory cp: cannot create regular file `admin/ltmain.sh': No such file or directory make: admin/Makefile.common: No such file or directory make: *** No rule to make target `admin/Makefile.common'. Stop. ============================================ There no longer is an svn admin directory in the tqtinterface sources. The wiki says "The current SVN tree is being ported to CMake. You cannot build part of the tree with CMake and then start building with autoconf." Do I now have to build tqtinterface with cmake? If so, then I according to the wiki I cannot build the remaining packages with autotools. I saw nothing obvious in the list archives. Darrell

5 12

Building arts with automake fails (looking for qt uic)
by Darrell Anderson 07 Mar '11

07 Mar '11

After failing to build arts with cmake, I tried again with automake. Yes, I know the move is toward cmake, but automake remains supported. I received the following errors: =================================== checking for uic-tqt... not found configure: WARNING: No Qt ui compiler (uic) found! Please check whether you installed Qt correctly. You need to have a running uic binary. configure tried to run and the test didn't succeed. If configure shouldn't have tried this one, set the environment variable UIC to the right one before running configure. make: *** No targets specified and no makefile found. Stop. =================================== How to fix? I rebuilt and installed qt3 with the 3.3.8c patch. Oddly, when I compared the 3.3.8b and 3.3.8c packages, only the directory names were different. Were any qt3 files in the 3.3.8c package changed, or was the patch needed only to build qt3 with the latest tqtinterface? Darrell

1 0

Building tqtinterface with cmake fails
by Darrell Anderson 07 Mar '11

07 Mar '11

I got qt patched to 3.3.8c and installed. :) Now I'm trying to update my tqtinterface build script to build with cmake because there is no admin directory in the tqtinterface source tree. IF tqtinterface can still be built with autoconf then somebody please explain. :) The build with cmake fails. I hope I am correctly following the directions at the wiki. Here are the relative snippets from my build script: ================================ PRGNAM=tqtinterface TMP=${TMP:-/tmp} ... cmake ${TMP}/${PRGNAM} \ -DCMAKE_INSTALL_PREFIX=${PREFIX} \ -DCMAKE_VERBOSE_MAKEFILE=ON \ -DWITH_QT3=ON \ -DQTDIR=$QTDIR \ -DQT_LIBRARY_DIRS=${QTDIR}/lib \ -DBUILD_ALL=ON make VERBOSE=1 ================================ I am building in $TMP and not the svn source tree. I am at svn 1223991. I receive the following cmake error output: ================================ -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- checking for 'Qt' -- Performing Test HAVE_PATCHED_QT3 -- Performing Test HAVE_PATCHED_QT3 - Success CMake Error at cmake/modules/TDEMacros.cmake:1051 (unset): Unknown CMake command "unset". Call Stack (most recent call first): cmake/modules/FindQt.cmake:96 (tde_restore) CMakeLists.txt:39 (find_package) -- Configuring incomplete, errors occurred! make: *** No targets specified and no makefile found. Stop. ================================ Darrell

2 9

kdebase
by Baho Utot 07 Mar '11

07 Mar '11

I am trying to build kdebase SVN checkout of revision 1223901 -- Complete , which resluts in this error [ 48%] Building CXX object kioslave/man/CMakeFiles/kio_man-module.dir/kio_man.cpp.o Linking CXX shared module kio_man.so [ 48%] Built target kio_man-module [ 48%] Generating kmanpart.moc Scanning dependencies of target libkmanpart-module [ 48%] Building CXX object kioslave/man/CMakeFiles/libkmanpart-module.dir/kmanpart.cpp.o Linking CXX shared module libkmanpart.so [ 48%] Built target libkmanpart-module [ 48%] Generating mount_xdr.c file `mount_xdr.c' already exists and may be overwritten make[2]: *** [kioslave/nfs/mount_xdr.c] Error 1 make[1]: *** [kioslave/nfs/CMakeFiles/kio_nfs-module.dir/all] Error 2 make: *** [all] Error 2 Aborting... Building a few days ago worked SVN revision 1222980 works Can anyone look into this?

4 11

TDE CMake learning Q - How does 'install ( FILES...' put things in 2 places?
by David C. Rankin 06 Mar '11

06 Mar '11

Guys, I'm making headway figuring out CMake so I can be a bit more helpful. I'm currently reverse engineering kruler (it's small enough to learn with). So far, the kruler CMakeLists.txt is easy to follow, but I can't figure out how the following creates 2 files?? install( FILES kruler.desktop DESTINATION ${XDG_APPS_INSTALL_DIR} ) /opt/trinity/share/applications/kde/kruler.desktop /opt/trinity/share/applnk/Graphics/kruler.desktop Is there something that says if to ${XDG_APPS_INSTALL_DIR} put it in both the following places: /opt/trinity/share/applications/kde/ /opt/trinity/share/applnk/Graphics/ The other install ( FILES... just end up in one place. (eg. install( FILES eventsrc DESTINATION ${DATA_INSTALL_DIR}/kruler ) /opt/trinity/share/apps/kruler/eventsrc install( FILES move.wav DESTINATION ${DATA_INSTALL_DIR}/kruler/sounds ) /opt/trinity/share/apps/kruler/sounds/move.wav What's the difference? -- David C. Rankin, J.D.,P.E.

5 7

partial port to cmake for kdepim was commited to svn
by Serghei Amelian 06 Mar '11

06 Mar '11

[kdepim]: initial cmake support for following subpackages: akregator, certmanager, kaddressbook, kalarm, kioslaves, kmail, ktnef, libemailfunctions, libkcal, libkdenetwork, libkdepim, libkmime, libkpgp, libkpimidentities, libksieve, mimelib -- Serghei

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels