tde-devels November 2011

devels@trinitydesktop.org

44 participants
150 discussions

Workaround for bad Qt4 performance
by Sanne 06 Jan '13

06 Jan '13

Hi all, I was listening in on the last irc meeting and caught an aftermeeting mentioning about bad Qt4 performance. I offered an article and a possible workaround I found recently, in case people are not aware of it, and was asked to bring it to attention to other developers also, so here goes: I'm suffering bad graphical performance in Qt4 and PyQt4 applications and searched for solutions. I found a post on nokia.com [1] that mentions a command line switch that might help. In short: adding "-graphicssystem raster" to my Qt4 applications' command line improved performance drastically for me. There's also a method to set it programmatically, and an environment variable [2]. [1] http://labs.qt.nokia.com/2008/10/22/so-long-and-thanks-for-the-blit/ [2] http://doc.qt.nokia.com/4.7/qapplication.html#setGraphicsSystem Thanks and much regards, Sanne

3 2

Trinity, Gentoo, and packaging
by E. Liddell 09 Dec '11

09 Dec '11

Or: "Lions and tigers and ebuilds, oh my!" Yes, I know there are no official packages for Gentoo yet. I decided to see if I could do something useful by installing what unofficial ones were available and probing for bugs, and possibly rolling a few ebuilds of my own for the packages that haven't gotten any love yet. I used non7top's GitHub fork of Serghei's ebuild repository (at the time I started, the contents of the two were identical, actually) and did manage to get kdebase installed after two ebuild- related hiccups. After that, things started to get complicated, and I ran into a variety of problems. Unfortunately, I haven't been able to decide whether some of them are Trinity bugs, ebuild bugs, or just Gentoo quirks, so I don't know where to file them and need help with the triage. __________________ Problem #1: Unset environment variables When I first booted Trinity, the desktop *appeared* to come up exactly as it should, but most applications would not start, the main menu was nearly empty, and kcontrol had no settings available. After some mucking around, I discovered that there was no mention of the Trinity bin directory in my PATH, and then found that Gentoo set PATH, ROOTPATH, LDPATH, and XDG_DATA_DIRS inside a distro-specific part of starkde (for KDE 3.5.10, that is), so I copy-and-pasted those into the startup file provided. (I know there are some setters in the Trinity startup script. They didn't work, possibly because of Problem #4.) Unfortunately, that didn't fix things--I also needed to set LD_LIBRARY_PATH for programs (including konsole) to start properly, and XDG_DATA_HOME, XDG_CONFIG_HOME, and/or XDG_CONFIG_DIRS (I never tried setting them individually, so I can't narrow it down) to get a working menu and kcontrol. I don't know what changed between KDE 3.5.10 and Trinity 3.5.13 to make the setting of those additional environment variables necessary, so I'm not sure who owns the second half of the bug. __________________ Problem #2: Autotools packages and ebuilds I did manage to write some successful ebuilds (I have most of kdegraphics and kdeartwork working, if anyone wants ebuilds for those, plus kdebase-meta and a variant ksmserver ebuild with a hal useflag), but only for packages that have been ported to CMake. The autotools packages Will Not Work, no matter how I mangle the KDE 3.5.10 ebuilds (rewriting from scratch is not an option, IMAO--the old kde-meta eclass contains several hundred lines of bash script, and spending more than minimal time on a build system that's going away is wasted effort). After a lot of playing around with kdetoys, I was able to figure out that I was running into two problems: a minor change in the tarball structure (not a bug, solved by a 1-line fix), and a set of missing build/config files. The kdetoys-3.5.10 tarball contains a bunch of files at the top level that are missing from its 3.5.13 equivalent: configure.in, acinclude.m4, aclocal.m4, and several other config* and Makefile* files. When I copied these files from the old to the new package, the ebuild got as far as actually configuring/building the package (and, naturally, failed, because the old buildscripts didn't know about TQT, but it was the first iteration that didn't bail out while trying to find the build directory or run eautoreconf/aclocal). I know next to nothing about autotools, so I don't know if those files were removed for a reason. Maybe someone who knows more about autotools and ebuilds could do something without them; I just know that *I* can't. Another thing is that I couldn't seem to get the --without-arts switch to work, but with the ebuilds so messed up to begin with it's difficult to tell whether that's meaningful. __________________ Problem #3: CMake failures Ebuilds for two subapplications of kdeutils that were included in the stuff I took from GitHub failed to build, complaining that they weren't able to find tqt.h (one of them would have been Ark). I don't know whether this is an ebuild or a CMake bug. __________________ Problem #4: startkde/starttrinity and minimal or unusual builds While I was wrestling with Problem #1 above, I had occasion to examine both the new and the old startup scripts in detail, and there were some things in the new one that drew my attention. However, I'm not sure they really qualify as bugs: if [ -d /opt/trinity/games ]; then That, and the lines that follow it, might work fine if Trinity is installed into /opt/trinity/, but Gentoo's practice is to install most software into /usr/. Something like: if [ -d ${KDEDIR}/games ]; then might be more portable. # Make sure a default wallpaper is set. if [ ! -e $kdehome/share/config/kdesktoprc ]; then # With Trinity this file should exist, but test first. if [ -r /usr/share/wallpapers/isadora.png.desktop ]; then cat >$kdehome/share/config/kdesktoprc <<EOF [Desktop0] Wallpaper=isadora.png WallpaperMode=Scaled EOF fi fi Not having a wallpaper set is harmless--these lines seem to add complexity to the script for no good reason (and I don't have a /usr/share/wallpapers, either-- isadora.png is in /usr/kde/3.5/share/wallpapers--so this code isn't portable). Perhaps it belongs in a distro-specific patch? # Configuration of the gtk_qt_engine if not already set. [...] Trinity will run quite happily without gtk-qt-engine installed, so a test needs to be made for that (at minimum--I'd relegate this to "distro-specific" too). # Remove moodin cache if we have a new wallpaper installed, jriddell. Distro-specific. if [ -d $kdehome/share/apps/ksplash/cache/Moodin/kubuntu ]; then if [ /usr/share/wallpapers/kubuntu-wallpaper.png -nt $kdehome/share/apps/ksplash/cache/Moodin/kubuntu/ ]; then rm -rf $kdehome/share/apps/ksplash/cache/Moodin/kubuntu/ fi fi This says right out that it's a Kubuntu patch. It doesn't belong in vanilla Trinity. $KDEDIR/bin/artsshell -q terminate Arts is another optional component that Trinity can operate without, so it shouldn't be shut down without testing to see if it's there. Maybe: if test -e $KDEDIR/bin/artsshell ; then artsshell -q terminate ; fi (The prelinking stuff isn't in my old startup script either, but I suspect that Gentoo may have removed it.) __________________ I think that's everything. The other (minor) bugs I ran into I'm fairly sure I know where to file.

2 7

Running Trinity, KDE 4, and KDE 3 Concurrently
by Darrell Anderson 07 Dec '11

07 Dec '11

Just my observations with Slackware 13.1. YMMV. Please feel free to add, edit, qualify, add a workaround, etc. Should we fine tune this information and post to our wiki? =================================== Whereas the Trinity developers have worked hard to support KDE 4 compatibility, there are several challenges with running Trinity, KDE 4, and KDE 3 installed on the same multiple user system. 1. Many of the apps use the same file name. The scripts in /etc/profile.d produce conflicting file search paths. Without the appropriate file search path, the file search path highest in the path hierarchy will launch the app, which might not be the correct app. 2. On multiple user systems, the profile.d scripts can’t be arbitrarily disabled because any of the desktop environments might be used. 3. The profile.d scripts cause conflicts with XDG paths, which create the desktop menus. Normally this is not a problem with other desktops such as Xfce, but that is not the case with these three desktops because many apps have the same name. With each profile.d script being sourced, each desktop system menu will show every app from all other desktops. The Trinity developers have hacked a neat trick to tag the KDE 4 apps in the menu, but there is no such support for KDE 3 apps. The hack does not exist for KDE 4 or KDE 3. 4. User-defined menu changes are stored in $HOME/.config/menus and $HOME/.local/applications. As those directories are global to anything the user does, menu changes in one desktop affects the other desktops if a user wants to change desktops. That means conflicts with starting apps. 5. The KDE 3 and Trinity KDM login manager will conflict unless one or the other is disabled (chmod -x). Neither can be used to support the other desktops because of the underlying dependency on each desktop’s respective kdelibs package. 6. The file search path conflicts will introduce multiple autostart directories. Apps in those directories will start for the other desktops too. A possible work-around to most of these conflicts is to disable all affected profile.d scripts and then modify the xinitrc scripts to source the appropriate profile.d scripts. That might suffice for run level 3, but not run level 4. Run level 4 would require some detailed scripting in the KDM Xsession script to look at the user’s dmrc config file and then source the appropriate profile.d scripts. Yet these work-around won’t resolve any user-defined menu changes. On single user systems or systems where all users want to use the same desktop, all of this can be avoided by uninstalling the other desktop environments. =================================== Darrell

5 22

"Keep password" check box restored to kdesu dialog box
by Darrell Anderson 03 Dec '11

03 Dec '11

I submitted a patch to bug report 388 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=388). The patch restores the visibility of the kdesu "Keep password" check box. In TDE, the check box is hard-coded invisible rather than being a function of the kdesu -t parameter as in 3.5.10. The patch (kdebase/kdesu/kdesu/kdesu.cpp): ================================================ // Try to exec the command with kdesud. bool keep = !args->isSet("n") && have_daemon; - bool terminal = true; + bool terminal = args->isSet("t"); bool new_dcop = args->isSet("newdcop"); bool withIgnoreButton = args->isSet("ignorebutton"); ================================================ Although I suspect many will welcome the patch, there likely will be just as many who will fear being eaten in the dark by grues if this check box is visible. I dislike the idea of those who want this check box visible to have to always patch the TDE sources in their build scripts. Is there a way to test who wants this check box visible and those who don't so no build-time patching is required and everybody is happy? I think the 'buntu family of distros don't use kdesu and instead use kdesudo. Perhaps this patch does not affect those distros. If that is the case then the discussion falls on everybody else. Ideas? Darrell

5 12

Package building QA
by Darrell Anderson 03 Dec '11

03 Dec '11

Do we have a check list to help developers/packagers watch for QA problems with packages? I have not seen any. How about we start one? 1. Check two apps in each menu category of the T-Menu to verify the Help file handbook is available. 2. Run a system test looking for broken sym links. (I use a short script I can share.) 3. Do all apps in the T-Menu start? 4. Check the xsession logs for unexpected or unusual errors and messages. 5. Do kdesu/kdesudo work as expected for your distro? This is just for starters. Please add to this list. Darrell

4 4

Kmail randomly archiving gmail messages
by Kristopher John Gamrat 02 Dec '11

02 Dec '11

Some of my gmail messages are being archived (removed from my inbox but not being deleted) when Kmail checks my gmail account. This only happens when Kmail does it's check, and none of the emails that are being archived are showing up because they aren't in any of my IMAP folders. I know the archived messages are still there because I can log into gmail's web interface, go to my "All Mail" list, and see the archived messages. When I move them back to my inbox, they will stay there so long as Kmail isn't checking for email. There is no setting in gmail's settings (either Kmail or the web interface) to do this, nor do they offer any filters that would do this (or at least, I don't have any such filters active in my gmail). I have checked my IMAP settings in Kmail and gmail web interface. I cannot find any settings that would exhibit this behavior. I do include my inbox (and all the other IMAP folders) in both my serverside and local subscription. The last detail I can offer is that I'm using cachedimap instead of regular imap. Is there anything outside of my gmail/IMAP settings that could be causing this? -- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/

2 1

KDE3 Profile Migration Script
by Darrell Anderson 01 Dec '11

01 Dec '11

In my patched startkde script (bug report 675) I include code to automatically migrate a user's existing KDE3 profile directory. I'm thinking perhaps I move that code to a separate script, say $PREFIX/bin/migratekde3, and source that script in startkde. That would allow admins and users to run the script as they please and separate maintenance for us. By moving to a separate script we all can test more easily and improve that script without directly impacting startkde. As a separate script testing could be performed in any desktop environment and not just TDE. Opinions? Yays? Nays? Darrell

4 6

Réf.: Re: [trinity-devel] build script for Opensuse ?
by ds ds 30 Nov '11

30 Nov '11

Le mer. 30 nov. 2011 02:06 HNEC, Dr Tony Young a écrit : >On Wednesday 30 November 2011 09:37:00 ds ds wrote: >> Is there a build script for Opensuse somewhere ? Even at a work-in-progress >> state ? > >I am assured that there is. :-) It is definitely in progress and I am looking forward to testing >it. >Tony Ok. Where is the web page ? Dsant

3 2

Bug Report 244 is patched
by Darrell Anderson 29 Nov '11

29 Nov '11

The little things tend to make a difference in our lives. Long ago in this galaxy, a KDE developer decided that being able to specify the number of files in Kate's Most Recently Used (MRU) file list, and to sort the files in the Documents file pane, was "useless crap." To me those features never were "useless crap." I have missed those features for a long time. I found the patches where those features were removed. I am not a C++ coder, not even close. Yet I was able to reverse the patches and add a little "TQT" love. By golly, the widgets actually appear in Kate! Once again I can set the size of the MRU list to something greater than 10 and sort the file list. Current Kate 3.5.13 picture: http://humanreadable.nfshost.com/images/kate-before.png Patched Kate picture: http://humanreadable.nfshost.com/images/kate-after.png The number widget works great. I think some of you will love that restored feature. Took me a while to realize the sorting option affects the files in the Documents list pane and not in the MRU list. :) I uploaded the patch to bug report 244. Woo-hoo! :) Darrell

5 6

build script for Opensuse ?
by ds ds 29 Nov '11

29 Nov '11

Is there a build script for Opensuse somewhere ? Even at a work-in-progress state ?

4 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels November 2011