From: Brian M. <br...@gr...> - 2009-12-15 14:02:03
|
Benny, > > Are you suggesting that src/gui would have a > dependency on src/cli? If so, I would probably not support > that. My goal is to have no dependencies between gui, cli > and web. In my opinion, NameDisplay, DateHandler, etc all > belong in gen. Perhaps a "gen/display" or "gen/format" > directory would be appropriate. > > Already there is a dependency of src/gui on src/cli. When I > created > cli, it became clear that cli needed reduced functionality > from what > was present for gui. So the way I did eg dbmanager, was to > write a > reduced version for cli, and then let the src/gui component > inherit > from this and extend with the extra things needed. The > alternative I > envisioned with a component in src and then an empty > wrapper in > src/cli, and an extension in src/gui looked artificial. Ok. Now I see where you are coming from. I don't really see it the same way. In my mind, CLI is not a subset of GUI. I think the two should not need to know about each other. > Some way of handling these situations is needed, while I > don't think > this functionality should be in src/gen, because then one > would move > cli functionality to src/gen only because gui needs the > same thing > with gtk dialogs instead of prints. > > Main point here is plugins that want to offer CLI and GUI > part. To > make it independant of gtk, we need to offer abstraction. > A > theoretical example: ErrorDialog, that in cli is > implemented as a > print to screen, but in gui as a popup. So we need to > implement > something like ErrorDialog in cli and in gui and offer a > way to the > pluginwriter to have correct import depending on if the > report is run > in cli or in gui. > > I see two possible approaches: > > 1/ the plugin writer must know it himself, and do > conditional imports, > so in a certain reused method: > if GUI: > from gui.widgets.dialogs import > ErrorDialog as errormsg > else: > from cli.widgets import errormsg > and then use errormsg in his code. We provide some > functions that do > that to make it easy. > > 2/we offer a mechanism that selects for the plugin writer > himself the > correct function/method. In this system, gui would extend > cli > functionality (using inheritance to keep parameter lists > identical) > and doing in a report > > from gui.widgets import ErrorDialogs > > would automatically use the cli version if gramps is in CLI > mode > (which we know on startup, so the __init__.py can take it > into > account) #2 is exactly the direction I am planning on going. It just might take some time to get it all worked out. ~Brian |