Printer Plugin Design

The printing system will require rethinking as we consider plugins... = = =The Present= Our current system works like this...

printer.py

• the printer module attempts to import one of three printers (lpr, gnomeprint, winprinter), each of which must implement RecRenderer and SimpleWriter. Thus, printer.RecRenderer will point to lpr.RecRenderer, gnomeprint.RecRenderer or winprinter.RecRenderer, depending on your system (the order of preference is something like gnomeprint / winprinter / lpr).
• recrenderer is a class that is instantiated with our recipe database (rd) and the recipes to print (recs) and a possible multiplier for ingredients (mult)
• SimpleWriter is used to handle e.g. shopping list printing (though it could be used by plugins to print other things as well). It is a simple text printer that has the methods write_header, write_subheader, write_paragraph and close (do printing).

=The Future?= Base class GourmetPrintManager handles all printing requests. This is parallel to our ImportManager and ExportManager.

• GourmetPrintManager, like ExportManager, is a pluggable that can take our different printer backends as plugins.
• Unlike ExportManager, GourmetPrintManager typically will only have one printing plugin it cares about -- whatever is right for the given OS. This should not be user selectable, though it is possible that in the future we'd have plugins like "Recipe Card Printout" that we would want to be user-selectable.
• Each Printing plugin provides a get_simple_writer method and a print_recipes method which handle these functionalities.
• Plugins might also provide a print_preferences setting... this is a bit tricky since this will look different in different backends.
• Plugins that modify printing will need to act indirectly (e.g. by modifying the exporter classes that which will likely be subclassed in printer subclasses, or by subclassing the plugins, which is complicated in itself)

Changes to the Plugin System

• The default plugins list will need to become more sophisticated to allow fallbacks... if we can't import the new gnomeprint, we use the lpr plugin, etc.
• The plugin_loader / plugin_gui should probably allow some plugins to become user-invisible, perhaps by being marked "essential" or something like that. The user, of course, would never want to disable printing entirely, so it doesn't make sense to give them that ability. That said, it is possible that the user will want to replace the default printing plugin with one of their own... perhaps something like

status = essential - keyword for base plugin. Then, replaces = printing - keyword for plugins that replace an essential plugin.

Or, we could have a meta-plugin that chooses the correct sub-plugin...

printing - provides the best printer available.

All of this would require a more complex dependencies system for plugins than is probably necessary...

=The Other Future= The other alternative would be to treat printing differently from exporters and importers. Gourmet handles printing internally. People who want to change printing will either just change Gourmet's code, or implement plugins that alter the default printer.

The new printer will be implemented using the new gtk PrintOperation set up and the existing legacy code can be used as a fallback for people with an out-of-date GTK (http://www.pygtk.org/docs/pygtk/class-gtkprintoperation.html#id3425092)