[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KSplash/ML donation?
From:       Ralf Nolden <nolden () kde ! org>
Date:       2003-03-10 10:29:02
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Samstag, 8. März 2003 20:31, Mosfet wrote:
> > Hm, yes. The thing that we are discussing is just the theme manager but
> > of course, the theme designer is the next logical step. Otherwise we'll
> > never end up with correct, neatly integrated themes. Regarding styles, I
> > think one thing that a theme designer *could* do is just save a list of
> > preferred stlyes that match the creator's taste what he thinks matches
> > best to the theme. If that theme isn't installed, fall back to another
> > theme and if that's not there, a third one as a maximum that a designer
> > could name in the theme rc file. If neither is available, don't change it
> > and stick with the current one.
>
> ...snip...
>
> Don't know about this. If someone is trying to install Liquid I doubt that
> they want to end up with Platinum ;-)
Ok, maybe I wasn't precise enough how I see that there is a problem:

most styles (kwin, kstyles, wallpapers etc) went to kdeartwork. Its part of 
KDE, ok, but a theme designer cannot make any assumptions on the user having 
kdeartwork installed. Therefore you need to have a fallback like with icon 
themes. The theme designer should have a way to say, ok, for my theme a theme 
rc file is enough. My theme consists of:

wallpaper xy
color scheme xy
kstyle xy
kwin decoration xy
System behavior xy (see kpersonalizer)

If he just wants to ship one wallpaper himself but for the rest of the theme 
wants to re-use parts that he assumes are available in KDE, he can only rely 
on what's installed with kdelibs and kdebase, not kdeartwork. However, he 
should have the option to say, ok, my primary kstyle is from kdeartwork but 
if that's not installed, use this style from kdelibs. That's what I meant.


>
> > The issue with the control modules is more or less that what I mentioned
> > - kpersonalizer does already do a good job but it was a PITA to sort out
> > everything and to write settings into rc files where I cannot always be
> > sure that module xyz didn't change the format and storage location. So
> > that's why I think that the dcop functions of the according desktop parts
> > should handle setting a theme (most of them do support that already or we
> > just restart a certain part like kicker) but most importantly support
> > writing a style after checking that it can be applied (i.e. for instance,
> > a style is installed -> switch to the style -> success -> save setting
> > automatically). That's what's missing in the infrastructure in the first
> > place to make applying themes as fool-proof as possible. What do you
> > think ?
>
> Basically what I think your saying is that a) the application of various
> theme components needs to be encapsulated into some sort of standard API. I
> don't know if DCOP is the answer or doing an actual library is, but I agree
> either way. Theme installers get pretty darn messy otherwise with bits of
> code modifying all sorts of app config files. I'm not too concerned about
> config keys changing, just that it's messy and prone to error.

Correct, that's what I meant. Kpersonalizer does handle things this way:
- - write into the rc files (kdeglobals, kdesktoprc, kickerrc mostly)
- - call the dcop functions to restart the app or to reconfigure (kicker has 
restart, but can handle setting its size by itself for instance while 
kdesktop only has reconfigure())

The idea that I think works better is to add a standard API call for setting 
things that are themeable in a specific order, like:

- - kstyles: setStyle("styleA", "styleB", "styleC")

the result would be that you would let the programs check if they have A, if 
not, try to use B, if that's not present, use C. Of course, if he ships his 
own theme he needs to make sure it can be loaded correctly also, so there 
should always be a fallback and a user information if a theme can't be 
applied.

Moving that functionality over to dcop'able functions would remove much of the 
redundancy in the kcm modules IMHO also. Their maintenance is a PITA, ever 
has been.

>
> As for b) I'm interpreting this to mean that you want to be able preview
> configuration changes before actually writing them permanently to a config
> file.
Hm, not so much about previewing but for setting the themes we need to make 
sure everything works as expected. A typo in the theme file for instance 
could prevent the theme from applying so the dcop function setting the theme 
should return true or false for the choice value of the theme that the 
function set, starting with 0 as the default return value maybe.

 I'd go one step further. The theme manager needs to be able to do
> both that and have some mechanism to change the settings of KDE Control
> Center modules before applying. Let's take wallpapers for example. I'd like
> the user to be able to both preview the wallpaper and modify it's settings
> like "tiled, centered, scaled, etc..." before applying. But the only way to
> get the background control center module to run with the new wallpaper set
> is by writing it to the config file first. This wouldn't let you cancel it.

Hm...this reminds me also about the problem of internationalized desktops and 
the screenshots that themes used to include - they just don't apply at all to 
hebrew or arab desktop because of the reversal of the widgets.

I'd rather try to combine the background preview in the background kcm module 
with the style module into one big previewing window. (kicker has a similiar 
widget for the kicker placement)

If we treat this more clever, we could go as far as thinking of it like we're 
writing layers for each theme part. Those layers can then be combined by kcm 
modules according to what they need and avoid code duplications overall. Even 
a full preview for the user would be suitable, so only one widget would be 
needed. Let me give you the idea: let's say we have one fixed preview widget 
size, then we could say, ok, kdesktop please generate a preview for 
background image xyz displayed tiled. Then kicker set to 80% width, left hand 
side, generate a matching image that can be overlayed to the kdesktop 
preview. Of course, kdesktop knows the current icon theme so does kicker, so 
they could even include the icons that the user currently has accordingly.

I hope you get the idea, I know it's a bit complex and I know if a full 
implementation is possible.


Ralf
> I ran into this problem with my replacement image part for Konq. It can set
> images as the background wallpaper but I wanted people to be able to
> configure it first. I couldn't get the control module to display the new
> one without applying it to the config file first. No good so I had to
> include my own.



- -- 
We're not a company, we just produce better code at less costs.
- --------------------------------------------------------------------
Ralf Nolden
nolden@kde.org

The K Desktop Environment       The KDevelop Project
http://www.kde.org              http://www.kdevelop.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+bGjxu0nKi+w1Ky8RAhJ/AJ0YeB6va0xM2STWxKREJi8necunBwCgiQKn
zCliokBTrwbjVxCfk+al5A4=
=cv6Q
-----END PGP SIGNATURE-----


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]