[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: KDE/kdebase/workspace/plasma/applets/systemtray/protocols/fdo
From:       Fredrik =?iso-8859-1?q?H=F6glund?= <fredrik () kde ! org>
Date:       2009-01-09 1:23:53
Message-ID: 200901090223.54422.fredrik () kde ! org
[Download RAW message or body]

On Friday 09 January 2009 01:41, Aaron J. Seigo wrote:
> On Thursday 08 January 2009, Fredrik Höglund wrote:
> > So could you explain what you were trying to accomplish with this patch
> > so we can fix it properly?
> 
> according to ddenis who worked on the NET_SYSTEM_TRAY_VISUAL for Qt 4.5, the 
> old code was failing on 16bpp displays. well, i'll let him speak for himself 
> here:
> 
> [Thu Jan 8 2009] [03:55:29] <ddenis> Hi. I wanted to talk to about about the 
> NET_SYSTEM_TRAY_VISUAL atom - I've implemented support for it in Qt 4.5, 
> however I suspect that its implementation in the systemtray applet in kde is 
> not correct - in the fdo/fdoselectionmanager.cpp in the initSelection() 
> function the code that searches for the visual explicitely sets the color 
> depth to be 32 and the problem occurs when I try to create a systray icon 
> window with that visual on a 16bit display. As far as
> [Thu Jan 8 2009] [03:55:29] <ddenis> I can see the proper way is to get the 
> depth from the system and then try to find the ARGB-enabled visual with the 
> same depth on the same screen

The X server only creates one ARGB visual, and that visual is 32 bits.

> he provided a patch that he claimed worked for him in those situations, i 
> applied and tested it here as well ... but perhaps you can propose a better 
> solution that isn't an elaborate no-op? ;)

Well the patch is wrong for the above reason. I also don't understand
how it can make a difference, because as far as I can tell the code in
PlasmaApp::self() forces Plasma to use the ARGB32 visual regardless of
the display depth.

That means that this code won't be setting the hint to a 16 bit visual even
with this patch applied. (because QX11Info::appVisual() returns a 32 bit
visual).

The question here is if Qt fails to create the window, or if it succeeds in
creating it and the window fails to embed.

If it's the former, then the problem is in Qt, not Plasma. If it's the latter,
then the problem may be in Qt or it may be in Plasma.

Regards,
Fredrik

[prev in list] [next in list] [prev in thread] [next in thread]