Bug 1489

On Ubuntu 13.04 with TDE R14 nightlies of July 14, 2013, using QTCurve theme causes many problems and instabilities all across TDE:

-As stated below, the background of K menu and File, ... menu is not always shown
-In Amarok, when I press on File menu, it doesn't show the menu.
-In VirtualBox, whenever I come to open a file selection (browsing) window, VirtualBox crashes. If I start it from Konsole, I can clearly see that it is caused by a segfault in QTCurve
-Whenever QTCurve crashed either completely or if it lock temporarily the computer, it slows down the computer and CPU use gets high, while using QTCurve on 3.5.13.2 is very stable and causes no freezing.
-Many lockups in TDE

TDE R14 is generally stable with Plastik widget style, but it is totally different with QTCurve. More testing should be done with R14 while using QTCurve, because QTCurve for R14 is not ready for release at all as of now.

I just bought a new Asus EEE X101CH, and since it needs a newer kernel than the one of PCLinuxOS, I use Ubuntu 13.04 with R14 nightlies on it for now, so I should be able to provide more debug info soon.

Thanks!
-Alexandre

Backtraces of crashes and lockups would help us fix the problems quickly.  Be sure to install the tdelibs debugging symbols and the qtcurve debug symbols before generating/posting backtraces.

Created attachment 1350 [details]
Crash when opening LibreOffice with QTCurve

Crash when opening LibreOffice with QTCurve on Ubuntu 13.04 with July 17, 2013 R14 nightlies

Here is what I had while starting LibreOffice with QTCurve.
I don't understad how it generated all this text, because I had not installed yet the tdebase-trinity-dbg package...

This time, the drop menus of Amarok worked as they should, but in VirtualBox and Speedcrunch, I couldn't open a ''open file'' dialog without making the program crash. QT4 programs use the TDE theme engine, so it is probably why it crash.

There is something that I doesn't like in the ''GTK Styles and Font'' section of the control center:
-First of all but not relied to GTK: It would be a good idea to have such option control for QT4 theme engine. It should be set in the qtconfig program, but if TDE override the setting without letting the user choose a theme, it will probably make a conflict of which theme is used.

-There is 2 choice: -Use TDE theme -Use another theme
Couldn't we have a third option that would be ''Do nothing''
This would be useful in cases as when the layout is destroyed in LibreOffice documents on PCLinuxOS. In this case, the theme of GTK (or QT4) is not controlled at all by TDE.

-Alexandre

When qtcurve is run under LibreOffice, many the class constructors are not executed (yes, I triple checked this!).  This primarily causes crashes, but can also cause hangs depending on the current (random) contents of the uninitialized memory segments.

For some reason this *only* seems to happen under LibreOffice.  I am somewhat at a loss as to why this happens, but will not that it has happened before to others under KDE 3.5.10 with no resolution:
http://forum.openoffice.org/en/forum/viewtopic.php?f=16&t=36225
https://bugs.freedesktop.org/show_bug.cgi?id=41496
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549069

My best guess, aside from a compiler bug, is that the gcc/g++ versions/flags used to compile LibreOffice and TDE are incompatible somehow.  Constructors should always be called on object creation!

Valgrind turns up nothing (except for the failures after object creation when the constructors are not called), so I don't think memory corruption is causing the constructor failure.

(In reply to comment #1)
> -In Amarok, when I press on File menu, it doesn't show the menu.

This is probably a kompmgr problem.  I have seen this for years now, only under kompmgr, but have not been able to isolate the problem to fix it.  Essentially at some point kompmgr fails to display a new window (popup menus are new X11 windows), even though the window is "visible" and active (i.e. able to be clicked on and interacted with, provided that you know where the elements are as the window is completely invisible!).  Sometimes merely closing one application or starting another is enough to clear the problem.  Best guess would be an overflow in some variable relating to a window ID, or a logic error when some Wid variable is close to its maximum value.

> -In VirtualBox, whenever I come to open a file selection (browsing) window,
> VirtualBox crashes. If I start it from Konsole, I can clearly see that it is
> caused by a segfault in QTCurve

I cannot replicate this.

> -Whenever QTCurve crashed either completely or if it lock temporarily the
> computer, it slows down the computer and CPU use gets high, while using QTCurve
> on 3.5.13.2 is very stable and causes no freezing.

Probably due to the uninitialized memory problem as stated above.  Why 3.5.13.2 does not crash is beyond me right now, the startup code (where the crashes are occurring) is pretty much identical in R14 vs 3.5.13.2.

> -Many lockups in TDE

If you can use gdb to break into a frozen TDE program, and generate a backtrace, I will be able to look into the problem faster.  At the very least I need an example of one of these lockups in a native TDE program (e.g. kate, kwrite, kicker, etc., NOT Libreoffice, VirtualBox, etc.) to investigate further.

Thanks!

Hi,

Oh, seems like I'm throwing quite big problems here!

For the Amarok menu, I wasn't using TDE compositor (or any other compositor). It was probably just not compiled as it should because after updating, it works as it should.

Ok, I'll try to update my TDE R14 install tonight and I will do further testing on it.

If it is not possible to make QTCurve work on R14 for now, is it possible to look at why pixmaps are not loaded when using a pixmap-based theme on TDE? I *guess* that it is not something big to make work. It is bug report no 1609.

Thank you for your hard work on TDE!
-Alexandre

Thus far I have not been able to replicate any QtCurve lockups in native TDE programs with the nightly builds.  Is this part of the bug report still valid?

Hi,

No, there is no lockups anymore. But QTCurve is still not debugged, as it was on 3.5.13.2. 
It will require some attention, especially if you plan to use it as a default, as it is when R14 is installed on (K)Ubuntu.

If you can take some time to try different settings of QTCurve on R14, you will see that it is buggy and might even, on some cases, render the session unusable, because of QTCurve bugs.

In the configuration  window of QTCurve, you will see at the bottom left a menu where you can select presets. It is easy to try, and it will let you see which part of QTCurve doesn't work.

Overall, R14 is getting better and better, close to 3.5.13.2 quality.

Thank you!
-Alexandre

Hi,

In recent R14 nightly build, running on my Asus EEE X101CH with Ubuntu 14.04, there is less visual glitches now.

For the problem I saw where the background of drop menus was transparent (not drawn at all) when a gradient background was used, it is much less present. The only menu where I still see this problem is the classic Kicker start menu, which is very long.


This Asus EEE X101CH seems to be an interesting case...
I often have bug that other users does not have at all.
What could be the cause?

-Alexandre

(In reply to Timothy Pearson from comment #5)
> When qtcurve is run under LibreOffice, many the class constructors are not
> executed (yes, I triple checked this!).  This primarily causes crashes, but
> can also cause hangs depending on the current (random) contents of the
> uninitialized memory segments.
> 
> For some reason this *only* seems to happen under LibreOffice.  I am
> somewhat at a loss as to why this happens, but will not that it has happened
> before to others under KDE 3.5.10 with no resolution:
> http://forum.openoffice.org/en/forum/viewtopic.php?f=16&t=36225
> https://bugs.freedesktop.org/show_bug.cgi?id=41496
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549069
> 
> My best guess, aside from a compiler bug, is that the gcc/g++ versions/flags
> used to compile LibreOffice and TDE are incompatible somehow.  Constructors
> should always be called on object creation!
> 
> Valgrind turns up nothing (except for the failures after object creation
> when the constructors are not called), so I don't think memory corruption is
> causing the constructor failure.

I was finally able to track this down to its origin after over a year.  QtCurve provides a Gradient class in its style plugin; LibreOffice also provides a Gradient class (https://docs.libreoffice.org/vcl/html/classGradient.html).  For reasons not fully understood by me:
a.) both classes provide exactly the same mangled class/constructor symbols
b.) one or both plugin loaders (TDE and/or Libreoffice) manage to make their Gradient class available to the other plugin handler (this is not supposed to be possible under the Linux "dlopen" RTDL system)
c.) the qtcurve style ends up calling the Libreoffice Gradiant class constructor instead of its own, causing the crash.

As I had difficulty believing this arcane cause when I first discovered it, I initially verified by renaming the QtCurve Gradient class.  A more permanent solution was then fashioned by forcing all QtCurve classes into their own namespace.

Fixed in GIT hash 0ea8899 (tde-style-qtcurve).

I am not starting to wonder if some of the other "odd" crashes (e.g. those experienced with Firefox and the gtk style plugin) could have a similar origin...

Good! I'll try it today. 

-Alexandre

(In reply to Alex Couture from comment #10)
> This Asus EEE X101CH seems to be an interesting case...
> I often have bug that other users does not have at all.
> What could be the cause?

I suspect your particular use case is the cause, not the hardware.  This is a good thing; you are testing code paths that most other TDE users apparently do not use on a daily basis and are therefore helping to keep the overall quality of the project high.

What is the current status of QtCurve on R14 from your perspective?  I don't see any real issues aside from combo lists sometimes remaining depressed after a user has clicked on the combo list and selected an item.

Thanks!

Hi,

I have never seen that trouble with combo lists, but it might be that it has not drawn my attention.

I'd say that the state of QTCurve is what I judge at 8/10, compared with 9/10 on 3.5.13.2. But it is certainly useable with many kinds of qtcurve configs without making TDE R14 crash, as it was months ago, to what I would have judged to 4/10. This is much better!

I don't have the file with me right now, but I'll try to provide a qtcurve config file that still has in some occasion little glitches, such as the gradient not drawn on the background of some icons on toolbars when the background of toolbars is set to have a gradient.

Thank you!
-Alexandre

Created attachment 2350 [details]
evaRounded qtcurve theme

Hi,

Can you test this QTCurve theme on your computer, to see if it has the described toolbar glitches for you?

-Alexandre

(In reply to Alex Couture from comment #15)
> Created attachment 2350 [details]
> evaRounded qtcurve theme
> 
> Hi,
> 
> Can you test this QTCurve theme on your computer, to see if it has the
> described toolbar glitches for you?
> 
> -Alexandre

That theme gave me all sorts of glitches in the popup menus; thanks for providing it as I can now debug more easily!

Oddly enough when I fired up Kate the toolbars were painted perfectly fine with the gradient in the background as intended.  What application(s) were you seeing the toolbar gradient issue in?

Thanks!

(In reply to Alex Couture from comment #15)
> Created attachment 2350 [details]
> evaRounded qtcurve theme
> 
> Hi,
> 
> Can you test this QTCurve theme on your computer, to see if it has the
> described toolbar glitches for you?
> 
> -Alexandre

Glitches fixed in GIT hashes b11ba44 (qt3) and 38755f9 (tqt3).

Are there any other regressions I should be aware of at this time?

Thanks!

Combobox glitch fixed in GIT hashes 444ac1f (qt3) and bdc8377 (tqt3).

At this point are there any remaining regressions in QtCurve?

Thanks!

(In reply to Timothy Pearson from comment #18)
> Combobox glitch fixed in GIT hashes 444ac1f (qt3) and bdc8377 (tqt3).
> 
> At this point are there any remaining regressions in QtCurve?
> 
> Thanks!

Looks like I may have spoken too soon.

I can currently trigger the combobox bug with ~50% reliability by opening the Kicker configuration dialog, clicking on the panel size combobox, and selecting an item from the bottom of the drop-down list.  Can anyone else confirm this behaviour?

Thanks!

(In reply to Timothy Pearson from comment #19)
> (In reply to Timothy Pearson from comment #18)
> > Combobox glitch fixed in GIT hashes 444ac1f (qt3) and bdc8377 (tqt3).
> > 
> > At this point are there any remaining regressions in QtCurve?
> > 
> > Thanks!
> 
> Looks like I may have spoken too soon.
> 
> I can currently trigger the combobox bug with ~50% reliability by opening
> the Kicker configuration dialog, clicking on the panel size combobox, and
> selecting an item from the bottom of the drop-down list.  Can anyone else
> confirm this behaviour?
> 
> Thanks!

This boiled down to a really stupid typo in the CEF structure definition, thereby assigning two different widget states the same numerical ID.

Fixed in GIT hashes f6b53fc (qt3) and 3aba060 (tqt3).

Please let me know if there are any unresolved QtCurve regressions vs. KDE 3.5.10 at this time.

Thanks!

Hi,

I will probably have time to try the updated TDE R14 system at the beginning of the week.

I don't know exactly how it works, but would it be possible to add the provided QTCurve theme to the list of predefined styles? Also, I have another QTCurve config file that is from KDE Plasma 5, which is made to look more ''flat''.
I'll try to upload it soon!

-Alexandre

Created attachment 2352 [details]
Breeze (KDE Plasma 5) QTCurve theme

Here it is!
-Alexandre

(In reply to Alex Couture from comment #22)
> Created attachment 2352 [details]
> Breeze (KDE Plasma 5) QTCurve theme
> 
> Here it is!
> -Alexandre

Sure, why not.  Added in GIT hash a3fbecd.

Hi,

Cannot update my system, because system is not able to fetch everything with ''apt-get update'' 95% of the time. When it can and I try to update the system, it says error 404 on most packages even if my internet conection is fully working... 

My opinion is that PCLinuxOS rpm package management is far more reliable and simple to use than debian package management. Did you saw that 80% of what is written on the trinity-user mailing list is about messed-up debian package management?

Test back later...
-Alexandre

(In reply to Alex Couture from comment #24)
> Hi,
> 
> Cannot update my system, because system is not able to fetch everything with
> ''apt-get update'' 95% of the time. When it can and I try to update the
> system, it says error 404 on most packages even if my internet conection is
> fully working... 
> 
> My opinion is that PCLinuxOS rpm package management is far more reliable and
> simple to use than debian package management. Did you saw that 80% of what
> is written on the trinity-user mailing list is about messed-up debian
> package management?
> 
> Test back later...
> -Alexandre

I agree, RPM is better than dpkg, but here I doubt that dpkg is the issue: 404 isn't a dpkg error, it's an HTTP error that means something along the lines of "I can't find the file you're requesting on the server you're telling me to download it from". The packages are being built (else apt wouldn't be aware of them because they wouldn't be added to the package lists), but for some reason they're not being made available for download.

Make sure that the non-TDE packages on your system are fully upgraded, make sure you have an alternate DE or window manager ready, then try this double-command (prefix them with sudo if needed):

apt-get update && apt-get --fix-missing dist-upgrade

That will cause it to look at what it *can* download, and install/upgrade the packages which aren't missing dependencies. The net result is, it won't upgrade the packages that it can't download, but it should install (most) of the packages it can upgrade.

With any luck, it should be able to upgrade your qtcurve package so you can continue testing.

Hi,

I've finally been able to update my system, but it seems like the packages has not been rebuilt yet, since the added ''Breeze'' QtCurve theme is not yet appearing in the list of pre-defined styles and I still have the glitches.

I is possible to add the evaRunded QtCurve theme too?

-Alexandre

Hi,

I forgot to add: Do you have this problem, where when the QtCurve theme is changed, the TDE panel loose its transparency and gets back to plain gray?

-Alexandre

Comment on attachment 2350 [details]
evaRounded qtcurve theme

Pushed to GIT in hash bdb6798.

(In reply to Timothy Pearson from comment #28)
> Comment on attachment 2350 [details]
> evaRounded qtcurve theme
> 
> Pushed to GIT in hash bdb6798.

Theme installation fixed in GIT hash a1093ee.

(In reply to Alex Couture from comment #27)
> Hi,
> 
> I forgot to add: Do you have this problem, where when the QtCurve theme is
> changed, the TDE panel loose its transparency and gets back to plain gray?
> 
> -Alexandre

Just got around to checking this.  Yes I do; this only happens after I click Apply in the style TDEControl module though.  The actual transparency setting is unchanged so I would hazard a guess that Kicker's reload code is resetting the internal transparency flag to false instead of re-reading it from disk.

(In reply to Timothy Pearson from comment #30)
> (In reply to Alex Couture from comment #27)
> > Hi,
> > 
> > I forgot to add: Do you have this problem, where when the QtCurve theme is
> > changed, the TDE panel loose its transparency and gets back to plain gray?
> > 
> > -Alexandre
> 
> Just got around to checking this.  Yes I do; this only happens after I click
> Apply in the style TDEControl module though.  The actual transparency
> setting is unchanged so I would hazard a guess that Kicker's reload code is
> resetting the internal transparency flag to false instead of re-reading it
> from disk.

On further investigation it seems that the KRootPixmap instance is unable to load the background wallpaper after the QtCurve style is changed (krootpixmap.cpp:301).  This may have to wait for a post-R14 release.

Hi,

Yes, for the panel transparency issue, it is not very important to solve right away, since you only have to cycle the transparency option tick box in Control Center.

I still have some part of toolbars where the gradient is not drawn under some icons with the evaRounded QTCurve theme. The bug don't seem to be reliable (well...) 

Kate: Toolbar gradient drawn perfectly
AmaroK: Toolbar gradient drawn perfectly, except under the Clear list icon
DigiKam: Toolbar gradient drawn perfectly
Dolphin: Changes from time to time: Sometimes perfect, sometimes the background of half of the icons is OK, sometimes the gradient does not go as far as the right part of the window.
Konqueror: Changes from time to time: Sometimes perfect, sometimes the background of some icons is not drawn.

By not drawn I mean that it is only plain gray, so this is not a big glitch.
Also, I don't see anymore the glitch of the long menus, so this part is OK.

-Alexandre

(In reply to Alex Couture from comment #32)
> Hi,
> 
> Yes, for the panel transparency issue, it is not very important to solve
> right away, since you only have to cycle the transparency option tick box in
> Control Center.
> 
> I still have some part of toolbars where the gradient is not drawn under
> some icons with the evaRounded QTCurve theme. The bug don't seem to be
> reliable (well...) 
> 
> Kate: Toolbar gradient drawn perfectly
> AmaroK: Toolbar gradient drawn perfectly, except under the Clear list icon

This one I had tracked down to an old KDE 3.5.x-era bug in Amarok, but I did not yet have a chance to fix.  I don't remember the bug number offhand, but it also involved tdepim and a search on this tracker for "amarok" should turn it up eventually.

> DigiKam: Toolbar gradient drawn perfectly
> Dolphin: Changes from time to time: Sometimes perfect, sometimes the
> background of half of the icons is OK, sometimes the gradient does not go as
> far as the right part of the window.

This sounds like a bug in the style engine and a probable regression from the KDE 3.5.x era.  Someone will probably have to run a regression check on this to isolate when it appeared.

> Konqueror: Changes from time to time: Sometimes perfect, sometimes the
> background of some icons is not drawn.

Same as above.

> By not drawn I mean that it is only plain gray, so this is not a big glitch.
> Also, I don't see anymore the glitch of the long menus, so this part is OK.

Glad to hear it!

So the remaining issues appear to be:
1.) Taskbar losing transparency due to wallpaper export glitch.  I have tracked this down to an apparent bug in kdesktop; killing and relaunching kdesktop is sufficient to restore the transparent panel (no need to flip settings).
2.) Certain toolbars not drawing background reliably or at all
3.) (just noticed this) QtCurve crashes when the Milk theme is selected (crash ID TDECRSH-9811cf4-e9fd7eb-f7f986e-371df3b-54bb0c1-d7739db-f43b165)

Did I miss anything?

Thanks!

Hi,

Looks like it is okay for me! But I might say that I can confirm that these glitches are not present at all on PCLinuxOS with TDE 3.5.13.2, except for the bug where the taskbar loose its transparency.

By the way, I finally sold my HP Proliant server for 100$


-Alexandre

I am actually using QtCurve right now and I'm experiencing the panel transparency issue. I can't get transparency work by toggling the setting, killing/restarting kdesktop, or re-logging/rebooting. If there's a config file I should attach, or some setting to look at to test, I can check for it.

By toggling the setting, I mean:
1.Turn it off, press apply
1.Turn it back on, press apply.

(In reply to Alex Couture from comment #36)
> By toggling the setting, I mean:
> 1.Turn it off, press apply
> 1.Turn it back on, press apply.

And that's also what I mean.

Hi,

Just a head-up on this problem: On Ubuntu 14.10 with TDE R14 most recent nighlty build, when you have the 100% default Kubuntu settings, as when a new user is created, there are still lots of gradient issues on toolbars. An example of a very visible one is in Dolphin, where some toolbar gradients should be drawn from top to bottom, but are drawn from left to right. There is still many unclear issues with QtCurve.

Thank you!
Alexandre

Created attachment 2503 [details]
QtCurve glitches

(In reply to Alex Couture from comment #39)
> Created attachment 2503 [details]
> QtCurve glitches

From here, that looks normal aside from the non-white background in the text area KATE (I reported that awhile ago, though it doesn't seem to show in the search results, I'll have to try searching again later when I'm not tired). Perhaps you can point out where in the screenshot we're supposed to be looking, and what the glitch is we're looking for?

Hi,

Take a look at the toolbar. The normal behavior would be to have the gradient visible under some of the icons from the left side of the wind up until the right side. Now, it is only half working with some settings, probably due to things like gradient using the same memory address as other apps.

Thanks!
-Alexandre

Hi,

Here is another screenshot of the bug.
It is on PCLinuxOS with TDE R14.0.1, but it acts the same on Ubuntu.

THe gradient for the rest of the toolbar is not even drawn in the right direction.

Thank you!
-Alexandre

Created attachment 2553 [details]
QtCurve using EvaRounded settings with bug

Hello, my name is ''Visual glitches when QTCurve is used on R14 nightlies'' bug.
I'm still there!