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

List:       kde-usability
Subject:    Re: Theme manager classes
From:       Ravikiran Rajagopal <ravi () ee ! eng ! ohio-state ! edu>
Date:       2003-04-21 20:40:26
[Download RAW message or body]

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

Hello,
  There are a few problems with the approach you outline. The biggest one I 
see is that DCOP requires the applications (KSplash, etc.) to be running when 
we save the settings from the KCModule. This is not realistic - atleast for 
KSplash.
  Here's my modification of the approach which is relies heavily on the 
KTrader framework. A "meta-theme" is a collection of themes for each 
application it can configure. Here's an example of a meta-theme file:

[Metatheme: MyMagicTheme]
Base metatheme=InheritThisMetaTheme
Window Decorations=Keramik,Liquid,Glow
Widget Style=Liquid,Keramik,Modern
Icons=Slick,Technical,crystal
Color Scheme=Emerald,Diesel
Splash Screen=MacClassic,Default
Noatun Skin Plugin=KJofol
Noatun KJofol Skin=Maegashira,Hex

1. Every application that wishes to be configured via a meta-theme provides a 
KDE service of type "Theme Module". This is a theme control module loaded by 
the theme manager, which provides a read-only interface which takes a list of 
themes and a theme directory as input. The theme control module provides a 
widget which can preview themes, and save theme information.

2. Each theme control module goes through the list of themes provided, and 
picks the first one actually available on the system or a default. It then 
generates a preview, and saves the information from that theme if told to do 
so.

3. When our theme manager reads a meta-theme and goes through its inherited 
hierarchy, it provides a list of check boxes allowing the user to turn off 
particular parts. In the example above, we provide checkboxes for window 
decorations, widget, style, icons, ..., naotun kjofol skin (assuming 
Inherited theme does not define more objects to configure). Depending on the 
checkboxes that are actually checked, we present tabs for preview of each 
feature. Ideas about integrating all the previews into a single canvas are 
welcome.

4. That's it for the KControl module.

My interest lies in a theme manager class that can be reused by standalone 
applications, which I think will be used by each of the modules mentioned 
above. This would simply be an abstraction of the class found in 
kdebase/kcontrol/thememgr.

Flames and suggestions welcome. Now I have to go back to thinking about Szego 
polynomials on the unit circle, and about getting some start on MathML 
support in khtml, so that I can HTMLize my dissertation. Damn.

Regards,
Ravi

Mosfet wrote on 2003-04-13 3:44:09:

The basic thing we were discussing in regards to a theme management library is 
that there is so many different applications to configure: KSplash, KDesktop, 
KPanel, KWin, widget styles, color schemes, etc... I think this should all be 
encapsulated into one API. Others wanted to use DCop to configure application 
themes. The end result is that we would make a general API that contains 
configuration methods for all these different things, then make the library 
call DCop as applications support it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+pFc6bI8Y8y0oVXcRArNsAKCO15+rN2YqeAy/50CHI6Ez1aLWEACeJU9+
IQVfwSWrW4sas+dNM1x0Yf0=
=KaKU
-----END PGP SIGNATURE-----

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability

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