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

List:       kde-usability
Subject:    Fwd: Fist proposal of a kthemecenter interface
From:       Daniel Molkentin <molkentin () kde ! org>
Date:       2002-05-18 1:06:19
[Download RAW message or body]

Moin!

The attached mail is something I recently sent to an intrested group wrt to a new 
themecenter. However, I am not involved enough into styles and most of the 
addresees are short in time and I feel that important things like theming should 
be discussed here.

Cheers,

</daniel>

----------  On Saturday 04 May 2002 20:48, Daniel Molkentin wrote:  ----------

Subject: Fist proposal of a kthemecenter interface
Date: Sat, 4 May 2002 20:48:57 +0200
From: Daniel Molkentin <molkentin@kde.org>
To: Karol Szwed <gallium@kde.org>
Cc: Fredrik Höglund <fredrik@kde.org>, Maksim Orlovich <mo002j@mail.rochester.edu>

Hi!

I finally found some time to start work on the new theme manager (called "KDE
Theme Center"). I'm still not so good equipped with time but this will change
in a week as my civil service is finally over (*phew*) and I'll get myself
some free weeks until my new job starts.

Attached you'll find a very first proposal for the themecenter (Header files
only as well as a designer file showing the basic layout of the modules). For
now I made it a kcontrol module but it should be no problem to have it as a
seperate app later on.

It was designed keep the current idea of configuring theme aspects in
seperatate dialogs (Maksim noted that it would be better to have ONE dialg with all 
theme aspect as tab as opposed to what I send attached here and I think he is 
right) but gives a unified preview and allows loading and saving
of themes. Basically, this is might the dead of the current .themerc files in
favour of an XML file. For now, I think we might need to export the contents
of the XML file to a .themerc file.

It outlines the basic structures but also raises some problems:

- when and how should we generate the actual config files from the xml file?
- Should the handler be in charge to keep his module up to date (load, save,
defaults?). I think we should simply add a virtual method to ThemeHandler
that returns a pointer to the dialog to gain access to it.
- how do we handle the fact that all all modules have access to the preview
window, given we make themehandler a public API to allow 3rd party
programmers to add their own theme aspects (like splash, but I want that in
as default this time).

I am sure there is a lot of space for improvements and maybe you have an even
better idea for the basic framework. So what do you think?

Cheers,

</daniel>

--
Daniel Molkentin | The K Desktop Environment | http://www.kde.org
KDE 3.0 - Konquer your Desktop!

-------------------------------------------------------


["kthemecenter-proposal.tar.gz" (application/x-tgz)]
["themecenter.ui" (application/x-designer)]
_______________________________________________
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]