RFC: GUI style dependant frame width for KListView?

[Ingo Klöcker]

Hi,

I just committed a patch to KMail which makes the width of the frames of 
the different panes depend on the GUI style. With the Keramik style the 
width is set to 0 while with the dotNET style the width is set to 1. To 
be precise, the width is set to 
style().pixelMetric(QStyle::PM_DefaultFrameWidth)-1 .

Why this hassle? Because KMail in Keramik looks much better without the 
unnecessary frames. In Keramik compare KMail to a Konqueror window 
which has a list view right of a splitter. You'll notice that in 
Konqueror there's a two pixel wide grey line between the splitter and 
the list view. One of the grey lines belongs to the splitter and the 
other one is the frame of the list view. In KMail you'll only see one 
grey line which IMO looks much better. The problem now is that in 
dotNET the splitter doesn't have a darker frame. Therefore it's 
necessary for the widgets in the splitter to have a non-zero width 
frame. Thus we do the above in KMail.

My question is now whether it's desirable to add this behavior to 
KListView. In KMail I had to implement the above logic in three list 
views. Additionally a slot which is connected to 
KApplication::kdisplayStyleChanged() is necessary so that the frame 
width is changed if the new style requires another frame width. I can 
of course write a trivial sub class of KListView which implements this. 
But I wondered whether this wouldn't be useful for all applications 
which use KListView() (probably only for KListViews which are child of 
a QSplitter) especially since we are striving for a common good look of 
all KDE applications.

Of course, other widgets which are inside a QSplitter should probably 
have the same behavior. What would be the best way to achieve this?

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030913/44b7c263/attachment.sig>