Image 01
profile-image

hoodedone

Raymond 
Sorry, meant to say specifically that I'm using openSUSE, so it doesn't appear to be a Slackware packaging issue. - Aug 26 2009
I'm seeing the same thing on anything less than KDE 4.3. - Aug 26 2009
So with 0.66.1, KDE4 "Extra" scrollbars are slightly more rounded than "Fully" scrollbars, but they're still not as rounded as GTK2 "Extra" scrollbars (which are the "proper" amount of roundness in comparison with 0.65) - Jul 22 2009
My roundedness is set to "Extra", but KDE4 won't go beyond "Fully" for scrollbars any more. GTK2 scrollbars are still nice and round.

Also, I'm not sure if right-aligning the section names (General, Group Boxes, Combos, etc.) in the prefs dialog is intended by the HIG. It looks a bit weird to me at the moment. - Jul 20 2009
KWin decorations seem to break across major versions of KDE. Make sure your QtCurve is compiled against 4.3. - Jul 08 2009
Does the new fix still require "-DQTC_FIX_FIREFOX_LOCATION_BAR=true"? Thanks. - Jul 02 2009
Unfortunately, I just realized that 0.65.0 has brought the return of the ugly border around the little icon boxes on the left of the address bar and search box. :( I just double-checked and it's fine in 0.64.2.

As a side note, when I was playing around with different GTK themes and Firefox, I noticed that something had put the path to QtCurve's gtkrc file in my $GTK2_RC_FILES. I know QtCurve didn't do it (though I searched through the source files to be sure) so I'm wondering if you happen to know what does that.

I *really* hate how there are a million different ways to change the GTK theme, and every config utility uses a different one, so they all conflict. Die in a fire, GTK. - Jun 26 2009
I accidentally changed the "Default button" setting, and I forgot that for KDE, "focus" and "default" go hand-in-hand for buttons. - Jun 25 2009
For buttons (but not combo boxes) KDE4 seems to apply the "fill" color on focus in addition to whatever the chosen focus setting is. - Jun 24 2009
First of all, I can confirm that this release fixes all the specific problems I've found so far, including setting the focus and hover colors properly in KDE3 Thanks!

However, I'm a bit unclear as to the intended behavior of the *other* colors in KDE3. In your last message to me, you said that under KDE4, the style "should use the KDE4 colour scheme - and the KDE4 default colours for hover/focus" I interpreted the "and" to mean that it should pick up all the KDE4 colors, but based on the source code and the actual behavior, this isn't the case. So just to be clear, this is the intended behavior for this version? If so, is changing KDE3 to get all its colors from KDE4 on the roadmap for the future? (I realize that it wouldn't be a quick fix, so no rush.)

In the meantime, I decided to try the "export colors" function. Exporting to Qt3 worked just fine, but when I exported to KDE3, it wrote the KDE3 color roles to my KDE4 kdeglobals. I moved the relevant lines over to my KDE3 globals, and nearly everything was ok. The final hitch was K3b: apparently the default theme uses the activeBackground and activeForeground colors from the [WM] section, which the exporter doesn't touch.

While I was looking through the source of qtcurve.cpp for KDE3, I found two possible bugs, though one of them wouldn't affect me at all, and I haven't run into the other one:

- at line 334, kdeHome() is called with no value, which results in trying to find kickerrc in KDE4's kdehome, which will probably fail.
- conversely, at line 7312, kdeHome(true) is called in a section that's supposed to be following KDE4 settings.

Both of these are probably holdovers from the previous version, where the default for kdeHome() was flipped.

Finally, one drawing bug I found that may or may not be new. In KDE4, with roundedness set to Max and button effect set to Etched or Shadowed, buttons have a small patch of white at each corner. I normally have my round setting at Extra, so I might not have noticed this before. - Jun 24 2009
For the purposes of making this image, I set my focus color to red and hover color to green: http://img208.imageshack.us/img208/2866/qtcurvehighlights.png

From top to bottom, we have:
- Normal
- Hover, no focus
- Focus, no hover
- Focus + Hover

And here is my qtcurvestylerc: http://pastebin.com/m472356a9 - Jun 17 2009
I figured out what was causing the colors issue I mentioned in my message last week. I am running in a KDE4 session, with my KDE config files in ~/.kde4, but *without* KDEHOME set. (This is the default configuration in openSUSE.) Under these conditions, the KDE3 version of QtCurve will not see my KDE4 config files. I saw in the source a TODO comment about using kde/kde4-config like the Gtk2 theme does. Since Gtk2 gets the colors right, I'm assuming this is the proper fix, so hopefully this can get in the next version.

While I was experimenting with that, I found another problem. In KDE4, when the focus decoration is set to full-size highlight or highlight & fill, the focus color takes precedence over the highlight color. KDE3 and Gtk2 correctly use the highlight color instead.

Also, I noticed that when the scrollbutton style is flat, disabled scrollbars look funny, due to the sudden shift in background color. (For example, the horizontal scrollbar in Kate most of the time.) Oxygen's flat scrollbuttons use the regular background color, which I think looks a lot better.

Finally, there is a problem drawing spinboxes in GTK, or at least in Pidgin. When a spinbox that starts out as disabled gets enabled, or vice-versa, it looks like crap. This can be seen in the Preferences under either the Network or Status/Idle tabs. - Jun 15 2009
I'm loving the new options, especially for the window decoration.

Here are the bugs I've found so far:

- The setting for checks/radios color behaves weirdly in both the KDE3 and KDE4 config modules. In KDE4, setting it to "Selected Background" causes the mini-preview to show up fine immediately afterward, but everything else uses the "Text" setting instead. When I open up the config dialog again, the combo box is blank. Using the KDE3 module, choosing "Selected Background" gets the proper option written to the config, and all apps pick up on it, but opening the dialog again shows "Text" in the combo box.

- Ditto for the menu stripe setting. In KDE4, both the "Blended Selected Background" and "Custom" settings are immediately discarded in favor of the "None" setting. "Darken" and "Selected Background" work fine. With KDE3, "Custom" behaves the same as KDE4. I am able to set "Blended Selected Background" as an option, but it still doesn't work. Furthermore, when the config dialog is opened again, "Blended Selected" is still selected, but the gradient combo box is disabled.

- Really weird little one: In the KDE3 config module, on the Menus and Toolbars page, the spinbox for the menu background has the % in *front* of the number. The spinboxes on the Mouse-over and Custom Gradients pages show up properly.

- In the KDE4 window decoration, the maximize/restore button is "stuck" on whatever it was showing when the QtCurve decoration was activated. Switching to another decoration and back updates everything to the proper button, but it still doesn't update on its own. I have not tried the KDE3 decoration at all.

- I'm not sure if this one is even a QtCurve bug. The other day I started up the KDE3 version of Kaffeine for the first time in a while, and I noticed that when I began playing a file, the *right* side of the progress slider was filled in. As soon as the slider moved the slightest bit, the right side was drawn empty, as it should be. I can't find any other sliders that do the same thing, and I can't find any other themes that fill in the left side of the slider to compare it to. So it may not be worth too much effort, but I thought I'd point it out while I remembered.

Thanks again for all the hard work.

(Also thanks to KDE-Look for eating my comment!) - Jun 08 2009
(I was wondering why the code had both runtime and compile-time version checks in the same place...)

For 0.61.4, I tried building against both 4.4 and 4.5, with the same results as far as I recall. (Though when I wrote my description above, I was definitely building against 4.5.) I only tried building 0.61.1 against 4.5.

Oh, and before I forget, I've noticed three other issues that aren't nearly as urgent, but I don't want to get lost in the shuffle:

1. When using the "button-like" (Grammar Nazi time: the label in the config dialog is missing the hyphen) appearance for checks and radios, there's little/no distinction for disabled controls. This isn't a problem when there's also text on the control that gets disabled, but for disabled controls on web forms, there's no way to tell the difference until you try to click.

2. In Dolphin on KDE 4.2, the free space indicator is no longer a progressbar, but some new widget. I believe I saw a developer refer to it as a "capacity bar". Anyway, whatever it is, QtCurve doesn't handle it, so it gets drawn in the Oxygen style instead. (The bar is no longer visible by default; you can enable it via General -> Show space information in Dolphin's preferences.)

3. Qt 4.5 has a new option in qtconfig -> Select GUI Style called "Desktop Settings", which is apparently the new default. I believe it means that under KDE, it uses your KDE theme and under GNOME it uses QGtkStyle. Anyway, under KDE with this option selected, qtcurve's gtk theme no longer picks up the proper colors. Fortunately, this one can be worked around by explicitly selecting QtCurve.

Sorry to hammer you with all this at once, but like I said, I didn't want to forget about them again. I really appreciate all the work you've put in on this great style. - Mar 05 2009
Update:

In 0.61.1, all tabs are drawn fine except for Arora's tabs (when they have an icon, i.e. blank tabs show up fine, too)

In 0.61.4, it's the exact opposite: everything is messed up except for Arora's tabs+icons.

So it's a safe bet that fixing Arora's tabs broke everything else. If it helps, here's how the bug was fixed in Oxygen: http://websvn.kde.org/?view=rev&revision=933838 (I can't confirm that it works 100%, as the fix was too late to make it into 4.2.1.) - Mar 05 2009
Oh, and while that's cooking, a bit more about what I've noticed of the problem: When the tab is text-only (like the tabs in systemsettings), the text is shoved to the left. When there's an icon, it looks as if the text is in the correct position, but the icon is shoved right. - Mar 04 2009
I'm seeing this too, with 0.61.4 on Qt 4.5.0. I thought it didn't happen with 0.61.3, but I've switched back and I'm still seeing it, so I'm super confused. Right now I'm building a copy of 0.61.1 (I don't have 0.61.2, and it's not on your server anymore) to check that one out. - Mar 04 2009
Haven't had time to fully test since I need to get to school, but I'll pass this on right away. I seem to be getting a crash in the GTK engine on readConfig(), whenever there's anything in qtcurvestylerc (even the defaults). - Apr 24 2008
Craig: I actually found this problem a while back, but after I fixed it for myself, I forgot to mention it here. Sorry.

Basically, at some point Firefox switched from requesting gtk-go-back to gtk-go-back-ltr (or -rtl as appropriate). For whatever reason, GTK isn't automatically translating the -ltr and -rtl requests to the underlying icons.

If you manually specify gtk-go-*-ltr and -rtl in the icons3/icons4 files, it works fine.

While I'm at it, I have two other changes I've made to my own copy of the icon mappings that I think should be considered:

- In the KDE3 mappings, gtk-home is set to filesystems/folder_home.png when actions/gohome.png seems more approprate (the KDE4 mappings use actions/go-home.png)

- The mappings for gtk-about both point to a KDE logo, which looks odd in that context. For the KDE4 mappings, actions/help-about.png is probably the most appropriate. For KDE3, actions/info.png looks like the equivalent of actions/help-about.png, but in my copy of crystalsvg, it is only provided in 16x16. This might not be a problem if the icon only appears in menus. Also, you appear to have your own fallback system in place, so maybe that could be used here. - Mar 02 2008
Also, I just saw the thing about newFirefox=true -- does this mean I no longer need the QTC_NEW_MOZILLA environment variable?

What is it supposed to do differently with vs. without, anyway? I haven't noticed anything. - Feb 28 2008
With the tab bar in Firefox 3, there are some weird painting issues related to tab scrolling. If you open enough tabs to fill up the tab bar, each time you open another one, it appears to get painted on top of the scroll and all-tabs buttons before getting moved over. The same thing happens if you click on a tab that's partially scrolled off the screen. Hovering over those buttons fixes it temporarily, but it does it again the next time. Interestingly enough, the problem does not happen if you scroll by clicking one of the buttons, or by using the mouse wheel.

Thanks a bunch for the arrow fix though. And of course for the great theme. - Feb 28 2008
I'm not sure what's the cause of your error, but the KDE:Backports repository just (finally) got updated to qtcurve 0.55.2, so you can download a package from http://download.opensuse.org/repositories/KDE:/Backports/openSUSE_10.3/repodata/repoview/qtcurve-kde-0-0.55.2-3.1.html - Jan 28 2008
Two calls to realloc() in qt_settings.c are missing the extra +1 for the string terminator. They are at lines 1477 and 1488. Fixing those seems to make everything run fine. - Sep 22 2007
If the setting for "checks/radios" is "selected background," the configuration dialog resets this to "text" every time it is open. - Jun 12 2007
Better Desktop Dropshadows

Various Stuff by abby 21 comments

The dcop call won't do it. It refreshes some things on the desktop, but doesn't redraw the shadows. BTW, right click -> Refresh Desktop does the same thing, for those who don't want to deal with the command line.

Restarting kdesktop would probably do the trick, but it'd be even more awkward for most people than just restarting KDE. - May 03 2004
Better Desktop Dropshadows

Various Stuff by abby 21 comments

This is very very awesome! Just yesterday I was cursing the horrible KDE drop shadows trying to get a good text/shadow color combination for the wallpaper here: http://www.kde-look.org/content/show.php?content=12352 but had to settle with something rather crappy. I had assumed that decent drop shadows were something that *might* make it into KDE 3.3, but now I don't have to wait. I haven't quite figured out what the perfect settings are for me, but I've restarted KDE enough for today.

A configuration UI would make this even better, as well as the ability to redraw the shadows without restarting KDE (possible wishlist items?), but this is a great start. - May 03 2004
KVisualBoyAdvance

Emulation by pistooli 34 comments

I'd been wanting something like this, since dealing with the command line anytime I want to load a rom is a bit ridiculous.

I think the textboxes for path and game directory should be editable, since it's just silly not to. Also, I want to run VBA through artsdsp, but the loader isn't accepting that as a valid command even when I manually put it in the configuration file.

Other things that would be nice are more of VBA's options, especially things like BIOS file and controller settings. - Jan 21 2004
8 .3
Mar 06 2009