xffm, libraries and 'interface'

[edscott wilson garcia]

El mié, 22-09-2004 a las 23:03, Maarten Boekhold escribió:
> > Do you need a list of all symbols exported from the executable to normal
> > libraries or to module type libraries? 
> 
> Both...
> 
> > Also, do you need a list of symbols exported from normal libraries to
> > modules? And from normal libraries to each other? 
> 
> Hmmm, from libraries to modules perhaps not, as we could link the 
> modules against the libraries. But from normal libraries to each other, 
> perhaps. I suppose it depends on the link order. If we have library A 
> that references B, and B references A, then there's a circular reference 
> that you can't resolve with a specific link order. In that case I 
> suppose we need those symbols in an IMPORTS file.
> 
> I haven't yet come across such a situation, so I'm not sure what the 
> syntax of such an IMPORTS file should be, i.e. I'm not sure if:
> 
> IMPORTS
> the_symbol = thelib.dll.the_symbol
> 
> will work. This will require a bit of testing.

OK. The final formatting of the IMPORTS file can be done by testing. 

> 
> > I suspect you will need all.
> > 
> > If that is the case, I can change all "extern" statements to 
> > G_MODULE_IMPORT, and then write a perl parser to create an IMPORTS file
> > (this will make maintainance easier since symbols are moved around at
> > times).
> 
> I did something similar with the panel, except I created a shell script 
> that works on G_MODULE_EXPORT (i.e. not G_MODULE_IMPORT). Actually, I 
> couldnt' work out how to directly extract that from the source, so I 
> added comments /* EXPORT:symbol */ to the panel source code...

I believe it might be easier to do with perl.
  
> 
> > Using "G_MODULE_EXPORT" for all exported symbols would be no problem
> > (AFAIK, in Linux it gets expanded to nothing). In fact, it would make
> > the G_MODULE_IMPORT scheme described above a bit clearer. Would using
> > G_MODULE_EXPORT in front of the symbol definitions work instead of
> > DLLEXPORT?
> 
> G_MODULE_EXPORT works fine. G_MODULE_EXPORT expands to the same thing as 
> DLLEXPORT (in fact I copied this from the gmodule.h file...)
> 
> G_MODULE_IMPORT would look more correct, but it expands to 'extern' on 
> just about every platform I know about, so if you really want, you can 
> keep the 'extern' declaration.

OK. I will start adding this to the source. I should probably be done in
a day or two.

> 
> Did I understand from one of your previous mails that you are in the 
> process of converting lots of these 'normal libraries' to 'modules'? 
> I.e. move them from ../libs to ../modules?

Just the libraries that take care of the bookmarks, recent/frequent, and
trash branches. The idea is to allow the writing up of branches as
plugins.

I would also like to convert other libraries to plugins (for startup
performance reasons) but they are currently quite tangled up. 

> 
> Jasper mentioned that he was planning on converting the panel (and 
> other) plugin interfaces to use GtkPlug/GtkSocket. I don't know (yet) 
> what that actually is, but if you are reorganizing the modules/libraries 
>   handling for xffm, it might make sense to have a look at this as well, 
> to come up with a consistent model across xfce. This would be for 4.4 or 
> later of course... I was planning to start looking at this as well, see 
> if I can help jasper out with this.

This, AFAICT, is so that segv signals in the plugins will not crash the
panel. We must see how it works in the panel to decide whether
GtkPlug/GtkSocket would be applicable.

regards,

Edscott