Would it be possible for that pixel to not belong to the scrollbar? If it must (scrollbar being a rectangular area or something) can the scrollbar have a transparent pixel? Or can the border draw over the top of the scrollbar? Seems to work along the edges.
I obviously have no idea how you've worked the unified borders. I just figured what worked along the edges might work in the corner, and only pointed it out in case you hadn't seen it. Hope there's a solution there, but it really doesn't look bad as is. - Dec 14 2007
The only *minor* issue is with a light highlight color and the corners where there is a scrollbar. See image:
A bit of black border still shows through on the corners.
Also, with the bottom border of the scrollbar "erased" by the highlight color the scrollbar somehow looks really skinny :) That's not really an issue, just something to get used to with unified borders! - Dec 13 2007
As far as I can see, it should be in ~/.config/Polyester. Is that correct? If so, what is it named, and what does the structure look like? Could you post an example config file for the Qt4 version after having changed some values around in the config dialog or something? Would be much appreciated :) - Sep 24 2007
quoted for truth
Still using 0.5.5, from before color was added to sliders, sort order buttons and selected toplevel menu (and I always disable scrollbar color). It just seems like it's drifting into too-colorful-land, with no way to turn it off. - Jun 19 2006
Of course the fact that I went to the trouble to downgrade instead of uninstalling should tell you I like the theme. Just not the new menus ;)
Funny that the idea spread to Lipstik. Of course the next version of Lipstik had an option to make the menus smaller again (hint) - Dec 16 2005
Various KDE 1.-4. Improvements 453 comments
Why? This means I can no longer have KDE3 dialogs in Qt4 apps. This is something that was entirely possible with kgtk-0.9.0.
With that version I could get kde3 dialogs in gtk2, qt3 and qt4 apps. If this is not possible with cmake, then switching to cmake was IMHO a regression.
This is IMHO broken. Qt4 apps are becoming rather common, but most kde users are still with kde3. - Oct 25 2007
ln -s /usr/local/bin/kgtk-wrapper /usr/local/bin/gimp
ii. Make sure /usr/local/bin is before /usr/bin (or wherever gimp is installed) in your $PATH
iii. Now simply run 'gimp' - this should find the wrapper script first."
This no longer works. realApp=`which $app` returns /usr/local/bin/gimp, which is of course a link to kgtk-wrapper, so it goes into an infinite loop.
Older versions had code like
PATH=`echo $PATH | sed s:$dir::g`
to temporarily remove /usr/local/bin from PATH to make sure $app is the actual gimp binary.
Editing the latest version to do the same thing gets it to work again.
ALSO (in better news) this works with qt4jambi (qt4's official java bindings) so one can write java programs with a qt4 GUI and KDE file dialogs. Great stuff :) - Sep 30 2007
I think I forgot I did that because kgtk-wrapper.sh and kqt-wrapper.sh are still in /usr/local/bin. Guess I saw them there and decided --prefix=/usr wasn't needed.
Why do those two files remain in /usr/local no matter what the prefix is? oh well, works great :)
Upgraded list of apps:
gtk-pod (add directory doesn't use the KDE version, but adding files does) - Jun 07 2006
Solved by moving everything kgtk related that was in /usr/local/kde to /usr
I could hopefully solve it by passing in --prefix= in configure, I'll try that out. - Jun 07 2006
Thanks for the quick response! ignore my other reply, posted before I saw yours :) - May 08 2006
Works great with gimp, firefox and eclipse here. Wish it worked with gtk1.2 (for xmms) ;) Great stuff, together with gtk-qt, those gtk apps look at home in KDE! The file dialogs were sorely missing, thanks for making them easy to use. - May 08 2006
/bin/sed: can't read /usr/lib/libXcursor.la: No such file or directory
libtool: link: `/usr/lib/libXcursor.la' is not a valid libtool archive
make: *** [libkgtk.la] Error 1
make: Leaving directory `/home/jason/Apps/cvs/kgtk-0.5.1/gtk'
make: *** [all-recursive] Error 1
make: Leaving directory `/home/jason/Apps/cvs/kgtk-0.5.1'
make: *** [all] Error 2
libXcursor.la no longer exists in debian unstable, and will soon disappear from debian testing (one modular Xorg gets there) http://lists.debian.org/debian-x/2006/04/msg00919.html - May 08 2006
German too. - Aug 26 2007
I for one think it's not ideal to make people start Krita or Digikam or whatever to scan something and would welcome Kooka's successor - Jun 29 2007
Ideally it would happen automatically when the filesystem is unmounted (and perhaps periodically before then if there are any changes).
Does this project have any relation to fusepod? - Jun 13 2007
Unfortunately, using Firefox with GTK widgets and GTK-Qt theme gives me a closer approximation of the widgets in my other apps, though it isn't as polished as your theme (a problem I ran into when creating a keramik theme for Opera).
Hopefully someday there can be a Qt frontend for Firefox so all this could be avoided. That aside, good job on the theme and its faithfulness! - Aug 02 2006
The added functionality of being able to navigate upwards through the tree is pretty much already there with the up button though, so it doesn't seem to bring much? True, one might need a few extra clicks to use the up button. Or, one could simply use the file tree.. Anyway, it just wouldn't offset the loss of ability to type in an address, which I do all the time, hidden directories or not. - Jun 19 2006
Please share the wallpaper too! - Feb 27 2006
Don't think I'll ever distribute it, but if I did I would need to specify that IBM's JRE was necessary. - Nov 21 2005
If thumbnails must be loaded, a patch like this simply has to go in. Bravo submitter. - Jun 17 2005
It hasn't been quite as urgent with KDE since KDE can do the Mac style menus already (though gtk and plain Qt apps don't follow along. I guess with this they could). Which leads me to wonder, what happens with Fitz + Mac style menus? I guess the buttons get shoved into the top toolbar instead? Not that using both has much sense, just sayin :) - Sep 11 2005
If the button is in the corner, it is not small, it is infinitely big. People can just throw the mouse to the corner: it's not possible to overshoot. - Apr 04 2005
Various KDE 1.-4. Improvements 128 comments
Everyone loved keramik at first, and judging by the approval rating, everyone loves this. Give it time though, and just like everyone wants plastik now instead, people would be begging for something more subdued for the control center.
Remember how keramik turned out, don't go hog wild with some other part of KDE. - Dec 25 2004
I regret saying this, as the new version adds some useful features, but the new layout is disagreeable enough to me that the new features aren't worth it. - Dec 24 2004
Also anything that *requires* renderaccel to perform well should definitely be optional.
So there is a choice between yet more options, or changing the default (imho, to a less sane default) .. bleh. Bear in mind, eye ecandy is cool until you have to stare at it forever. Remember how much everyone loved Keramik before they tried it in daily use? - Nov 28 2004
- To improve the performance of the rubberband try to enable the option "RenderAccel" in your XF86Config file."
Fark.. why should something as simple as a rubberband be so crusted up that the user has to try to improve its performance? This could only really go in if it was optional. Hooray foreven more options in the control center :D I sure don't mind addming more options, but Eugenia et al will certainly complain. - Oct 27 2004