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 _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
