Version: (using KDE Devel) Installed from: Compiled sources OS: Linux The "edit identity" dialog window has a problem on the tabs: if the window is at a small size and the tabs are too wide, there appear tho small buttons "<" and ">" for navigate through the tabs, but this two buttons are over the latest tab label. See the screenshot for an example.
Created attachment 22065 [details] tabs problem
Created attachment 22066 [details] same behavior in konqueror Maybe it is not a kmail bug? There is the same behavior in konqueror :-(
This bug is indeed not KMail specific, it seems to be an oxygen bug. Reassigning to kdelibs (what is the correct place for oxygen bugs?) and adding Casper to the CC list.
known bug actually
On the latest revision the arrows are going better. The "button" style is ok.
The bug is there as of today. See screenshot. Furthermore if you scroll the tabs to right, a black line will appear on the left.
Created attachment 22931 [details] The arrow bug in Konqueror
Created attachment 22932 [details] The black line bug in Konqueror
The black line is already reported. The "buttons" over the tab are the fix against the original bug report.
*** Bug has been marked as fixed ***.
And do you think the current way of drawing is good??
I don't like to play ping-pong with the reports, but the current way of drawing the arrows is simply wrong. See the Konqueror screenshot and compare with the one using the Plastique style.
Created attachment 22989 [details] Tabwidget arrows in Plastique
I think the problem is how Oxygen draws the QToolButtons, namely it draws a *smaller* rectangle for their background then it is requested. void OxygenStyleHelper::fillSlab(QPainter &p, const QRect &rect, int size) is the place where the rectangle is drawn. The size argument is never used, but it defaults to 7 and it shrinks the rectangle with s = double(size) * (3.6 + (0.5 * _slabThickness)) / 7.0; If I calculate correctly this is 3.825 . This is why there is a gab between the two arrows as the two arrows are actually two QToolButtons with half size. Not doing this shrinking fixes the problem and I didn't see other artifacts (actually there shouldn't be any if one draws the rectangle on the size it was requested. Anyway, one who know why that was there should review it, but this proves that the problem is in this case in the style itself.
Well how we draw buttons shouldn't (ideally) affect how this looks Also you have gone too far down into the code, but still yeah the reason it looks as it does is because we draw less than the size. It does have artifacts (no focus or hover being drawn on any button) so changing this is not an option. I maintain it's a qt problem.
If you draw a button smaller than it should, that *is* a problem. Why should be this a Qt issue (and what would be the problem with Qt in this case)? Qt (or KDE, whatever) requests to draw two button, let's say one from position 0,0 until 16, 16, the other one from 16,16 to 32, 32, and you draw one from 2,2 to 14, 14 and from 18,18 to 30,30. At least the area where you don't draw needs to be cleared. I also get focus effect on hover on buttons with this patch. I don't understand your comment that I've gone too far down in code... When you try to find the reason of a bug, you do that, right? And I did so I can find what can be the problem with QToolBar, KToolBar, QStyle, KStyle or the Oxygen style. And it turned out that only Oxygen style has this bug, because of the above.
Andràs, would you write a small patch with your idea so I can test it? I don't know if this is a Qt bug or a KDE one, but fixing it is a good idea. An initial fix could be the Andràs patch, and a furter step could be check who should manage correctly this type of buttons (Qt or KDE?). Anyway, the problem occours only with oxygen so this is more probabily a oxygen style bug, not a Qt one. But I'm not so expert to decide this. Thanks.
I wouldn't call a good patch, but I attached what I was talking about, in regards of the code. Just apply it to kdebase/runtime/kstyles/oxygen, and restart your KDE. Let us know if you see artifacts or other issues. I'm running it since I found the reason, and I see no problems.
Created attachment 23133 [details] Ignore, wrong upload...
Created attachment 23134 [details] Patch that makes the tab scroll buttons cover the tabs completely
Ok the patch is wrong in that it paints outside the button, where we want the background to shine through. And herein lies what is wrong with qt, as they don't make sure that the background looks nice, assuming that the button will cover it all One workaround would be to make the buttons larger as a special case in the tabbar. We would loose glow though.
Created attachment 24560 [details] this patch should make the background render correctly
Created attachment 24561 [details] background rendered correctly
Created attachment 24562 [details] this patch should make the background render correctly V2
Comment on attachment 24562 [details] this patch should make the background render correctly V2 sent all my patches to boemann :)
commited
Sorry, this is not fixed. See screenshot from today's trunk.
Created attachment 25037 [details] The problem as of 1st of June
Hm, probably the libs were not reloaded, now after a reboot it works.
*** Bug 163621 has been marked as a duplicate of this bug. ***
Bug is present in trunk. :( No need for a new screenshot, it is like in the last one.
Created attachment 28834 [details] correct tab arrows on r889158 @Andras: which revision are you using? Are you really sure that you've compiled and installed correctly? This is a screenshot using r889158.
Revision: 888742 and I have no reason thinking it is not installed correctly. Current screenshot follows.
Created attachment 28835 [details] Arrows as of 25/11/2008
Very strange, I hope devs could help us!
I can't confirm either. It looks like Finix' screenshot here as well. I'll let you close the bug again
It still works for me to.