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

List:       kde-core-devel
Subject:    Re: Theming manager [was: Re: KDE 3.1]
From:       Torsten Rahn <tackat () kde ! org>
Date:       2002-03-29 17:58:09
[Download RAW message or body]

Am Freitag, 29. März 2002 18:38 schrieb Cristian Tibirna:
> On Friday, 29 March 2002 05:38, you wrote:
> > Moin!
> >
> >
> > Fabian, Karol, Cristian, will you join?
>
> Yes, I would join.
>
> Issues and questions:
>
> 1) we would have to use a dedicated mailing list. Possible ones are
> kde-artists, kde-usability or a new kde-styling ml.

While I think that the artists should be involved with the major decisions I 
don't think that kde-artist would be an appropriate mailinglist as it is 
rather targeted at creating pixmaps of all kinds.

> 2) we will have to make a complete list of all things that can be managed
> by a theme (eg. fonts, colors, style, decorations, icons, bg, sounds,
> specific configs, skins etc.). The way of managing this stuff has to be a)
> configurable b) flexible (allowing future additions).

yes, it should be as modular as kcontrol itself. If somebody creates a new 
kcm-module it should be possible to insert the contained new properties into 
the theme. If the user wants to install a theme and doesn't have that 
particular kcm-module installed the thememgr should take care of this (by 
informing the user or by offering a good fallback solution).

> 3) we have to decide: will the theme manager be a part of kcontrol or a
> separate app? If it's part of kcontrol, will it supercede  and finally

It should be a separate app.
Just imagine it to be something like a media-player: you can insert any kind 
of file (MEDIAPLAYER: mp3, avi, mpeg, etc. THEMEMGR: ico, thm, tgz, ... - the 
user doesn't have to care about the filetype) and presses "play" (THEMEMGR: 
"install"). If some kind of default option doesn't fit the user has to go 
into the settings (which should be kcm-modules).


> 	d) saving a theme (basically generating a theme package based on the
> current user's set of look configurations)

ew - saving a theme using a GUI will bring you into some big trouble and into 
problems that you'll not be able to solve.

> 7) do we need to define a mechanism of hierarchisation? So that a theme
> that is built on top of an existing one doesn't save all the crap (pix,
> configs, sounds, fonts) once again, but rather specify the original theme,

the current iconthemes already have a mechanism to inherit from each other.

> 8) do we include "feel" configs in a theme too? (like number of desktops,
> or layout of kicker etc. - personally I wouldn't like this, but I have to
> ask).

Sure. From a user's pov: Why not?

Greetings,
Tackat


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