From kde-core-devel Mon Nov 11 12:26:47 2002 From: Ralf Nolden Date: Mon, 11 Nov 2002 12:26:47 +0000 To: kde-core-devel Subject: Re: Experiences with KDE-CVS at LinuxWorldExpo X-MARC-Message: https://marc.info/?l=kde-core-devel&m=103701770532155 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Montag, 11. November 2002 13:12, Waldo Bastian wrote: > At 15:10 -0500 11/10/02, Havoc Pennington wrote: > >On Sun, Nov 10, 2002 at 04:04:20PM +0100, Marc Mutz wrote: > >If anyone is seriously interested in a server-based config solution, I > >should point out that I'm willing to strip all the CORBA dependencies > >etc. out of gconf, sync it to KDE release cycles in addition to GNOME > >release cycles, rename it, move it to shared CVS, whatever it takes. > >I wrote up some details on gconf and its role in this kind of central > >config setup, see http://www.linuxsymposium.org/2002/ proceedings (I > >think, haven't checked). The paper for OLS also contains some > >discussion of ACAP. > > To solve the documentation problem I think schemas would indeed be a > good solution but I would rather not have to read them during normal > operation. Config options are typically used in two places: in the > application itself and in a config dialog. Currently in KDE defaults > are hard-coded in the code (typically in multiple locations, which is > a maintenance problem) I think it would be acceptable if schema's > where used for the config dialog but in the application itself this > causes rather unnecessary overhead IMO. To ensure consistency between > the defaults defined in the schema and those used by the application, > the application could optionally (e.g. when compiled with > --enable-debug) run in verification mode where it reads the schema > and verifies that the application does indeed use the same defaults. > This could then be skipped in normal production use. This is what I thought about. Ideally, the application should have a commandline option in debug mode to generate the output of the file, or even better, write the default config file as a system-wide installable file during the build by calling the application with --generate-configfile once after the binary has been created. That always ensures that the packages build for KDE applications contain a unique system-wide config file which is consistent with the hardcoded options in the application. Ralf > > The other thing that concerns me is the communication overhead with a > (local) daemon, does a GConf application make roundtrips to this > daemon for every config-key it needs to lookup? > > Cheers, > Waldo - -- We're not a company, we just produce better code at less costs. - -------------------------------------------------------------------- Ralf Nolden nolden@kde.org The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9z6IIu0nKi+w1Ky8RAtJkAJ9hYowRJFG8bXSbg7l+swExM7HctgCgt5lH AwuTD1F/NpkyW1z35kDqMfE= =mGSm -----END PGP SIGNATURE-----