I realize that plugin might, indeed, be a problem for the code separation. I propose to make plugins highly related to the UI, at first. It's indeed where most features are wanted.
Features needed could be implemented in the core if we want, even if we don't have an UI for them (for example, we could have support for a task attribute FOO in the core and don't use it in the GTK ui). In the future, it would be indeed great to have also plugin support in the core but that would come later and I see it as less critical if we have backend. Let see: - Tomboy/Gnote : purely UI plugin. - Notification Area : purely UI. Might enter the trunk. - Evolution : will be replaced by a backend - Closed tasks remover : core. But the feature is useful enough to be implemented in trunk - Send by mail : purely UI and top level actions. - Bugzilla : purely UI - RTM : will be replaced by a backend - Export and print : core features should enter the trunk. Formatting is part of the UI and will be a plugin. - Hamster : purely UI - Import from JSON : replaced by a backend ? - Geolocalized : UI and core. The core part could be done with support for generic attributes in Tasks, making the plugin purely UI (only a matter of setting/displaying one attribute) Paul, I feel that your work will involve working a lot with the plugin API too. Could you think about it ? -- https://code.launchpad.net/~gtg-contributors/gtg/code-layout/+merge/26624 Your team Gtg developers is requested to review the proposed merge of lp:~gtg-contributors/gtg/code-layout into lp:gtg. _______________________________________________ Mailing list: https://launchpad.net/~gtg Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg More help : https://help.launchpad.net/ListHelp
