[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic