gnc_plugins

[Chris Shoemaker]

On Fri, Dec 31, 2004 at 01:21:08PM -0500, Derek Atkins wrote:
> Chris Shoemaker <c.shoemaker at cox.net> writes:
> 
> > I noticed that there are (at least) two ways that GncPlugins are added
> > to the GncPluginManager:
> >   1) in gnc_gui_init() in top-level.c: gnc_plugin_manager_add_plugin
> > is called explictly.  (with a comment about removing this usage)
> >   2) sometime before gnc_gui_init() is called, several other plugins
> > are added, e.g. stylesheets.  I'm not really sure how, but I think it
> > comes from scheme-land, e.g. perhaps: (load-module
> > "gnucash/report/stylesheets" 0 #f) ?  (which also has a comment about
> > eventually making modules loaded automatically instead of statically)
> >
> > So, what's the right way of adding plugins to the plugin manager.
> > Keep in mind I'm considering a plugin that doesn't (currently) have
> > any scm component.
> 
> You don't need a scheme component in a module, however I can't think
> of any modules where you would not want a scheme component in order to
> export your module functionality to the scheme interface.

Hmm. I'll think about that.

> 
> gnc_gui_init() is an internal function that initializes the GUI.  You
> shouldn't use it yourself.  You should, instead, plugin your menu
> options using the various sets of APIs available to do so.

Of course I'm not _calling_ gnc_gui_init() , but gnc_gui_init is
currently where 3 plugins are added to the plugin manager, with a
comment suggesting that this is not the best place to do so.  Where's
the better place?

> 
> > And, while I'm asking about gui stuff... what about gncPlugins
> > vs. gnc_menu_extenstion_ stuff?  All the Reports menu stuff uses
> > gnc_menu_extensions and no gncPlugin at all.  
> 
> gncPlugin is a new-in-g2 api; the gnc_menu_extension is the older
> interface.  There's no reason to use one vs. the other as far as I
> know.

Why was a new api needed?  Because if one is no better/worse than the
other, I can think of a good reason not to have two - headaches.  :)

Are you implying that the plan is that gnc_menu_extension stuff will
be converted over to use gncPlugin in the g2 branch?

> 
> > There are so many menuing APIs in use, it makes my head spin (or is
> > that the egg nog?)  Can't we all just use the same one?  :-)
> 
> No, we can't.  We need one API from scheme, one from C, and we need
> static and dynamic interfaces.  The reports are all dynamic so they
> need a dynamic menu interface.  However the business features are
> static, so they can use a static interface.

I wasn't even counting the scm interface.  We have _more_ than one
from C.  Also, isn't static menus just a special case of
dynamic. i.e. a dynamic menu that's merged during window init and
never unmerged.   Surely one API can do both, right?  

Actually, perhaps reports and business features are a good case in
point.  I see _in_the_code_ that reports menus are dynamic and
business feature menus are static, but in the actual gui behavior, I
don't see much difference.  Both menus are there all the time, right?

> 
> > What shall it be?
> 
> Use whichever is reasonable for your module.

Not the answer I was looking for. :(

If I knew which was reasonable for my module, I probably
wouldn't have started this thread. :( Of course I could have just
tried do everything my own new way, but that's just dumb when there
are good ways already available.  So, I try to see what those ways are
for managing menu items, what libraries are used, what APIs are used,
etc.  But, what I find is that there are a few different homegrown
(unique to gnucash) apis to do pretty much the same thing.  Besides
confusing novice gnucash hackers like me, I imagine it must be a
maintanence headache.

Seriously, I estimate it would probably take 4 times as long just to
figure out the differences among the different menuing apis, than it
would be to actually implement my menu items in any one of the apis.
And, all choices _MAY_be_ equally good.  (You said you don't know of
any reason to use one over the other.)  But that's not the point.  It
takes a fair bit of work to figure that out.  That's my point.

So, to make things easier, let's spare new developers the hassle of
learning, evaluating and then choosing a menuing api.  So, for C, and
for g2, can we at least proclaim a _preferred_ menuing api?

-chris