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
All,
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.
Enjoy!
Tim
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.)
Darrell
All,
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.
Tim, All,
To track the recent handful of ftbfs for k3b, k9copy, kdmtheme, krusader due
to scope/declaration issues that have surfaced, I have opened:
http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=1119
That will provide a common point to work from.
--
David C. Rankin, J.D.,P.E.
Calvin, All,
I have updated all of the Arch PKGBUILD scripts with the current R14.0.0 build
scripts at:
http://www.3111skyline.com/dl/dt/tde/src/
You can download all the PKGBUILD src dirs in the file:
http://www.3111skyline.com/dl/dt/tde/src/tde-pkgbuild-src.tar.gz
It doesn't include wv2/koffice dependency (forgot), so download it here:
http://www.3111skyline.com/dl/dt/tde/src/wv2-0.4.2-3.no-src.tar.gz
All the individual PKGBUILD masters (PKGBUILD only) are available in:
http://www.3111skyline.com/dl/dt/tde/pbf/pbf-PKGBUILD-files.tar.gz
(I find it easier to keep a dir of pkgbuilds for access in kate and then copy
them to the pbpkg dir after updates.)
MAKE sure you read:
http://www.3111skyline.com/dl/dt/tde/src/README-building.txt
If you want to set up and end-to-end build environment similar to what I have.
Then just call ./bldtde.sh (after you setup bldtde.conf) and let R14 build. (you
have to have a local copy of the GIT tree, and create tarballs with ./tdetgz -w)
Once we get R14 settled and I can strip the temporary patches and sed commands
out of the PKGBUILDs, I will update the tde-packaging files. We will need to
just move to 3.5.13/remove the current pkgbuilds on tde-packaging because I
don't think they have been updated in a year or so. I haven't checked who the
GIT owner is, but I know it isn't me :)
--
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.
Thanks,
Julius
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).
Calvin
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
developing it.
Reasons to support it.
1. someone somewhere somehow may be philosophically against using Qt4.
Calvin