kde 3.1 -- make Keramik default?

Vadim Plessky lucy-ples at mtu-net.ru
Thu Jun 13 08:09:40 BST 2002


On Wednesday 12 June 2002 1:21 am, Fredrik Höglund wrote:
|  On Sunday 09 June 2002 09:27, Vadim Plessky wrote:
|  > On Saturday 01 June 2002 9:40 pm, Torsten Rahn wrote:
|  > |
|  > |  http://www.kde-look.org/content/preview.php?file=1961-3.png
|  >
|  > I do not think that this screenshot looks good.
|  > A whole screen looks flashy (which is not bad) and inconsistent (which
|  > is bad).
|  > On top of it, fonts are not anti-aliased on that screenshot which really
|  > takes you back by year or 2 years from now. Even Mozilla supports AA in
|  > custom builds nowdays!
|
|  I hardly think the point of this screenshot is showing what KDE looks
|  like with anti-aliased fonts, but rather showing the combined effect
|  of the color scheme, the widget style, the window decoration, and the
|  icon set, as compared to the screenshot where the style is used
|  with the default icon set and color scheme.

I agree with you. And can repeat once more: badly looking fonts affect KDE as 
a whole ennvironment.
As about "default icon set and color scheme" - Keramik should exactly 
*RESPECT* color scheme.
If you want some color schemes for testing - take any of my KDE mini-Themes 
(http://kde2.newmail.ru/themes/)
which is in fact *color scheems* packed into KDE Theme format, with screenshot 
& other nice things.
I like Keramik a lot. And I like my color schemes. So, it would be cool to use 
them together. But Keramik should get rid of coloured pixmaps first.
(I run Blue Fantasy on my desktop at a moment, and it really loooks cool with 
KDE2 HiColor Window Decorations; I just disabled stipple effect to make it 
looking better)

|
|  > Crystal Icon theme takes you back, too.
|  > Ok, I have nothing against Folder icon, this one is very good.
|  > But the rest of icon sets lacks "contouring" line around icon (in
|  > contrast color), so icon loses border. Effect from this is very bad.
|  >
|  > Now about Keramik Window Decorations itself.
|  > 1) how can I switch Rounded corners off?
|  > I don't like those rounded corners for several reasons.
|
|  The rounded corners is sort of the whole point of this window
|  decoration, there's no way to turn them off, nor will there ever
|  be an option to do that. If you don't like shaped windows you
|  shouldn't be using this deco.

I really sorry to hear this.
I frequently do screenshots of different windows, and rounded corners do no 
tlook good on those screenshots 9they bacame *black* when you capture window)

Besides, I do not think that spending extra CPU cycles worth rounded corners. 
At least people with slow CPUs or not most-modern video cards should have 
possibility to swicth them off.

|
|  > 2) colors, and *style* for Maximize/Restore, and even for Close and
|  > Minimize, look terrible. They should not be of Black color, and Pixmaps
|  > for them should be configurable
|
|  If they shouldn't be black, what color would you suggest? The idea

Button Background/Foreground from default Color Scheme.

|  is that they will be either black or white depending on the brightness
|  of the button color in the color scheme. With the current color
|  they're obviously too bright for the symbols to be white. As for the
|  symbols themselves, they're designed to match the style of the
|  symbols used in the widget style, and they were designed by
|  the same artist.

Ok, than it's better to make symbols configurable.
What about to have an option to replace pixmaps (which AFAIK grayscale 
pixmaps) with some other from the disk/theme?

|
|  > // BTW: what about using SVG for those buttons, instead of pixmaps? With
|  > recent SVG support in KDE this sounds quite reasonable.
|
|  As I'm sure you're aware, the decision has been made to use hand
|  painted pixmaps for icons smaller than 22x22 pixels, because SVG
|  icons simply won't look acceptable at those sizes. The titlebar
|  buttons are 17x17 pixels (that's 16x16 plus an additional row and
|  column for the shadow).

Titel bar buttons have size which you define for them.
I was doing KDE2 themes (for siome reasons, KDE3 is not compatible in theme 
format with it?) and many titel bar buttons hadve 22x22 size in my themes.

|
|  Furthermore the buttons are not intended to be scalable, so what
|  exactly would the advantage be of using SVG here? It would degrade

1) color match (color scheme)?
2) have you thought aboyt screens with >100dpi resolution, say, 150dpi or 
200dpi?
Do you know how many troubles hard-coded pixmaps create for those 
screens/resolutions?

|  image quality and slow down initialization time (since it would
|  take quite a while to render the images) while offering no
|  advantage whatsoever.

There is possibility to cache.

|
|  > 3) it's realy bad UI design - when you combine both Round (circle) and
|  > Rectangle buttons in *one* themes
|
|  The descision made by qwertz was to make the most important
|  buttons square, and the less important ones round.

Again: doesn't sound wise to me.
If this design was intentional than it's mistake.

|
|  > On top of it, KDE2 default Window Decoration has these options:
|  > 4) draw grab bar below windows
|  >
|  > 5) draw titlebar stipple effect
|  >
|  > which make it superior to many other styles.
|  > Until you can control "grab bar" and add/remove stipple effects (or
|  > gradients) in Keramik - it should not go as default KDE 3.1 theme.
|
|  Havoc Pennington recently wrote an article on his website
|  (http://www106.pair.com/rhp/free-software-ui.html) that you
|  might want to read, that deals with the subject of configurability
|  versus usability. That article has been discussed quite extensively
|  on this mailing list, and the views that are expressed there have
|  been confirmed by usability studies conducted by Eazel and
|  Sun Microsystems. I've tried to adhear to the findings of those
|  studies when designing the configuration tab for this deco.

I have to admit that I haven't read that article. I will look at it later.
BTW: Eazel and especially Sun are not good example to quote about "usability".
Eazel was bankrupted (nice example, ehh?..), Sun has a lot of troubles nowdays 
and its focus primary on server market.
So, I see no pionjt quoting those 2 companies.
As about Havoc Pennington - if I wanted to use GNOME, I could use it.
My choice is KDE, and it's done. Thanks!

|
|  Those ideas are being adopted in quite a few places in KDE.
|  You might want to take a look at the HEAD version of the
|  config dialog for kicker, and compare that to the one in
|  the release version of KDE 3.0.
|
|  > oh, and the most important priblem:
|  > WHY KERAMIK DOESN'T RESPECT KDE COLOR THEMES?
|
|  That question was answered by me almost two weeks ago on this
|  mailing list, see
|  http://lists.kde.org/?l=kde-core-devel&m=102286945019871&w=2
|
|  In the meantime there's patch created by Rik Hemsley that you
|  can try that enables the experimental recoloring code in CVS,
|  see http://lists.kde.org/?l=kde-core-devel&m=102295981016327&w=2
|
|  Unfortunatly it's a common misconception these days that when
|  something has committed to CVS, it has also been released to the
|  public. I can assure you that that is not the case. Neither the
|  widget style nor the window deco have been released yet, not even
|  as alpha versions. It is not a requirment that work is finished by
|  the time it's committed to CVS. Only that is finished at release
|  time.
|
|  That someone chooses to check unreleased code out of CVS, package
|  it and upload it to kde-look doesn't change that fact.
|
|  If you choose to use the HEAD version of KDE or anything else
|  that's being developed under CVS, you cannot expect all features
|  to be implemented, nor that the code is free of bugs.

Yes, right, I see your point and agree.
Just wanted to make some comments to bes ure that Keramik is usable when 
released ;-)

|
|  > I have tried several ones, and even KDE's default (rather dark blue)
|  > color is not respected, not speaking about other nice color themes I
|  > have here.
|
|  The style does not attempt to mimic the default color scheme.
|  That is quite intentional, and as it's pointed out in the email
|  you're replying to, the style doesn't look all that good with
|  the current default color scheme.

So, what about trying with my color themes?
I amaware that KDE's default color schems are not very good.
That's why I developed my ones.
My mini-Themes/Color Schemes were extensively tested with different KDE styles 
(works fine with Quartz, for example, in addition to KStep and KLaptop and 
KDE default)

|
|  Regards,
|  Fredrik

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/





More information about the kde-core-devel mailing list