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.
I have completed downgrading through the sets of binaries I have and from
that I can summize that this bug was introduced sometime between 3/29 and
4/10. In my 3/29 build, kwrite is fine. In my 4/10 build, this bug effects
kwrite, kate, all editors EXCEPT kedit. In kedit, I can continue to paste away
without any crash (I'm sure it makes no use of katepart...)
So that is the best I can do in narrowing it down rapidly from existing
binaries I have.
Darrell, do you have any binaries between 3/29 and 4/10 that could help
narrow? There were a ton of changes that went into the GIT tree for tdelibs
and tdebase during that two week period. It would be great if we could further
narrow it by simply loading binaries rather going through all the commits...
I've updated 979 with the info.
David C. Rankin, J.D.,P.E.
If I understand correctly, any library directory outside of the standard /lib and /usr/lib locations need to be identified in /etc/ld.so.cache. Is this correct?
During my Trinity build and packaging process, I have been inserting /opt/trinity/lib into /etc/ld.so.cache.
Do I need to add /opt/trinity/lib/trinity too or are subdirectories of /opt/trinity/lib automatically found by ldconfig?
Are there any other library locations from Trinity that belong in /etc/ld.so.cache?
When I build Trinity packages, because I am installing to a non standard location, I explicitly declare $LD_LIBRARY_PATH=/opt/trinity/lib in my build environment. I do not declare this variable in during run time. To my understanding, this variable causes the build process to use that location before using library files in the standard locations or /etc/ld.so.cache. Is this correct?
I had to see that there is still development going on in your fork of KWin and
I am very unhappy about that. This is something I really want to see resolved,
any development to KWin should happen in KWin, it's such a waste to work on
the same project without coordination.
Let's first recapture the state of TWin:
= Why does TWin exist? =
Because KWin got forked together with everything else from KDE 3.5 to form the
Trinity Desktop Environment (TDE).
= Why has the TDE fork happened? =
The TDE fork existist because of a combination of the following reasons:
* Parts of KDE had to be rewritten in order to be ported to Qt 4
* Early versions of KDE 4.x were lacking functionality compared to KDE 3.5
* Early versions of KDE 4.x had quality and stability issues compared to KDE
* A general disagreement with some project decisions
* KDE 4.x introduced new technologies unliked by some (e.g. Nepomuk or
= Do these reasons hold for KWin? =
No! None of the reasons stated above has ever been true for KWin. KWin is a
direct continuation of the KDE 3 version. The codebase did not get rewritten,
the quality of the window manager did not suffer, new functionality got added
as optional addons.
= Is there any other reason justifying the TWin fork? =
Maybe the fact that KWin depends on Qt4/kdelibs4 which is not liked by TDE.
= Is that a reason for a hostile fork as it is at the moment? =
No, the fact that TWin requires Qt 3 is no reason to have the current state
with the hostile fork. Best would be a solution of no fork, but a
collaborative friendly fork should be possible, given that KWin and TWin share
a large code base.
= What can KDE do about the fork? =
Actually pretty much nothing. The license allows TDE to fork KWin - whether we
like it or not. All we can do is force you to change the name and urge you to
work together with us.
= Why do I actually care? =
The KWin development team is rather small. I would like to see more involvment
inside KWin than to see duplicated work in a fork.
Furthermore KWin 3.5 has a very good reputation and is known as rock solid. I
see this reputation questioned if the TWin fork is continued without the
quality checks performed in the KWin development.
Lets have a look at the recent patch for TWin called "Mac Like Switching
Panel". This introduces a new feature to switch through applications and
references an implementation in window maker. To be clear: this functionality
has been present in KWin since version 4.4 (I added it). A little bit of
coordination here would have prevented the duplication of development.
But is there a problem when Trinity adds code, should I care? Well the code is
wrong (review based on patch2.patch on mailing list). In an attempt to copy
everything from window maker code got added to KWin (particular readClass)
which already existed. Lack of knowledge about the KWin source code are
probably the reason that it is unknown that
KWin::Client::resourceName()/resourceClass() provide the window class
Another problem is that the code is crashy. For me as an experienced KWin
developer I only need to look at the code and see immediately were it is
likely that the code will crash. Consider that start is NULL and the following
line of code: start->readClass().
How likely is it that a non KWin developer would have spotted this crashy
code? How likely is it that you know how to create such a situation? (I know
It is not surprising that you are not able to add code to KWin which is
correct - hardly anybody not knowing the code base is able to do so. That's
why we perform code review and help new developers to get the code into a
state that it works correctly. We are happy to accept patches from the Trinity
team to KWin as well (of course we only accept patches for current master).
The important difference is that in KWin there is a quality assurance through
the code review by *experienced* KWin developers. This is impossible in TDE as
there are no experienced developers for KWin.
Now I'm not writing this mail to blame you for writing wrong code. If I would
be "evil" I would sit back, relax and wait to see TDE hit the wall which is
approaching faster and faster when crashy code gets added. Remember: one of
the reasons for Trinity is the (no longer) bad quality of KDE 4 code. And you
even use that in your external communication - such crashy changes might
backfire and then you cannot blame KDE.
I'm here now to resolve this issue about TWin together with you. I want to see
the hostile fork go away. From all we see TDE is unable to maintain or even
develop TWin. Please accept this fact as it is. It is nothing bad, I needed
three years of strong involvment in KWin developer before becoming maintainer
and there are still large areas of code blocks where I have no clue about.
Based on that fact we have to look for a solution. In my opinion the best
would be to just use our KWin. And we have some quite useful things about that
in our current development version:
* no longer depends on anything else from kde-workspace
* build options to disable "KDE 4" features (see
* mostly runtime dependencies to libplasma
* desktop integration possible through custom QML additions like e.g. Alt+Tab
* currently integrates with three desktop shells
* (under review) build option to change the name of the binary, which would
allow you to generate a kwin_tde or twin binary (automatic adjustment of all
configuration files, etc.) (see https://git.reviewboard.kde.org/r/104299/)
* after feature freeze: branch to build kwin standalone without the need to
run cmake in kde-workspace.
As you can see this is a rather impress list of features which would allow TDE
to use KWin instead of their fork.
Of course KWin depends on Qt 4 and kdelibs 4. We have no interest to support
anything below Qt 4.7 and are currently preparing the transition to Qt 5 and
KDE Frameworks 5. I think that this is only a minor issue to Trinity as to my
understanding TDE can also use Qt 4.
We are open to discuss any concerns regarding integration a Qt4/kdelibs4 based
application into TDE. I am very sure that most of your possible concerns are
rather non-issues and that they can all be easily resolved.
I hope that you consider dropping your hostile fork of KWin and start to
collaborate with your upstream pears at KDE more closely.
Thanks for your time
As /dev/ammo42 suggested, I captured a strace on the i686 crash. It is
attached to bug 979. (current tdebase and tqt3, tdelibs from 4/16 -- same crash)
Also, this bug occurs 100% of the time when pasting 'small' amounts of text
(1-2 words at a time) until the line wraps. I can paste 10 lines of text into
kwrite and keep editing - so it looks like something that effects the single
line length computation.
I'll keep incrementally downgrading and report when I narrow the time the
bug was introduced. If anyone can read straces, then take a look.
David C. Rankin, J.D.,P.E.
As I work to downgrade my R14 test boxes to troubleshoot what caused the
kate/kwrite crash, I ran into a question I would like to get your thoughts on.
All my day-to-day boxes run fully updated Archlinux (with one openSuSE box), and
TDE 3.5.12 as the desktop (3.5.10 on SuSE).
If the crash is due to an Arch update -- "They why do kate/kwrite continue to
function normally in 3.5.12?"
It just strikes me that 3.5.12 would be much more susceptible to break due to
Arch updates that R14. Would we not expect to see this same crash in 3.5.12 if
this was due to an Arch update?
What say the experts? If this was Arch, wouldn't 3.5.12 have broken too?
David C. Rankin, J.D.,P.E.