Well, it's all text files so there is no reason that a Qt front-end cannot be written for Qt and if it is successful it *will* be supported. I think a lot of companies have bought FUD about Qt. Once they see otherwise they will come round. If we get a lot of things right I see a very bright future for KDE to be honest. Our comunity has the workable business models.

Using Qt only makes sense for ATI. You get seemless platform independence on your configurator. All you have to do is port your drivers. how hard can that be? :) seriously though, that helps out a bit and makes it easier for them to support other platforms since all users will be starting at the same interface when calling up tech support.

I should have written "it only makes since THAT" and instead of "only makes since FOR." Yes, I agree. I think all closed source configuration utilities should be written using Qt or a similar cross platform indepdent tool. Then again I'm quite partial to Qt. :)

Hey - that's really nice to see a commercial company
write GPL'd KDE apps. And they create very good products AFAIK. Never
had any complaints and they reguarly win tests at PC mags.
BTW: I agree with Carsten - a mobile phone with most frequently called
function would be really useful. Why didn't I think of this before?

We need a new KDE logo, the Kgear is now dated. The KDE artists really need to match the competition. I like quartz's stuff. I wish he could polish up the icons as well. crystal is great, but for small icons, it sucks. OT, plastik has managed to get rid of the ugly black borders on qt widgets. it should be made default for now until someone does an original kde style. I dont use gnome, but I check it out from time to time just to see how cool it looks. And where is the howto for kde styles, maybe i can do it myself, rather than complain.

As has been said many times before, the default theme won't be changed.

And even if I'm in the minority, I'm very happy with that. Last week I finaly came around to updating kdeartwork, and test plastik for myself, to see what everybody was so pleased about.
But the impression I got from the screenshots didn't change after using it for some hours. It still reminds me of the arcitecture of the 60's, plain, gray, rectangular, without any intressting points, or with Homer Simpsons words: BORING. I don't think it is in any way modern, it has, on the contrary, a rather outdated feeling (Just a personal feeling).
Well, but I guess it's just a matter of taste, and as wiser people than me said, "Taste can't be quarreled about".

good for you. I have attached a screenie of keramic to show you just how inconsistent the borders are. in all I count six border line types. all lit from different light sources with conflicting shadows.

So what?
I mean it is not that a DE is a natural surface which is bound to natural lightning, (It does not even have a relief, or light for that matter). As you noticed, it are border lines which have a different type. They are there to separate content, not to give any hight information, since there is no hight in the GUI.

And looking at your screenshot, your comment is plainly wrong. All "lights" are at the upper left corner. Especially #1 and #2 are correct, since you have to look onto the whole widget (the white area). #5 symbolises a narrow channel, so its correct, too. #4 looks a bit strange in this shot, but the whole impression and lightnig is correct. #6 even has a gradient light and shadow, but has an additional thin black line surrounding it.
You could dispute that the white and black lines which symbolise light and shadow should be a gradient, for a better relief illusion, but i guess that would be a bit overkill.

"[Plastik] should be made default for now until someone does an original kde style."

The default theme cannot be derivative of the look for another desktop. KDE needs to have a unique appearance, and not be a visually reminiscent of CDE, NeXT, Aqua, QNX, etc. While Keramik is not my favorite style, it definitely is unique. The old Highcolor default, while very simple, is also unique. Unfortunately Plastik is not, no matter how great it looks. It is very derivative (in look, not code) to INCORS Alloy. It's been softened a bit, and tempered with some WinXP styling, but a comparison of the styles shows the relationship.

Just about everything out there is derivative of someone else's look. The number of Aqua and XP inspired styles on kde-look is amazing. I decided to do a new style that was completely orginal, since every style I've done was derivative of something else. It's very hard to do, because your subconscious keeps interjecting stuff from other desktops. Or from the real world. After all, why should pixels drawn on a glass screen resemble brushed metal or globs of jelly or the television remote control?

Like it or not, Keramik is original. While I don't like it as the default, that's only my personal opinion. Instead of throwing it away, how about fixing the minor inconsistancies?

"And where is the howto for kde styles, maybe i can do it myself, rather than complain."

I wrote a HOWTO for KDE window decorations, so I know how much work this is. Doing one for KDE/Qt styles would be at least five times as much work, because there is so much more ground to cover.

Well, talking only for me, I think the preferences look a bit convoluted (at least in KDE version 3.1.5).
For example they feature entries that are not obvious to your average computer user, like Dither in HiColor (15/16bit) modes etc in the General section. At least a popup explanation should be provided. Also why not separate the viewer shorcut and the browser shortcut preferences into own sections like so many other KDE programs do? Furthermore, is there a reason why the program uses horizontal tabbed preferences and not vertical ones?
Also, I think that the context menu is a bit overloaded and features too many entries. What about organizing them in sub-menues and adding icons for faster visual navigation?
Finally, what about giving the "Start slide show" button in the toolbar a more prominent position? E.g. adding it on the bottom of the window that opens first when starting kuickshow? I think that for many people it is not immediatly obvious how to start the slide show.
Thanks otherwise for this nice application!

> For example they feature entries that are not obvious to your average
> computer user, like Dither in HiColor (15/16bit) modes etc in the General
> section. At least a popup explanation should be provided.

Yes, I think I can remove those options entirely. Or at most provide a slider "Quality -- Speed".

> Also why not separate the viewer shorcut and the browser shortcut preferences
> into own sections like so many other KDE programs do?

When I wrote this, it wasn't possible to do, but it seems, it now is. Will do.

> Furthermore, is there a reason why the program uses horizontal tabbed
> preferences and not vertical ones?

Because that was state-of-the-art in '98 when I wrote it ;-) No, actually there was some usability study by Macintosh people (I think I read about it at "AskTog") that a tabbar was easier to comprehend for new users, than those vertical sort-of tabs. (The Mac had those vertical tabs before the tabbar was invented).

So with that in mind, I saw no reason to switch to vertical tabs.

> Also, I think that the context menu is a bit overloaded and features too many
> entries. What about organizing them in sub-menues and adding icons for faster
> visual navigation?

You mean the image-context menu, right? Agreed, it's a bit crowded, as people requested this and that entry. I'll look into optimizing it.

> Finally, what about giving the "Start slide show" button in the toolbar a
> more prominent position? E.g. adding it on the bottom of the window that
> opens first when starting kuickshow? I think that for many people it is not
> immediatly obvious how to start the slide show.

You mean a transparent widget covering part of the image? Or a button at the bottom of the filebrowser?

> Yes, I think I can remove those options entirely. Or at most provide a slider "Quality -- Speed".
Great, good idea!

> Because that was state-of-the-art in '98 when I wrote it ;-) No, actually there was some usability study by Macintosh people (I think I read about it at "AskTog") that a tabbar was easier to comprehend for new users, than those vertical sort-of tabs. (The Mac had those vertical tabs before the tabbar was invented).
That's interesting. Well, I don't know why I like the vertical sort-of tabs more than horizontal ones. Maybe, because the latter are more clearly separated from the content and also allow for big pretty icons ;-) Also, many horzontal tabs lead to a crowded look, which is less the case with vertical sort-of tabs.

> You mean the image-context menu, right?
Yes!

> Agreed, it's a bit crowded, as people requested this and that entry. I'll look into optimizing it.
Great, thanks!

> You mean a transparent widget covering part of the image? Or a button at the bottom of the filebrowser?
I meant a button at the bottom of the file browser. A transparent widget would probably confuse many people. Also this button could be an ordinay push-button and carry a label like "Start slide show" in order to immediatly reaveal what the program is about and how to use it. I remember that the first time I used kuickshow, I was a bit confused when facing the file browser and first hovered over all toolbar buttons in order to read the popup explanations. :-)

Further idea: What about (optionally) allowing kuickshow to be integrated into konqueror (kpart?) so that a slide show could be started in a konqueror window? Probably, navigation buttons at the bottom of the konqueror window/file browser would be useful in this case.
I don't use Windows myself, but saw something like on the computer of a friend who uses Windows XP. Thought it was pretty nifty. There are more and more digital cameras around and people like to browse their image collections, so why not allow them to view a little slide show right in konqueror?

I experienced problems with the file scroller when the file names are strange.

the next item algoritm used for the "up and down" of the entities is not the same as used for the sort algorithm. So you don't get the next item in the file scroller but you jump back 4 lines... very strange...

> the next item algoritm used for the "up and down" of the entities is not the
> same as used for the sort algorithm. So you don't get the next item in the
> file scroller but you jump back 4 lines... very strange...

Yes, this is a known bug in QIconView and hence is not limited to KuickShow, but visible in other KDE apps, too.