Re: [Fwd: 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 18:08, Carlos Eduardo Rodrigues Diogenes wrote:

> >
> > 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.  ;-)
> 

Any screen reader uses script to allow users to customize the
functionality. The intention is to have this support in gnopernicus too.
These scripts should be able to control everything in gnopernicus. For
this, they should have the possibility to intercept and change the
"internal gnopernicus commands". In the light of this, gnopernicus has a
commands queue. In this queue are put the commands (as strings). Every
string has associate a command (a C call). The string representation is
very useful because user has the possibility to map those commands to
keys, and it will make the script clear.

> >
> >>
> >> 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.

That's true. Also, users don't change settings all the time, so, using
gconf is not doesn't slow down gnopernicus.

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