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

[Carlos Eduardo Rodrigues Diogenes <cerdiogenes yahoo com br>]

-------- Original Message --------
Subject: 	Re: [g-a-devel] gnopernicus: srcore module - what is the 
function of srctrl.c
Date: 	Wed, 02 Nov 2005 08:46:16 +0000
From: 	Bill Haneman <Bill Haneman Sun COM>
To: 	Carlos Eduardo Rodrigues Diogenes <cerdiogenes yahoo com br>
References: 	<4367BD5D 9050109 yahoo com br> <4367E70C 20002 sun com> 
<4367FC70 3030405 yahoo com br>



Carlos Eduardo Rodrigues Diogenes wrote:

> Bill Haneman wrote:
>
> > Carlos Eduardo Rodrigues Diogenes wrote:
> >
> > > Hi,
> > >
> > > What is the function of srctrl.c in srcore? I don't understand it. 
> > > Can anyone explain me what this part of the program and for what are 
> > > all that static functions (they are used? I search the functions 
> > > that are called by the functions declared in srctrl.h with cscope, 
> > > but appear that any static function in this file is called.)?
> >
> >
> >
> > This looks to me like the main control source for all gnopernicus 
> > settings and commands.
>
>
> I find it strange, because all the functions are static and many 
> functionalities that are implemented in srctrl.c is in srmag.c too. 
> The main control is changing and being more modular? The srmag.c is 
> substituing srctrl.c?

It's just a case of too many layers.  I can't explain why this is.  ;-)

> > 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).
>
>
> It does not appear to be a good way too, it's not so much slow? 

I don't think speed is the problem here.  And I don't think it 
necessarily accesses the disk each time here.  However, the gconf 
developer docs say that one should not use gconf as an IPC mechanism.

> If gconf mantaim something like a proxy and do not have to access the 
> disk every time that an information is required it's is not so bad. So 
> if the things happen this way, srcore have to make pooling in gconf to 
> know if something have changed?
>
>  From what I saw in the gnopernicus code, I think that the design is 
> changing, it really is? Can someone from BAUM explain how the srcore 
> module is organized and give an roadmap what is being thinked to the 
> future, so we can understand it bettter?

I don't know; by the way, your last email was sent to me only, not to 
the list.  I have replied to you only.

Bill

> Carlos
>
> > Bill
> >
> > > Thanks,
> > > Carlos.
> > > _______________________________________________
> > > Gnome-accessibility-devel mailing list
> > > Gnome-accessibility-devel gnome org
> > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel