bastian at kde.org
Thu Jun 26 16:19:06 BST 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Thursday 26 June 2003 16:30, Ian Reinhart Geiser wrote:
> On Thursday 26 June 2003 10:13 am, Waldo Bastian wrote:
> > On Thursday 26 June 2003 15:13, Ian Reinhart Geiser wrote:
> > > Needless to say, for end developers there is no reason other than to
> > > build a backend that one needs KConfigBase, and from what I can see
> > > KConfigBase should go away asap. Unless someone (waldo) knows of a
> > > VERY good reason why such an evil pair as KConfig/KConfigBase should
> > > exist together?
> > KConfigBase provides the API, KConfigBackEnd the backend, and KConfig
> > provides storage and ties the two together.
> Well see this is where things get confused. KConfigBackend relies on code
> that is only in KConfig, but can only be accessed in KConfigBase. Worse
> KConfig provides the storage, with no knowledge of the backend, so we
> cannot safely move the storage to the backend where it can more effectively
> be cached. Also storeing the config in the kconfig object ensures we will
> never be able to merge config backends without some expensive operations.
> Unless we start to muck with the kconfig entry map. I started down this
> route, but got stuck on a few issues of how to dirty only a single entry
> from the backend or from kconfig... Really if only the backend had access
> to the entry map directly, or if the frontend didnt flush the whole thing
> when anything is updated, we might see an improvement.
I think the main problem is that the KConfigBackEnd API is not flexible enough
for things other than file_based formats. That's hardly surprising, because
only the INI backend has ever been developed, so design-requirements of other
backend-styles have most likely never been seriously considered.
> > This gives you some design flexibility that allows for things as
> > KConfigGroup which implements the KConfigBase API, but shares the backend
> > and storage of another KConfig object.
> Im seening a greatly simplified API by just removeing KConfigBase and
> keeping the storage in the backends. The kconfig class is confused, it
> has no idea what its role in the mess is... is it storage? is it an
> interface to the configs? is it both? if so whats the kconfigbackend
Storage and glue as far as I can see.
> Maby im trying to over refactor it, im not sure. But the orignal
> intent of the API has long been lost, and IMHO its time to clean it up so
> we can get back to what it was orignally inteded to do.
I think the original intent of the API is described in KCONFIG_DESIGN. I think
things have changed much since that was written.
> > I don't see any reason why it should go away. You say yourself that you
> > hardly ever use it as an "end developer", so why do you care about it
> > either way?
> I care becase im trying to fix it ;) Really no-one will ever notice when
> im done other than maby some speed improvement
Why do you expect speed improvements? I would only expect to see those if
there is a fundamental inefficiency in the current way of doing things. If
you are aware of one I would like to hear about it.
> and a reality of multiple backends.
That would be nice.
> One other side part im working on is better ways to keep
> applications in sync with each others instances.
It would be nice if we could hash out the desired semantics for that. I think
you need a deamon to do it efficiently and I guess you need some sort of
locking semantics in the API towards the application.
I also wonder whether the syncing needs to be optional (on request by the app
only) or not. From the application point of view, syncing basically equals to
reparseConfiguration() being called automatically. Applications may or may
not expect that, otoh KDE wide changes of styles / colors / etc. already do
exactly that, so I guess it doesn't have too big of an impact.
> Currenly we do this silly
> little tell everyone to reparse their config files via KIPC... while this
> approach is effective, its painful for things that use many config files...
But that's fundamental I would think. Using many config files is painful in
and of itself and shouldn't be done if it can be prevented. The only other
thing that we have some control over is to make sure that we report changes
fine-grained enough so that we don't reparse config files unnecassery.
Otoh I know from my work on the theme manager that the biggest problem with
for example theme changes isn't the reparsing of the config files, it's the
updating of the widgets. The biggest problem was to make sure that the theme
manager reported all changes at once so that all widgets where only updated
once. If you end up reporting changes one by one (e.g. fonts have changed,
color has changed, style has changed) applications end up updating their
widgets way too often and you end up with a desktop that flickers for 5
So I think you have two requirements in this respect that are a little bit at
tension which other: On one hand you want fine-grained change notification,
on the other hand you want them to be atomic.
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com
(1) Well, maybe 10 seconds, but it felt like 5 minutes and I bet it could have
been 5 minutes if my computer was slower and I had more windows open.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
More information about the kde-core-devel