Comments

The author of the article complained about the
aliased fonts and jagged edges around his icons.
He was unable to build the Qt library with support
for Xft, which I believe to be the root of the
aliased/jagged appearence of fonts/icons that he
was seeing.

Don't you see the problem here? All that fancy
alpha transparency just does not work without
the Render extension on the X server. This means
that KDE 3.* + icons with alpha will look like
crap on Linux boxes still running the old
XFree86 3.x.y X server, as well as the commercial
X servers on Solaris and Irix which will likely
not support the Render extension in the near future.

I think KDE would do itself a better service by
shipping with less eye-candy by default (the old
hicolor icons were fine without the Render extension).

Paul.

PS. I am running KDE 3.0.1 on Solaris 2.6, and
icons utilising the alpha channel do look like crap.

On first startup, you can choose from different themes/styles (one of which is the Keramik theme) - at least last time I checked, this was the case.

So I think it's still perfectly possible to select the 'default highcolor' scheme if you find the 'eye-candy galore' themes to look like total crap on your display.

Now about what Red Hat 8.0 installs for a default...well yes...let's not go there shall we?

If you rm -rf ~/.kde I'm pretty sure you'll get a 'setup wizard' the first time you start KDE again, which will ask you which style you want to use, and how many CPU-cycle-consuming-but-nice-looking features you want or don't want.

I know I am perfectly capable of installing the hicolor icons
myself. That really is not solving the underlying problem in
the long term. Eventually the hicolor icons will become obsolete
as more features are added to KDE. There will be a discrepancy
between the number of icons used in the default icon theme, and
the number of icons in the hicolor theme, which means I will see
"question-mark" or "kde-gear" default icons for things which do
not have a corresponding icon in the hicolor theme.

A better solution is to implement a software fallback rendering
engine that could perform the same functions that Render performs,
but on X servers that do not support the Render extension. However,
this is probably too-much work for too-little benefit to the
wider audience (the Linux + XFree86 4.x.y). After all, how many
KDE Solaris users are there?

Maybe I should stop being so selfish and let you enjoy the Crystal/Keramik
eye-candy by default (provided you have the Render extension ;)

Well, there was a software fallback on KDE 2.2.2 (kalphapainter.cpp). But as far as I know it was removed after Qt started to support XRender. There is a thread about this on kde-devel or kde-core-devel. I tried to port kalphapainter to KDE 3 but I'm no graphics expert. It just didn't work. And some words to the hicolor theme: Of course I can (must) switch to it, but it doesn't look good either, without alpha blending. Hicolor on KDE 3 looks worse than on KDE 2.2.2.

I wrote some mails about this to kde-devel and kde-solaris, but got no response. So it seems that there are indeed not very many non-Xfree users of KDE.

I believe that Keith Packard's plan for newer versions of the render library includes just what you wanted... a fallback for servers without the extension. So everyone will be able to benefit, not just KDE users.

As far as I know, Keith Packards newer Render library is still for
XFree86 4.x.y only. All it will do is provide software Render fallback
for cards which do not have hardware acceleration for Render. Render will
not be a stand-alone software-rendering library (to my knowledge), because
in order to provide accelerated Render functionality it will have to be
a part of the XFree86 X server (an X server extension).

Which means that this will benefit users with older/weaker graphics cards,
who are running XFree86 4.x.y, but it will do nothing for people running
XFree86 3.x.y, nor for commercial X servers on SUN and SGI.

KDE 3.1 really rocks.....tons of new features and many improvements.....its not just eyecandy...its really a GOOD software worth it......and BTW congratulations to the KOffice team....i couldnt even install OOo 1.0.1 in linux, and with KOffice aside from some crashes and some weird things in KWord and the interaction with KFormula, with some playing im been able to write really professional documents, matematical reports and all without me knowing a single LaTeX command, with the AA fonts, freetype and all my fonts....really COOL :)....and the UI of KFormula is more user friendly that the formula component of OOo (tested on Windowz) i hope soon the KOffice team has working filters for all the OOo formats...

where is my mp3???noatun says that it supports mp3 but redhat says that they removed this support... :(.i have xmms now palying mp3 after installing a library but i want noatun.i really like noatun and its full integration with KDE.is there any way to play mp3 some how on noatun???if yes,mail me

i have a problem with attachment and i have formated my pc 4 time but the problem is same pls solve this problem and one thing net is ok every sites is open but no file attache so i dont send any document ok
thx

i believe in open-source and i'm not agree with the redhat software patents question. software isn't of redhat, so they coudn't invite us to use our linux box as they think we should. everyone likes play his favourites mp3s so why shoudn't?
well, redhat encourage not more mp3 but "unfortunatelly" xmms isn't of redhat, and that's the solution: there's an xmms plug-in for mp3 and it name is xmms-mpg123-1.2.7.21.i386.rpm. you could find it on google very fast, i use redhat9 and works fine. why should we use redhat and xmms and not redhat and xmms with plug-in?

Let me respectfully suggest something. Why not kill all the obvious bugs during the betas, make just one release candidate, give time to the interested distros to package it (as they do with the betas), check for showstoppers, fix them if any, and then either rename RC as final or make the final release. It occurs to me that this way:

1) Less effort would go in release related stuff (as opposed to the effort of releasing / coordinating several RC's)

2) More people would test the RC

After all, a release candidate is exactly this: a version that looks finished, and that will in principle become the final release. If the idea is not to release binaries of the RC to avoid mixing up packaging errors with code bugs, the RC can be released src only.

Either way KDE is fantastic, and the developers/translators/etc., the whole team is making a damn great job. I just though I should post just one more opinion at the hectic bazaar, in case it helps :-)

> After all, a release candidate is exactly this: a version that looks finished, and that will in
> principle become the final release. If the idea is not to release binaries of the RC to avoid
> mixing up packaging errors with code bugs, the RC can be released src only.

Well, that's what KDE 3.1 RC's all were. It's just that there is a major showstopper left: No Qt 3.1-final ;-)

> > principle become the final release. If the idea is not to release binaries of the RC to avoid
> > mixing up packaging errors with code bugs, the RC can be released src only.
>
> Well, that's what KDE 3.1 RC's all were. It's just that there is a major showstopper left: No Qt > 3.1-final ;-)

Ha !, true :-), but really, while the last RC was not planned, several quick RCs were planned ahead in the release schedule for 3.1 - I guess my point is, if you plan them ahead, they are not really RC's. They are betas. And I don't see the use of short lived betas. By definition, the RC should be one (except if sh*t happens, but that you can't plan :-). So, my suggestion in the end is: why not plan just 1 RC, give people time to use it and see if it turns into final with no changes. As I said before, just an idea ... Cheers :-)

On those screenshots, you can see that konqueror has very few icons (back, forward, up, home, reload and stop). IMO that should be the default configuration for two reasons.

1) It make konqueror easier to use because only the most useful items are on the toolbar.

2) It makes it nicer because you can have only one toolbar instead of 2 or 3. And as keramik isn't very nice with lots of toolbars, it's better.

I think this could be applied to lots of apps (kword for example). The less toolbar icons you have the easiest it is for the user to find what he looks for and the nicest it looks. Look at GNOME apps. I haven't seen any GNOME apps having more than one toolbar (in fact, I haven't seen any non-KDE app having more than 1 toolbar).

And the most important part is that with 2 or 3 toolbars, you reduce vertical area for the app, which can result in usuability problem at low resolutions.

Yes, but not simply becuase it is Red Hat,but becuase as usual they are
implementing something that isn't quite finished yet ( close, tho)
Keith Packard's excellent xft2, which does look like it will be the definitive
solution to font handling in Linux.
Now if only they had used this "best of breed" approach to package
management we would all be using debs and apt.

Hey, what happened to the expanding frame around the title in the title bar? In older versions, the frame around the title would grow for the active window, to be a little higher than the top of the title bar. I thought that was a really nice effect, but it seems to be gone from the keramik screen shot in the article.

Next to being slow for those with older hardware, KDE being a little too busy seems to be the most common criticism of it.
It is a difficult job to square frequency of use, comprehensiveness,and proper
categorisation.
The answer may lie in easy customisation , so that those who like a cleaner
simpler interface can cull away. Of course, KDE has this now but perhaps
it needs to be emphasized more.
That or perhaps some kind of "level" toggle that could reaveal an extra layer
with more detail. At most 3 layers in total, but probably just 2 would be best.