From: Gerald B. <ger...@gm...> - 2009-03-23 02:22:51
|
Brian et al, I guess I don't understand the question re multiple implementations. My purpose for the Html class is to provide a. simple, robust framework for building pages. I think I achieved that at least. I would be gratified if others found it useful but won't lose any sleep over it if not. As to where it should live, I'm open to suggestions. It is only under webreports at the moment for convenience. Benny seemed to think that it belongs with other html stuff and that makes sense to me in concept. However I haven't had a chance to study that yet. Hopefully. in the next few days I will be able to. Naturally if it turns out that it belongs with the other plugins I will formalize it as requested. I do however question the utility of showing library functions in the plugin status page and would like to see that policy revisited. Displaying them provides no benefit to the end user and removing their display would harm no one. Perhaps we need a different place to store helper modules for plugins that makes them available without requiring their self-registration nor display in the plugin status list. Just a thought. On 3/22/09, Brian Matherly <br...@gr...> wrote: > > 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 > -- Sent from my mobile device Gerald Britton |