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.
I'm updating various help guides.
The first section of the "TDE for Administrators" help guide, "Chapter 25. TDE Internals, Overview," is empty.
Note: To view this help guide, select the TDE User Guide and scroll to section VI.
I would be grateful for suggestions and ideas for what information should go in this section.
For R14 I would like at least to provide an outline of topics, even if we don't get around to actually providing detailed content.
A note to everybody interested: we have an etherpad checklist to track pre-release tasks. Please help with this preparation check list and missing items too.
In the etherpad I attached a preliminary draft/template for a press release. Please add/edit as you see fit.
We need help to create a list of to whom we should send an email with the final press release. Please help populate that list.
Releasing R14.0.0 is a tad down the road yet, but if we peck away at these things then the final days won't be as hectic. :-)
I'm looking forward to the official release!
Also noted from the meeting, the current 3.5.13 will _not_ build on gcc 4.7.1.
There is _no_ reason not to port the patches to the 3.5.13 code base. All the
patches simply cleaned up the code from a syntax standpoint and will not impact
it building on earlier gcc releases. The closed bug 979 holds the collection of
gcc 4.7 patches that could easily be applied to 3.5.13 to make it gcc 4.7.1
David C. Rankin, J.D.,P.E.
Pretty sure this is upstream and not distro specific.
It is exactly the same as 'solved' bug number 394 but under latest git
Running tdesu (from guest console or superuser menu item) kills klauncher
and nothing from tmenu or tray will launch, instead receiving the error
message: "Klauncher could not be reached via dcop"
Running tdeinit fixes the error.
To reproduce open a guest console and run 'tdesu kwrite' then close and
launch something from tray.
My build is from latest git. Can someone confirm this behaviour? Regression?
Looking at 3.5.10 on suse, there is an app called 'krecord' that is a handy
little sound recorder that provides a frequency spectrum and input-level monitor
window. I can't figure out what source this comes from or if it is in TDE. Any
ideas? Here is a screenshot:
David C. Rankin, J.D.,P.E.