U++ framework: Look and Chameleon Technology

Home » U++ Library support » Look and Chameleon Technology » Chameleon problems

Show: Today's Messages :: Polls :: Message Navigator
E-mail to friend

Chameleon problems [message #11144]

Wed, 22 August 2007 13:25

mrjt
Messages: 705
Registered: March 2007
Location: London

Contributor

I have attached two screen shots of the same U++ test program running on KDE 3.5.4. I have used a tool to change the GTK theme so that it matches the QT/KDE theme. This works perfectly in GIMP for instance.

There are two issues:
1) The only difference is the addition of the 'MT' compile flag to the second shot. I can see no reason why this should affect the theming, and there is no #define flagNOGTK anywhere in my source or uppsrc except one for OSX.

2) The scrollbar in the second shot is incorrect. Many of the KDE themes have the extra button on the right/bottom including the default one and GTK seems to support it. The extra button does not function here. If the scrollbar is disabled all the buttons are drawn in the right places, but do not appear disabled.

I've had a look at the source and it seems this might be difficult to fix, but let me know if you'd like me to do any further testing.

James.

Attachment: ChWnd1.png
(Size: 6.03KB, Downloaded 774 times)

Report message to a moderator

Re: Chameleon problems [message #11145 is a reply to message #11144]

Wed, 22 August 2007 13:27

mrjt
Messages: 705
Registered: March 2007
Location: London

Contributor

Second shot

Report message to a moderator

Re: Chameleon problems [message #11200 is a reply to message #11145]

Mon, 27 August 2007 10:45

mirek
Messages: 14291
Registered: November 2005

Ultimate Member

MT issue looks very strange. Any idea?

As for scrollbar, well, I got somewhat ready for that (multiple buttons), but has not finished the implementation....

Report message to a moderator

Re: Chameleon problems [message #11235 is a reply to message #11200]

Tue, 28 August 2007 16:05

mrjt
Messages: 705
Registered: March 2007
Location: London

Contributor

luzr wrote on Mon, 27 August 2007 09:45

As for scrollbar, well, I got somewhat ready for that

Cool. I thought I remembered something mentioned about this.

luzr wrote on Mon, 27 August 2007 09:45

MT issue looks very strange. Any idea?

Through trial and error it seems I have found the problem:

#ifdef flagMT
#ifdef COMPILER_MSC
__declspec(thread)
#else
__thread
#endif
#endif
MCache mcache[16];

(HeapImg.h:34, heap.cpp:186)
This code is the sole difference between correct/incorrect theming. With the '__thread' declaration theming is correct, without it always appears as 'Classic' style.

Next question is: Why?

Report message to a moderator

Re: Chameleon problems [message #11243 is a reply to message #11235]

Tue, 28 August 2007 18:05

mirek
Messages: 14291
Registered: November 2005

Ultimate Member

Interesting.

Hypothesis: our overloaded operator new/delete has a problem with Qt new/delete (this "thread__" variable is per-thread allocator cache).

Please, try with USEMALLOC to test this.

(OTOH, if this proves to be true, I would be really unhappy, because unless there is some magic way how to solve this, we have only two options - poor performance in MT or KDE compatibility... Smile

Mirek

Report message to a moderator

Re: Chameleon problems [message #11244 is a reply to message #11243]

Tue, 28 August 2007 18:50

mrjt
Messages: 705
Registered: March 2007
Location: London

Contributor

Unfortunately (or fortunately Smile

), USEMALLOC doesn't make a difference. Let me know if you'd like anything else tested.

Also, the following line:

#if (defined(TESTLEAKS) || defined(_DEBUG)) && defined(PLATFORM_POSIX) && !defined(PLATFORM_OSX11)

(Core.h:466)
needs '&& defined(UPP_HEAP)' adding to it before it will compile with USEMALLOC.

Report message to a moderator

Re: Chameleon problems [message #11247 is a reply to message #11244]

Tue, 28 August 2007 19:14

mirek
Messages: 14291
Registered: November 2005

Ultimate Member

Ops, I have missed that is actually WORKS with MT... (thought it is otherwise).

Well, this looks like very likely new hypothesis:

KDE is multithreaded and needs multithreaded memory allocator Wink

Actually, this could even explain some mysterious MacOS behaviour we have encountered recently too...

Anyway, this should USEMALLOC fix too (then it would use regular malloc and everything should be OK). This is really strange, with USEMALLOC, that mcache variable is #ifdefed out of code...

Report message to a moderator

Previous Topic:	QT
Next Topic:	progress bar not chameleonized

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat May 30 08:01:47 GMT+2 2026

Total time taken to generate the page: 0.00884 seconds