Wanted: New Default K3b Theme for 1.0
Friday, 25 August 2006 | Strueg
K3b 1.0 is in sight and with it I would like to introduce a new default theme. Not because I don't like the current ones, but I just want K3b 1.0 to look different so that people will see the difference, not only feel it. If you are interested in creating a theme for K3b see the themes howto which describes the pictures that are needed in a complete K3b theme set. Send your entries to k3b-devel. In other artwork news one of our best community sites kde-look.org passed its fifth birthday.
Comments:
Color themes? (little off-topic) - sebastian - 2006-08-25
Great! Though I wonder why it is not possible to match the current color scheme with these pixmap themes. Theme designers may create a pixmap skin which fits a specific color theme, mostly KDE default, or their favourite KStyle. Changing the KDE color settings may yield a distracting result. There are quasi-pixmap style engines like Baghira/Keramik which blend their pixmaps with the individual color settings. Why not adopting this colorizing algorithm for K3B themes or themes in general (like Amarok themes, Konqueror's context bar, help system stylesheets). Currently, we have a mixture of themes being totally different and mutually visually excluding. Being consequent, KDE4 should rethink its theming concept. On the one hand we may adjust the shape of widgets (KStyle) and the corresponding colors individually, on the other hand pixmaps are used which fit only one specific color scheme. In this regard, Gnome seems to be more consistent where the color settings are defined by the used theme, such that everything fits together. Which way to go?
Re: Color themes? (little off-topic) - oliv - 2006-08-25
I stumbled yesterday on this 3-years old article about magically changing the colours of KDE icons. I think this should be implemented in an automatical way, so one only stores the basic icon theme, and the new hue (the new ones can be written on disk too of course). http://scanline.ca/hue/ Also, using indexed colours would help to have icon themes magically follow the colour scheme.
Re: Color themes? (little off-topic) - Wade Olson - 2006-08-25
If you run under the assumption that icons and whatever other visual images on the desktop will continue to trend toward SVG, then with QT4 and Zack's work, the sky's the limit. SVG animations and CSS-color assignments. If you want icons to follow a color scheme or have effects (brightness, animation, whatever) upon a mouse hover, it's all possible. If you want you mount point/hard drive icons to show a current little capacity pie chart on it, or a decoration/notifier on icons that are already running, or an integer on your IM icon for how many session you have open, or, or.....what an icon is and what an applet is will be blurred. Possible before? Yes, but harder. Of course: 1) It all depends on HCI/usability and people actually doing the work. Auto-color changes might help desktop consistency, but it can also impact accessibility aspects if not watched. And it dilutes icon/image recognition and makes people lean more on the pattern for recognition. Would someone your computer spot a FF/Konqueror/whatever icon as fast if it was purple? Marketing-wise, we can also talk about brand equity being lowered. But what the hell do marketing people know. 2) This all has little to do with a request to pretty-up with cool application.
Re: Color themes? (little off-topic) - Olaf Jan Schmidt - 2006-08-25
"HCI/usability and people actually doing the work" We have already discussed this in the HCI workgroup, taking accessibility, usability and artwork into account. What we urgently need at the moment are developers implementing it - and later the willingness of developers and artists to listen to our advise. Olaf
Re: Color themes? (little off-topic) - Jakob Petsovits - 2006-08-26
> But what the hell do marketing people know. *g*
Re: Color themes? (little off-topic) - Olaf Jan Schmidt - 2006-08-25
Similar algorithms for changing the hue, saturation or brightness of a colour are described here: http://accessibility.kde.org/hsl-adjusted.php Olaf
Re: Color themes? (little off-topic) - oliv - 2006-08-25
I compared both pages. I do not want to sound too hard with you, but I think the difference is that the page I linked to is written by someone who is a professional of colour, so it is accurate. He uses CIELAB space to perform the rotation. Your formulas are probably much faster, but they are less accurate (for example, you use a gamma of 2.2 for sRGB space, when sRGB cannot be described by a simple gamma curve, and the part that can be has a gamma of 2.4). And accuracy is quite important with colours. You also rely on the sRGB standard, which fortunately, is already phasing out of the HDTV world (replaced by the xvYCC space with a much wider colour gamut). Most new devices will use better light sources (LED, lasers, new CCFL or HCFL) which will make the sRGB space too limited. It has already started last year with LED LCD TVs (Sony, Samsung, etc.).
Re: Color themes? (little off-topic) - Olaf Jan Schmidt - 2006-08-25
The two pages have totally different aims. The page linked by you does not address how to compute the luminosity contrast or other topics important for accessibility. The sRGB standard defines a gamma value of 2.2, but it also says that the real gamma value depends on the brightness of the room where the monitor is placed. This implies that total accuracy is impossible when dealing with monitors or HDTV devices, unless we know the exact luminosity characteristics of the room (i.e. all lamps, the colour of walls, the time of the day, etc). An additional problem is that some CIELAB colours cannot be expressed in sRBG. This means that a conversion to CIELAB and back to sRGB doesn't make sense if hue accuracy is your sole aim, as the page linked by you explains. CIELAB and derived colour spaces can be used in professional image editing applications, but they are never used for the user interface. All colours used in the KDE user interface are expressed as sRGB (colour schemes, CSS, SVG images). sRGB is also used in 99% of all raster images, and none of the image editing applications on Unix/Linux bar one (Krita) can handle anything different from sRGB internally.
Re: Color themes? (little off-topic) - oliv - 2006-08-28
Olaf, Unless you allow in your sRGB algorithms the use of values inferior to 0 and superior to 1 (or 255, depending how you normalise), then they will stop working as soon as the new displays (such as the ones introduced 1.5 years ago for HDTV) will be available. If you use CIELAB (or allow the negative RGB signal in your algorithms), then whatever the display technology, your formulas will work. DO you really wish to rewrite your library in 2 years from now ? Allowing the negative RGB values (and the ones superior to 1) allows to acess all of the colours. See the xvYCC standard.
Re: Color themes? (little off-topic) - SadEagle - 2006-08-25
It's pretty much impossible to do well adjusting colors in general.
Re: Color themes? (little off-topic) - Olaf Jan Schmidt - 2006-08-25
"Though I wonder why it is not possible to match the current color scheme with these pixmap themes." This is indeed very important, for example for partially sighted users who can only read light text on a dark background. The plan for KDE4 is to have image colourisation algorithms in the KDE libraries, as well as a global option for switching off all background images: http://www.amen-online.de/~olafschmidt/colors/ Olaf Schmidt KDE Accessibility team
Re: Color themes? (little off-topic) - Sebastian Trüg - 2006-08-26
Actually the current svn trunk supports transparent pixmaps and defaults to the current KDE color scheme. This way one can create K3b themes that fit the KDE color scheme.
Good Looks aren't everything - Rube - 2006-08-25
Just as long as they replace that default reveille (or whatever that bugle riff is) sound for completed burns...I *hate* that.
Re: Good Looks aren't everything - Daniel "Suslik" D. - 2006-08-25
Why do people always bug devs about their preferred DEFAULTS? You want to personalize sounds - Control Center > Sound > Sound and Notofocations Personalizing KDE is SO SIMPLE, leave the defaults alone.
Re: Good Looks aren't everything - Carlo - 2006-08-25
> Personalizing KDE is SO SIMPLE, leave the defaults alone. The problem is, that this is also time expensive, so the defaults should fit for as many people as possible. Sometimes people do not even find the place to perform the changes. KDE is not shining in this regard. Too many places where you can change options. Not to speak about missed kconf_update files you stumble about in the one or the other case, later; So it's actually beneficial, when developers do not chose to set their preferred options as defaults, so they stumble about such issues.
Re: Good Looks aren't everything - Martin - 2006-08-25
The problem really is: Why does everyone assume that just because he dislikes a particular default setting the majority does?
Re: Good Looks aren't everything - Paul van Erk - 2006-08-25
Agreed. I happen to love the sound of a finished burn. Hurray for trumpets!
Re: Good Looks aren't everything - Carlo - 2006-08-26
No. While your point seems to be a good one, it's just that the other way around the point is as good. Most dev's are not usability experts, nor do they usabilty tests with a decent number of testers - which is of course asked (maybe too) much for FOSS projects, without commercial backing. Maybe I should add that I do not argue about this particular sound - having sound notifications disabled, I couldn't care less - but usablity issues are a general problem of the Linux desktop and especially KDE 3.x.
Re: Good Looks aren't everything - Rube - 2006-08-25
Actually, I don't consider this bugging the devs. It was a light-hearted comment to begin with, posted on a call at the Dot for input on K3b's default theme. "Leaving the defaults alone" is pretty much the opposite of what they're trying to do here, isn't it?
Re: Good Looks aren't everything - Matt - 2006-08-25
Perhaps a more taste neutral default would be desireable. My preferred default is no sound. If I were to leave the disc burning and be concerned about not missing the end of the burn then an option to enable a sound on completion that is visible during burning would be great. Just a checkbox for play a sound on completion that saves between burns and file picker for the sound with preview.
Re: Good Looks aren't everything - Chani - 2006-08-26
I like the bugle sound. I even re-used it for a contact in kopete. still, knotify config stuff could use some work. or, well, all of kde's config stuff. it can be kinda.. daunting.
Colorizable theme - Francois Chazal - 2006-08-25
I agree with sebastian about the colorizable theme feature. It would allow to users to adapt the theme to their personal environement whatever color it is. However it wouldn't be that easy for k3b developpers to include that feature to the product for only the background should be colorized (take the current theme and colorize it with the gimp, you'll see how horrible it'll look like). Since it would have the developpers to rewrite the whole skinning source code, I don't think that feature will be include in the 1.0 release.
Glitter - furangu - 2006-08-26
A general problem with our usability and visual standardisation issue is that applications like K3B look like other applications. Just imagine everything is themed the same. It is important to keep contrast. Wow! applications need Wow! theming, with the default as neutral, invisible as possible.
Re: Glitter - Mark Hannessen - 2006-08-26
A general problem with our usability and visual standardisation issue is that applications like K3B look like other applications I would call this a usability feature actually... I love the consistency that kde provides.
Re: Glitter - Robert - 2006-08-29
Lovely. A desktop with all applications constantly trying to out-glitz each other. Sounds like the recipe for a consistant desktop.
Re: Glitter - Ben Morris - 2006-09-02
MSN IM, EI7, WMP, and MS Office all have their ownwidget themes, and all other built in Windows apps are split between XP style and Classic... It's been tried, and the result is a confusing mess of styles. Interface consistency, IMHO is an important feature that sets KDE apart from that sort of system. No one is ever going to mistake K3B for Konqueror or Kopete, because obviously it has different buttons because it performs different functions, so why make things inconsistent?