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

List:       kde-devel
Subject:    Re: KSplash/ML donation?
From:       Mosfet <dan.duley () verizon ! net>
Date:       2003-03-10 16:00:18
[Download RAW message or body]

On Monday 10 March 2003 4:29 am, Ralf Nolden wrote:
> 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.
>

Okay, I understand. I guess the question is if the theme should require you 
install the dependencies or if it can be flexible enough to use fallbacks. In 
some cases this is okay, but in others it is not. Again, if someone makes a 
theme for Liquid they may not want it to be shown in Platinum ;-) We can be 
flexible here and let the author decide.

BTW, I haven't upgraded to HEAD yet - still waiting for a new machine from the 
adopt-a-kde-developer program - but from what I am aware KDE now only 
includes like 1 wallpaper and screensaver in it's base packages. Good idea 
but probably a mistake. AFAIK some distributors aren't even including 
kdeartwork so KDE sucks pretty hard on these platforms and only has one 
screensaver and wallpaer. It's a good and "correct" idea, but relys on 
distributors to package a decent KDE desktop, which is always a mistake. 
Someone will always mess it up ;-)

> > > 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.
>

Okay. Originally I was just going to write things using existing code. I was 
just going to extend things to handle new stuff, (themerc files for C/C++ 
window and widget styles, etc...), and redo the user interface.

What you are suggesting is something that touches many applications. If you 
guys want to do that that's fine but is not something I'm apt to do myself. I 
wanted something I could do independently and submit for inclusion when I'm 
done.

If you wanted to coordinate and have one person do the application 
modifications and I do the theme manager itself that is cool. The thing is, 
no one has volunteered to me to do this.

> > 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.

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]