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  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 .
Thanks and much regards,
I recently pushed a new (alpha quality) backend for the media:/ kioslave
which uses udev/pmount and therefore does not rely on HAL. I encourage
developers here to try it out!
Please report failures to this list, not to the bugtracker, as it has not
been tested much beyond mounting simple flash drives. Encryption support
is buggy, but repairing it is my next task.
Rhis will NOT be made default for R14.0 due to the vast array of hardware
that it still needs to be tested on, but if your distribution no longer
works with HAL it may be better than nothing even in this alpha form.
To enable it, pass the -DWITH_TDEHWLIB="on" option to tdebase CMake.
Considering the original volume of changes needed, we're about as okay as we can expect, but --- we still find branding issues. For example, today I found some more and I am pushing patches.
To resolve remaining branding issues we need the following:
* Some really smart person to grep the system properly looking for corrupt image files (png, xcf, jpg/jpeg, whatever else might be out there). We can't inspect those images for branding issues. For whatever reason, seems many of the images got corrupted with CR/LF issues. We have found most of the corrupt files (walch.martin found most of them --- I only pushed clean files), but I don't know of a good way to search the sources for corrupt image files.
(Note: Corrupt image files do not block building packages, but they cause usability issues that reflect badly on us).
* Some really smart person to grep the system looking for text strings containing KDE. I haven't figured out a slick way to search the sources for these branding issues. Again, I think we have found most but we continually find more, albeit a smaller number of these strings appear each time. The challenge is we *cannot* do a blind global search-and-replace. We are at the point where we have to review each potential suspect string in context to ensure we are updating human-viewable text strings and not code strings.
* Some really smart person to figure out how the fifteenpieces applet About dialog is sucking in a KDE3 branded image (bug report 1052). I don't know whether the problem is limited to fifteenpieces or whether the image being used is a global default About image. One way or another we need to find that image and update.
* Internationalization (tde-i18n) files are beyond me. I nonetheless have patched many of these files. Most of the changes have been in the nature of KDE->TDE, but I suspect that in those patches occasionally I presumed incorrectly and changed something that changed contextual meaning. I don't know how we are going to resolve the differences between the tde-18n files and the parent files in the main source tree (po files, *.desktop files, *.docbook files, etc.)
I was trying to do a quick backport of the sftp kio fix to TDE 3.5.12,
however, it looks like libhpi.so from jre has changed names or disappeared
altogether. (It's not in jre or jdk 7.4)
Does anyone know if this file has been dropped from jre? Is there a patch
that will fix configure?
David C. Rankin, J.D.,P.E.
It seems the migration script is being ran every single time I log on
now. As a result, I see nothing on the screen for a long period of time.
After a while a dialog pops up, which indicates there is an issue with
some desktop link files in my profile.
Could somehow the migration process be announced/displayed/indicated so
that it is clear what is going on? Why could the script have problems
with updating desktop links inside my profile? The diagnostic
information seems limited.
Would anyone be interested in integrating the features (and plugin
system) of katapult into our mini-cli, as well as revamping it?
I think that would improve our launcher considerably and allow for
better integration. Since katapult is plugin based, users could easily
pick and choose what features they want, or if they didn't want any
(disabling all the plugins).
Why do we still support Rosegarden?
Reasons not to support it.
1. It is not a kde project. Right now, Rosegarden is an independent project.
2. The current Rosegarden does not depend on KDE4, instead it depends
on Qt4 and other libraries (not unreasonable)
3. It has a large codebase that is aging, and is a highly specific
application, used for music creators, who will be using the latest
versions of it (for integration with things like jack and dbus), not
the ancient kde3 version.
4. we don't know anything about how it works code wise, sure we can
fix some problems here and there, but we obviously will not be
Reasons to support it.
1. someone somewhere somehow may be philosophically against using Qt4.