Wincent Colaiuta [Wed, 10 Nov 2010 18:57:15 +0000 (19:57 +0100)]
Provide registration mechanism
Note that we require plug-ins to explicitly register in order to
participate in the preferences UI. This fits in nicely with the
ability to disable plug-ins; if a plug-in is disabled, no code
from it will be executed, and therefore no registration will take
place and no preferences UI for the disabled plug-in will be shown.
Wincent Colaiuta [Tue, 9 Nov 2010 19:21:54 +0000 (20:21 +0100)]
Depend on com.wincent.fusion.menu
We need fusion-menu to be loaded before us. There is no need
to explicitly depend on fusion-base because it will be loaded
before fusion-menu and therefore before us too.
Wincent Colaiuta [Tue, 9 Nov 2010 19:11:22 +0000 (20:11 +0100)]
Add symbolic link and reference to fusion-menu header
Note that we don't use a submodule here for the sake of simplicity; we
instead just require the sibling project to be checked out alongside
this one (which will usually be the case because the different plug-ins
will live alongside each other as submodules in the parent project).
Also note how this interacts with the "-undefined dynamic_lookup" linker
option: we don't have any real (strong) dependencies between the
different plug-ins seeing as they don't have to link against each other,
and that in turn means we can get very fast build times (ie. a single
change to one plug-in will not necessarily trigger a rebuild for all the
others as well).
The only hard requirement here is that the Fusion framework headers
already be available in the build products directory by the time we
compile the plug-in. In practice this will usually be the case because
the superproject will compile the framework first. If I find that it is
not working out that way for whatever reason, I can always add another
symbolic link.
git.wincent.com / fusion-prefs.git / log
