From: Brian M. <br...@gr...> - 2009-03-22 20:26:40
|
Gerald, > But that's just my point. An end user has no reason to > know what the underlying libraries are for or even that they > exist. He needs to know about the plugins that are available > that he can use directly. The current status display does > that nicely. Consider the plugin status display for Firefox, > for example. You see what is installed and what sorts of > things each plugin handles but you cannot see what libraries > they use. Same thing, basically. for other programs like > gimp or gedit or many others. Open the plugin status window at look at the end of the list. "html.py" is already there. It just doesn't have a description. The src/plugins directory in the Gramps source tree is for storing plugins only. If something is not a plugin, it should not be in there. Some plugins are only libraries that are not directly exposed to the user. These library plugins reside in src/plugins/lib and they are registered with the plugin system. That is the current policy for plugins in Gramps. Please follow it. > On the other hand, I think I like Benny's idea: Move > the class so its part of the doc structure and make other > HTML classes derive from it. It would no longer be a plugin > that way but would perhaps have greater utility. I'm having trouble understanding how this would work. The current BaseDoc classes are interfaces only. There are multiple implementations that are plugins in src/plugins/docgen. How would that relate to the html.py file you have now? Would there someday be multiple Html implementations? ~Brian |