On Fri, 2007-01-05 at 09:02 -0800, alan wrote:
> On Fri, 5 Jan 2007, Peter Gordon wrote:
> > On Thu, 2007-01-04 at 21:20 -0700, Trever L. Adams wrote:
> >> And as of the last version, compiz had a horrid configuration (read
> >> almost none) for the different plugins, etc.
>
> Saying it is in gconf is like saying to a Windows user that "You can just
> make changes in the registry to configure it". It is a non-obvious
> configuration option.
It may be non-obvious, but it is there; and it allows you to change
virtually any aspect of Compiz's behaviour and/or appearance. This is
hardly "almost none" as you had stated.
> I am not certain why gconf is a "better" solution.
From a corporate administrative stand point it has things like lock-down
and standard profile capabilities. From the standpoint of a user, it
also means that the preferences are applied immediately (yay for
inotify!) and for developers means that the information-manipulating
code is already written; i.e., one does not need to write code to parse,
read, and write file foo.cfg for various aspects and can instead simply
call the various GConf library functions to read or write data in
various configuration parameters. It also makes for having such code be
reusable by virtually any application that needs to store configuration
data. This is called encapsulation and abstraction; and it is nearly
always a very good segment of one's program design.
For example:
Beryl might (I haven't checked the code) do a configuration algorithm
such as:
1. Create a file descriptor and map it to the file
~/.config/beryl/user.cfg, opened in read-only text mode
2. Read the file contents and parse them into a configuration
storage structure
3. Poll the config file every so often for changes and re-read them
into that structure if there are any
4. Call wrapper functions on that structure to retrieve specific
data pieces as needed
Whereas with GConf it's theoretically quite a bit simpler:
1. Call gconf_client_add_dir and gconf_client_notify_add to
register a callback function for when the configuration is
changed.
2. Call gconf_client_get or other gconf functions as needed to
retrieve a specific key
3. That's it :)
Also, the GConf on-disk structure is XML, which makes it much better
suited for automated manipulation tools.
> It makes moving users
> from one version to another difficult. (More than once, I have had all
> the configuration data tied up in the gconf blob. Not easy to say "pull
> all the configuation for app x".)
Actually it is. The tree of gconf keys should contain a /apps/app-name/
subtree that you can pull with a simple cp or mv (the
~/.gconf/apps/app-name/ directory on-disk).
> Compiz themes are different from Metacity themes. They just added to
> them.
Right, but work is underway in Compiz to have both it and Metacity use
the same theming/rendering infrastructure, as I've read on various
Planets. Does Beryl have similar intention of desktop integration?
> I do know that I have been able to get Beryl to work consistantly. With
> Compiz, I am lucky to get the window decorations to come up most of the
> time.
The fact that something works and whether or not it is functioning and
designed properly are two entirely separate things. ;)
--
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
My Blog: http://thecodergeek.com/blog/
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
