kde 3.1 -- make Keramik default?

Fredrik Höglund fredrik at kde.org
Tue Jun 11 22:21:13 BST 2002


On Sunday 09 June 2002 09:27, Vadim Plessky wrote:
> On Saturday 01 June 2002 9:40 pm, Torsten Rahn wrote:
> |  On Saturday 01 June 2002 16:37, Volker Augustin wrote:
> |  > So, you think that the following screenshot looks good? (keramik as in
> |  > kdelibs out-of-the-box)
> |  > http://homepages.uni-regensburg.de/~auv20213/keramik0.png
> |
> |  It doesn't look too nice because you mix some styles on the screenshot
> | but I would not say about it: "Der Stil ist Arschhäßlich" (not only for
> | reasons of politeness but rather because me and most people think the
> | opposite).
> |
> |  Using the correct defaults and stuff the style is rather meant to look
> | like this:
> |
> |  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.

> 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.

> 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
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.

> // 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).

Furthermore the buttons are not intended to be scalable, so what
exactly would the advantage be of using SVG here? It would degrade
image quality and slow down initialization time (since it would
take quite a while to render the images) while offering no
advantage whatsoever.

> 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.

> 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.

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.

> 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.

Regards,
Fredrik






More information about the kde-core-devel mailing list