[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-11 10:19:55
[Download RAW message or body]

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

On Montag, 10. März 2003 17:00, Mosfet wrote:
> On Monday 10 March 2003 4:29 am, Ralf Nolden wrote:
> > On Samstag, 8. März 2003 20:31, Mosfet wrote:
> 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.

Sure. However, like with the icon themes, a theme inheritance is always a good 
thing. The cursor themes in XFree 4.3 also use inheritance to make sure 
everything works and you can even use a subset. Even though I know that's not 
what you originally always *want* to have, but it is a technically safe 
method. 

If e.g. a theme gets packaged by distro packagers, they can add the necessary 
dependencies to their packages to make it work correctly like the original 
author intended to do. Other people that come into consideration are mostly 
either compiling from source or just know that they have to have everything 
installed from KDE to make things work correct always, so I think the 
inheritance is a safe technical thing but doesn't do too much difference when 
it comes to displaying the intended theme to the user. The only thing that I 
think it should refer to when it comes to a preference in e.g. kwin styles 
and kstyles is that otherwise you only give one theme if you're the author. 
If that theme isn't available, KDE can't change the theme at all and the 
desktop may look even more screwed up :-). That's why fallbacks are always a 
better idea IMHO.

>
> 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 ;-)
Agreed :-)

We'll have to evaluate which stuff *should* be shipped as a minimum in 
kdebase. IIRC it should at least define some rudimentary KDE theming 
infrastructure that ships with at least that stuff that's needed by 
kpersonalizer so this works out of the box at least and the theme manager is 
able to display these themes completely as being fully installed.

> > 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.
Which is a pretty good task that could be done easily, agreed. It would be the 
most sufficient short-term solution to make things work.

> 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.
Ok, understood.

> 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.
Karol Szwed and I would be doing this and Carsten Wolff as well because that 
is what we desire to achieve long-term to fix all the issues that are there 
and we'd need to change kpersonalizer on the way. Tackat can bring in his 
input also.

What if you started to remodel the theme manager first by looking at the 
kpersonalizer code and then extend the definition of the themerc file so we 
have everything collected ?

Then, if the design of the thememanager is made very clearly to switch bit by 
bit over to dcop functions we could do that along the way and change it in 
kpersonalizer and the thememanager simultaneously in CVS ?

Another good solution IMHO would be to write a wrapper around the C++ 
implementation for now so we can restrict any changes later on the single 
apps to that wrapper app. Let me tell you how I think we could manage that:


		KDE Desktop apps + kcm modules
					|
				kdetheme (wrapper app)
					|
		________________________________________________
		|						|				   |
	Theme manager				kpersonalizer		 third party app


We could  strip out the code from kpersonallizer and define the themerc file 
layout. Then implement the program kdetheme as a commandline program to be 
accessible via dcop to set any of the themerc file settings. This will 
clearly desing and implement the themerc file settings and we could easily 
extend it in later versions. The kdetheme program then handles the 
modifications to the desktop apps and calls the functions that currently 
kpersonalizer does to restart/reconfigure them to apply the themes.

The theme manager could work like providing the user interface to the kdetheme 
program, calling the kdetheme program directly with a theme file after 
installing a theme and directly the specific dcop functions - which is 
necessary if you want to have a layout that says: "I want the background 
image but not the sounds of this theme applied to my current theme", and also 
being able to save a theme in a new theme file, even copying stuff like 
non-system installed wallpapers and stuff into a new theme folder and package 
it up. E voila, you have that done what is close to a theme designer :-) at 
least it would work in a similar way that the windows 95 plus! theme manager 
did (and how the current kde 1.x theme manager does once in an while :-})

Also this would allow you to work more independently on your own. After we'd 
have the kdetheme program in place, we'd put together the four to five theme 
files that define kde standard themes that ship with kdebase. Then we'd adapt 
kpersonalizer to apply these themes over the kdetheme program. In the 
meantime you could rewrite the theme manager to serve the proposed purpose. 
After all that is finished, Karol, Carsten and I could work on the kcm 
modules and the apps to implement dcop functions directly and clean up the 
kcm mess, replacing the implementation for writing into other apps's rc files 
with appropriate forwarding dcop calls.

BTW the kdetheme program should be able to put a complete theme into place, 
i.e. copy it into ~/.kde/share/apps/kdetheme/<theme>, unpack it and apply the 
themerc file, so that's getting stripped out of the default thememananger's 
capabilities as well.

I think this would be a pretty good long-term approach to solve those pending 
issues with themes in a way that it gives you the maximum independence and we 
can do things step by step.

Comments, ideas ?

Ralf





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

- -- 
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+bbhPu0nKi+w1Ky8RAp3XAKCg/3azwdazImszqW6oNf7P92y+mgCglTTw
TJLZcUvZJMv7THiktUnIUBw=
=g0J5
-----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]