[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 3:20:27
[Download RAW message or body]

On Saturday 27 October 2001 22:12, Neil Stevens wrote:
> > Well, I don't agree. We don't need yet another API to deal with. We need
> > to make KControl more clever.
> >
> > Some sort of versioning control for all KDE configuring options, plus a
> > standard for extracting, applying, managing them, plus a central
> > transparent server (not the usual themes web page, but a server with
> > specific functionality, so that user can uniformize automatically config
> > between distinct networked machines) would be in order.
>
> It is possible to over-engineer something.
>
> In the case of look and feel, we have a specific need, and a specific set
> of users that wants it.  If you go overboard making it too complex, you
> lose the users that wanted it in the first place.


OK, point taken. I used generic concepts trying to say a very specific thing. 
Sorry for the noise. I will start again.

1) KDE look config is *already* done entirely. It needs manual intervention of 
the user on each and every parameter. The lowest (and only?) level support 
for the KDE look configuration is a set of config files in the KDE fs.

2) The KControl set of technologies (KConfig, KCModule etc.) is used to 
manipulate KDE look config. The current KControl setup "works" but can't be 
proven as optimal (e.g. desktop background color config separated from color 
scheme config - explainable from a programming pov, not sustainable from a 
user logics pov; even worse, desktop background color config completely 
disjoint from icon label color config).

Thus, what I say: instead of inventing a 7th wheel for this (5 years old) 
cart, call it nice names and saying it will avoid over-engineering, I believe 
more in rearranging (not rewriting!) the KControl system so that it gets a 
logical layout instead its current programmatic (developer's fisheye) 
structure. In the process, we will be able to make things more easily 
conceivable with a single look from the average user, and offer technological 
means for future development into a versioning + distributing infrastructure.

A particular point in this whole mess is the need of analysis that the styling 
engine badly needs, be it at least for putting it into accordance with the 
current Qt-3 styling tehcnology (and cleaning KStyle up). A style editor, as 
well as a kwin Client style editor are almost mandatory too (perhaps using 
Qt-designer/uic-like methodology, perhaps).

Thanks for coping with my rants

CT

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