tde-devels December 2011

devels@trinitydesktop.org

32 participants
74 discussions

by Baho Utot

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

12 years, 11 months

Slow TDE Exit Time

by Darrell Anderson

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

12 years, 11 months

Kdesu and $PATH

by Darrell Anderson

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

12 years, 11 months

Donations

by Darrell Anderson

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

12 years, 11 months

Suggestion to drop [t|k]win from Trinity and replace it by KWin4

by Martin Gräßlin

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…

12 years, 11 months

Interesting comment in passing about TDE

by Darrell Anderson

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

12 years, 11 months

kdenetwork-3.5.13

by Bruce Dubbs

I've moved on to kdenetwork. The same build instructions for kdeadmin seem to work, but the build of kopete fails with: linux/videodev.h no such file or directory I can find the .h file on an older version of linux, but kernel version 3.0.4 only has videodev2.h. It looks like it is included from two files: kopete/libkopete/avdevice/videodevice.h kopete/plugins/motionautoaway/motionawayplugin.cpp Changing the include in these files to videodev2.h does not work (and I would have been suprised if it did). Does anyone know how to work around this issue? Excluding kopete will complete the build, but that certainly isn't optimal. -- Bruce

12 years, 11 months

Single-click is the default?

by Darrell Anderson

The default mouse click behavior was changed to double-click a long time ago in this patch: http://www.trinitydesktop.org/patches/1284792137:5ec667408632981bb995a8af48… Checking the affected 3.5.13 header file shows the change is good with no regressions. I also have my own default global $PREFIX/share/config/kdeglobals file that has SingleClick=false. The file does get installed and the setting is the same. When I create a new profile through the KPersonalizer wizard the default becomes single-click. When I skip the KPersonalizer wizard then the default is double-click. Therefore something in the KPersonalizer process is overriding the system defaults. Would somebody please confirm this behavior? Thanks. Darrell

12 years, 11 months

Device Icon Bugs

by Darrell Anderson

Although I have been submitting many patches, I am but a C++ newbie. There are some bug reports I very much want fixed. Two of the reports likely all have the same cause and likely could be resolved with the same patch. The problem likely is TDE not initializing correctly. Another report is closely related to those three: 385 Unmounted removable device icons do not appear on the desktop (http://bugs.pearsoncomputing.net/show_bug.cgi?id=385) 372 Storage media applet doesn't show usb stick at kde startup (http://bugs.pearsoncomputing.net/show_bug.cgi?id=372) 392 Desktop Device Icon Placement (http://bugs.pearsoncomputing.net/show_bug.cgi?id=392) The first two are usability bugs. Users expect device icons on the desktop. Icons should appear when TDE is started and should not require a device change event to show other icons. The third bug does not cause any crashing, but the placement behavior is contrary to 3.5.10 and other desktop environments. The traditional placement of new icons is in the first vertical left-side column, below existing icons, and when no room exists there, to start in the second vertical column, top. As TDE is being marketed as a traditional desktop, we should embrace those expected behaviors. Ideally, there should be a KControl option that dictates whether placement hierarchy is vertical or horizontal, but the default should be vertical. A fourth bug that hampers usage: 692 Kate: focus is broken when using the --use parameter (http://bugs.pearsoncomputing.net/show_bug.cgi?id=692) I've looked at the code and patching these bugs is beyond my current skill set. :( Hopefully in a year I can say differently, but not today. I'd be grateful if some of you C++ experts would look at these bugs. I'm ready and willing to test patches. And I'll likely learn something too. :) Thanks! Darrell

12 years, 11 months

Cmake issues: Building kdebase with HAL support

by Darrell Anderson

Several bug reports focus on TDE not displaying device icons on the desktop or the standard popup dialog when a new device is detected. Refer to bug reports 372, 385, 634 for starters. These are serious usability bugs. Today I started investigating. I discovered that HAL support is not enabled in the default cmake options. I don't know why that is the default. I enabled HAL support with -DWITH-HAL=ON. The build failed for failing to find some header files. I submitted a small patch in bug report 755. I don't think my patch is the best approach. Instead I think the following environment variables need to be defined: $DBUS_TQT_LIBRARY_DIRS $HAL_INCLUDE_DIRS $HAL_LIBRARIES Although referenced, I don't think these variables are defined anywhere in the cmake files. How do I patch the cmake files to know those locations? I could hard-code those locations in my kdebase build script or build environment, but what is the proper approach? Darrell

12 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels December 2011