Re: [g-a-devel] gnopernicus: srcore module - what is the function of srctrl.c

[remus draica <rd baum ro>]

On Wed, 2005-11-02 at 00:07, Bill Haneman wrote:

Hi,

> 
> Realize that 'gnopernicus' and 'srcore' are two separate binaries, 
> 'gnopernicus' spawns 'srcore' and communicates with it via gconf.
> 
> (That is not the recommended way for applications to use gconf, but 
> that's how gnopernicus does it).
> 

One goal of gnopernicus design was to have permanent configuration.
Another one, was to separate the screen reader from the interface. 

For permanent storage we had to choose from several options:
  1. implement something in gnopernicus (a lot of work, with a lot of
possible bugs, etc)
  2. use gnome-settings (which was and is deprecated now)
  3. use gconf. 

The gconf, beside of being nonvolatile, has the advantage of notifying
clients when a key changed.
Because of this, and the idea of having the UI separate, gconf looked
the perfect choice. Gconf IS NOT used to send information from one
process to another in same way a pipe is used. 

Because some settings can be changed from both processes (eg volume), a
communication is necessary because, always the settings shown in the UI
should reflect always the settings of the screen reader (srcore). So,
the communication is used just to inform one of the 2 processes to
re-read some gconf keys.

Bill, why do you think that "is not the recommended way for applications
to use gconf"? How do you think that the problem of keeping 2 process
synchronized (as settings) can be solved? What are the other options
(beside gconf) for doing this? Do you think that gnopernicus should be a
process? (in this case keeping the UI and srcore synchronized is a
little easy)

Regards,
Remus