Bug 1800

Created attachment 1798 [details]
Image of malformed Kompare 'Compare' button

What widget style are you using?

>What widget style are you using?
KDE Classic

This started recently. Because of all the patching the past week, I made no new package set until yesterday. My guess then is the regression happened after Dec. 18. Possibly all of the kdewidget->tdewidget renaming?

Not all apps are affected. The screen capture was from kompare.

Interesting observation. Looks like this bug has been latent for a long time.

I reinstalled my package set from Dec. 18. I have "Show icons on buttons" enabled in kcontrol->Appearance & Themes->Style->Widget Style.

In kompare, the Compare button does not show an icon but the Cancel button does. I cannot tell whether the icon is clipped or is not enabled.

Possibly the bug is localized to specific apps, but seems the first place to look for a potential pattern is how kompare displays the buttons.

Several widget sets do the same as KDE Classic with the kompare buttons:

.Net Style
Platinum
Asteroid (no icon)
B3/KDE
CDE
Compact
HighColor Classic
etc.

This is indeed a latent bug exposed by recent patches. In 3.5.13.2 and 3.5.10, the Compare button in Kompare does not show any icon while the Cancel button does. Whether the icon is clipped or not showing at all I don't know. So only in R14 will we see this mangled button appearance and only since the patching of the past week or so.

I suspect only tdesdk apps are affected. All tdesdk seem to be using a non standard method for dialog buttons.

It seems that there are more glitches in the rendering.
See bug 1693 and bug 1692.

Since filing the report, the only place I notice the button glitch is with kompare. That is why I changed the bug report summary.

Apps that use the dialog libraries from tdelibs do not have this problem on my system.

The button icon bug is a latent bug that recent patches exposed. Because of that observation (comment 5 and comment 7), I do not think this bug is related to 1693, although finding a remedy for 1693 would be nice too. :)

I wonder: How the recent wave of patches exposed this latent bug I don't know, but could the button icon glitch be related to the number of characters in the button? In kompare, the "Compare" button often is an "OK" button in most common dialogs. The word "Compare" is 7 characters. If I knew exactly where in the kompare sources the word "Compare" is passed to the dialog, I could experiment with character lengths.

I can't replicate this on my hacked-up test box (various versions of multiple components compiled at differing times against differing versions of other components).

I'm not saying it doesn't exist, but I will need to wait for the build farm to finish its tdesdk build for my stock Debian test box before I can analyze this further.

I ran some proof-of-concept tests.

In the tdebase minicli, I changed the Run button to RunRunRun. The button displayed the icon and text with no crunching.

In kompare, I changed the Compare button text string first to 'Comp' and then again to 'Compar'. In both tests the button icon and text did not crunch, but with 'Compar' the 'r' is clipped at the right side of the button.

I found another instance of a malformed pushbutton: khelpcenter->Settings->Build Search Index. Notice the 'Build Index' button is crunched with the 'B' and 'x' both clipped.

Another example is the standard Find and Replace dialog. The text string 'Replace' is crunched. In kate, the associated Replace Confirmation dialog is affected with the 'Find Next' button crunched.

The commonality seems to be using the 'setButtonOK' method, which is found in tdelibs/tdeui/kdialogbase.cpp:894. The problem would seem to be how the button resizes:

d->mButton.resize( false, 0, spacingHint(), mButtonOrientation );

Thus the bug is not limited to tdesdk and I am updating the bug report summary.

Images attached. I'm still using KDE Classic widgets, but that does not really matter.

Created attachment 1808 [details]
Image of malformed Find&Replace 'Replace' button

Created attachment 1809 [details]
Image of malformed khelpcenter 'Build Index' button

Created attachment 1810 [details]
Image of malformed Replace Confirmation 'Find Next' button

Created attachment 1811 [details]
Image of minicli Run button modified without malformation

Additional testing indicates all pushbuttons with long text strings all resize correctly when icons are not used.

In summary, one of the recent patches exposed a long standing latent bug. The bug is that pushbuttons will not display correctly when icons are enabled and the button is displayed through the setButtonOK method.

The button will resize but will be crunched or clipped. The setButtonOK method now displays buttons normally only when icons are not used.

The bug never appeared previously because when the setButtonOK method is used, icons never displayed even when configured as such. One of the recent commits caused icons to be displayed in the buttons.

I tested this on 3.5.10 and 3.5.13.2. When icons are enabled in pushbuttons, all dialogs using the setButtonOK method do not display icons. Would be interesting to know whether this has always been an unknown latent bug or a work-around hack to avoid the crunching problem.

Seems the solution will be to fix the setButtonOK method to accommodate icons correctly.

I'm curious which recent commit exposed this latent bug.

I ham having great difficulty replicating this.  Can you please post a screenshot of the Fonts TDE control module on the system that is showing these symptoms?

Fundamentally this is probably the font metrics going wrong somewhere, but I need to be able to replicate this before I can fix it.

Created attachment 1840 [details]
Image of kcmfonts and kcmstyle

(In reply to comment #19)
> I ham having great difficulty replicating this.  Can you please post a
> screenshot of the Fonts TDE control module on the system that is showing these
> symptoms?
> 
> Fundamentally this is probably the font metrics going wrong somewhere, but I
> need to be able to replicate this before I can fix it.

Darrell, Tim,
about a week ago I could reproduce the same problem (no icon on the Compare button of Kompare). But now the icon is displayed correctly.
Last Sunday I switched from Plastik to QtCurve widget style, but now even if I switch back to Plastik I can not reproduce the problem any more, the icon on the Compare button of Kompare is displayed correctly.

>Last Sunday I switched from Plastik to QtCurve widget style, but now even if I
>switch back to Plastik I can not reproduce the problem any more, the icon on
>the Compare button of Kompare is displayed correctly.
Plastik is not one of the affected widget styles. Refer to comment 6 for a starter list of affected widget styles.

At least one patch after Dec. 18 exposed this latent bug. The bug always existed but previous to Dec. 18, even when enabled, icons never displayed in pushbuttons using the setButtonOK method. Icons did display in other pushbuttons not using the setButtonOK method.

As I shared in comment 7, the icons did not display in setButtonOK pushbuttons in 3.5.x, even when enabled. This also was the behavior in R14 until about Dec. 18 when at least one patch exposed this latent bug.

Only certain widget styles and only setButtonOK method buttons are affected.

(In reply to comment #3)
> This started recently. Because of all the patching the past week, I made no new
> package set until yesterday. My guess then is the regression happened after
> Dec. 18. Possibly all of the kdewidget->tdewidget renaming?

I think this problem is related to the problem of bug 1857.
The time of this bug report is very suspicious.
Darrell, using the same two sets of packages that you use for testing bug 1857 (Dec 16 and Dec 22 I think), could you verify that this problem has a similar pattern (ok in Dec 16 and not in Dec 22)? Thanks.

Using previous package sets won't help exactly.

As I mentioned in previous comments, until the bug was exposed the buttons using the setButtonOK method never showed icons, even when the user explicitly enabled icons in the buttons. With the older package sets all I will see is a button with no icons.

As I mentioned in comment 22, at least one patch after Dec. 18 exposed this bug. The bug likely is a latent bug that always existed. Not until exposure from that period did setButtonOK method buttons actually show icons in the buttons. Therefore nobody knew the bug existed.

I cannot test this in 3.5.10 or 3.5.13.2 because in those releases all buttons using the setButtonOK methood did not show icons despite being explicitly enabled.

That now icons finally showed in the setButtonOK method buttons is good. The latent bug that exists with the setButtonOK method buttons never worked but nobody knew that.

If buttons using the setButtonOK method had always showed icons then this bug would have been exposed long ago and probably fixed long ago. The fact that the setButtonOK method buttons never showed the icons masked the bug. Nobody ever complained that the icons were not displayed in certain buttons.

That said, I tested the December package sets. I narrowed the exposure of the latent bug to about between Dec. 17-18 (I started building the package set late Dec. 17 and finished Dec. 18) and Dec. 22.

To iterate: with the package set started on Dec. 17, I see no icon in any button using the setButtonOK method. With the package set built Dec. 22 I see icons, but the icons do not display correctly in the buttons.

The bug affects setButtonOK method buttons only. I have no idea whether this is related to bug 1857.

(In reply to comment #24)
Thanks Darrell (as usual :) ).
I think you are right: the bug was already there before and nobody noticed. Then it was exposed by the changes discussed in bug 1857

Created attachment 2282 [details]
Kompare using Classic style

Created attachment 2283 [details]
Kompare using Platinum style

I'm not sure this bug is still valid with the latest GIT sources.  I tried to reproduce the problem today using latest sources and using two different widget styles on your list of problem styles (see Attachment 2282 [details] and Attachment 2283 [details]); Kompare never displayed an icon on the affected Compare button.

Can you please verify that the bug is still present on your system at this time?

Thanks!

Now there is no icon at all in the Kompare Compare button, but an icon appears in the Cancel button. That is a nominal improvement over the way the icons were misaligned, but not appearing at all does not seem like the correct solution. Am I missing something?

I don't remember committing anything to disable the icon, so I suspect the bug that led to its (obviously broken) appearance was fixed somewhere along the line.

As a matter of policy determination, if we want to specify an icon that should appear on such dialogs, that should be handled in another report.  Right now I see consistent behavior across all widget styles in my tests, and consistent behavior with KDE 3.x not to mention TDE 3.5.13.x, so I think this particular  bug can be marked as RESOLVED FIXED.

Thanks for reporting!

>I don't remember committing anything to disable the icon, so I suspect the bug
>that led to its (obviously broken) appearance was fixed somewhere along the
>line.
This is latent bug that was long masked, going back to KDE 3.5 days.

That there is again consistency is good, but the consistency is the same as before, as reported in comment 7. That is, now no icon shows at all in the non-Cancel buttons, despite the user configuring icons in buttons.

In comment 12 I reported the bug seems to affect only those buttons using the 'setButtonOK' method.

That the icons no longer are malformed in those buttons is good, but there is no icon at all.

I don't think it is correct to close this bug. The bug was reported because some icons were not displayed on push buttons when they should (see Darrell's comment 18). IMO we should reopen it and fix it properly.
Darrell, if you also agree, please reopen the bug.

Not having any icons is better than malformed icons, but the icons should be displayed. I don't know why buttons using the 'setButtonOK' method should be exempted from showing icons.

> Not having any icons is better than malformed icons, but the icons should be
> displayed.
Agreed. As a "solution", let's follow Tim suggestion and file a separate bug report for "Icons are not displayed on some push buttons".

While investigating Bug 2143 I found the commits that fixed this bug--GIT hashes 3a40adf (qt3) and 48f56c4 (tqt3).  Basically this report was another (rarer) manifestation of Bug 1857, but one that accidentally showed how nice it would be to have icons on our default buttons.

It was caused by an icon being set on creation, then unset later by the application author (see Bug 2143).  As TQt3 was ignoring the unset requests and displaying the icon anyway, the icon could overrun the text in the now too-small pushbutton area.