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

List:       kde-core-devel
Subject:    Re: IRC Meeting on KDE 3 Theming [Was: Re: Reminder 2nd November]
From:       Cristian Tibirna <tibirna () kde ! org>
Date:       2001-10-28 13:05:17
[Download RAW message or body]

On Sunday 28 October 2001 00:56, Neil Stevens wrote:
> On Saturday October 27, 2001 08:36, Ilya Konstantinov wrote:
> > Quite simply - we need to move WM Decorations, Themes and Styles into
> > one KControl module.
>
> Having two, three, four rows of tabs in a module will be hard to use and
> navigate.  You'd probably end up removing it from KControl to break it up
> into different modules again.
>
> Ever seen an MS Word 95 config dialog?  My memories of the Office 95
> config dialogs, with row after row of tabs, aren't pretty.

Nobody implied that we should use tabs after tabs after tabs. We can find 
elegant solutions.

I was, just earlier, about to prepare a message on this very topic. There 
exist examples of implementations of what I mean, and there exist clear 
situations of what I mean can be adapted.

The good example: If you look at te KNotify config, it is an example of 
bringing together a bunch of very similar config options, from different 
apps. The particularity in the case of KNotify is the uniformity of the raw 
KConfig support present in the backend (i.e. .events files installed by each 
app in a standard location). 

But we can use the same approach, with minimal changes, to situations 
concerning apps that are storing the effective KConfig info in completely 
disjoint files. The heterogeneity of config files that have to be supported 
isn't a barrier.

Now the bad example: if you were around in the time of KDE-1, you might have 
been interested and you might have looked at the fonts configuration. There 
was a rudiment of this "centralisation of similar functionalities" principle. 
The initial idea was to make possible to have all apps put their font related 
configuration in one single KControl module. The things didn't go too far, 
all apps have now their font configurator (konq has 2!!).

What I envision is to still rely on the current saving of KConfig font info on 
a per app rc file basis, but use a centralization mechanism. It will consist 
of:
- backend (KConfig keys in spread around rc files) - already existent
- backend centralizator - an XML file for each app specifying:
	- app's identification
	- app's font keys - one entry per key
		- identification of the font key
		- default value
		- value limitations (e.g. fixed fonts only)
		- rc file, kconfig group, kconfig key names 
- frontend (a kbookmarkedit-like or knotify-like listview + widgets)

We can improve a lot on this basis.

And the spots where this kind of approach applies are a few.

CT

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