Comments
-
Greg Hurrell
I haven't yet provided a UI for manipulating plug-ins. And seeing as iChat is the only instant messaging client supported so far most of the code for the instant message component is actually stored here:
Synergy Advance.app/Contents/Resources/PreferencePanes/InstantMessaging.prefPane
You could remove that preference pane if you really wanted to, but I don't think there'd be any performance benefit at all because the component uses 196KB of memory and can be completely turned off in the preferences in which case it doesn't use any CPU at all.
Later on when there actually are multiple plug-ins for you to turn on and off I will add the plug-ins preference pane so that you can manipulate which ones get loaded or not, and which order they get consulted (if appropriate). You'll be able to turn this support on and off using checkboxes in the prefs.
-
John Davidorff Pell
Thanx for taking a look at my request so quickly. :-)
I believe that Finder has some UI for manipulating plugins in app bundles, it would be cool to take advantage of that (or maybe not, I don't really know :-D).
Also, can I ask about the architecture of your plugins? What I mean is, how do you plan on managing them. the iChat prefpane is a prefpane, I assume that other components will not all be prefpanes (will they?), so do you plan on doing "plug-ins" by just disabling assorted bundles in your app, or having a real "plug-ins" directory that holds specific bundles, each providing the various components (including a prefpane) inside it that can be loaded all togeter?
JP
-
Greg Hurrell
(In reply to comment #2)
I believe that Finder has some UI for manipulating plugins in app bundles, it would be cool to take advantage of that (or maybe not, I don't really know :-D).
No, it has to be written from scratch. The Finder doesn't export any API, it's just an application. Besides, I want a bit more flexibility. Some plug-ins will be inside the Synergy Advance application bundle:
Synergy Advance.app/Contents/Resources/Plug-ins/
But others will be in
~/Library/Application Support/Synergy Advance/Plug-ins/
Or:
/Library/Application Support/Synergy Advance/Plug-ins/
Some of the code that is currently in Synergy Advance I will actually split off into a framework, SynergyAdvance.framework, so that plug-ins can leverage it without having to reinvent the wheel. All the code is modularized and ready to go; I haven't yet shipped the framework in the current version of Synergy Advance because (so far) nothing requires it.
As for the question about prefPanes vs plug-ins, if a plug-in author (bah, let's be honest, I am probably going to be the only plug-in author!) wants a preferences UI then a separate prefPane will need to be created and installed somewhere where Synergy Advance can see it. Once again this means one of the following:
Synergy Advance.app/Contents/Resources/PreferencePanes/ ~/Library/Application Support/Synergy Advance/PreferencePanes/ /Library/Application Support/Synergy Advance/PreferencePanes/
It's not to hard to program in a modular way even with completely separate bundles. The Synergy Advance executable, for instance, doesn't need to know anything about what a preference pane does and the preference pane doesn't need to know anything about what the executable does, yet you can still get a very high degree of integration (as I think you can already witness even in the first few preference panes that I've shipped with the current version of Synergy Advance).
-
John Davidorff Pell
As you obviously know, the whole point of a bundle is that it contains all the code and resources are in one ... bundle. Would it be quite difficult to do something like letting prefpanes be in:
Synergy Advance.app/Contents/Resources/Plug-ins/PreferencePanes/ Synergy Advance.app/Contents/Resources/PreferencePanes/ ~/Library/Application Support/Synergy Advance/PreferencePanes/ /Library/Application Support/Synergy Advance/PreferencePanes/
This way, a plug-in can be self-contained and not need extra pref-panes to be useful. Actually, if this is easy to do then maybe you don't need the PreferencePanes directory at all, just put all the prefPanes inside the bundle that it controls. :-)
JP
P.S. Thanx for being so responsive!
-
John Davidorff Pell
Synergy Advance.app/Contents/Resources/Plug-ins/PreferencePanes/
was suppsed to be
Synergy Advance.app/Contents/Resources/Plug-ins/SomeRandomCoolFeature.bundle/PreferencePanes/
-
Greg Hurrell
(In reply to comment #4)
As you obviously know, the whole point of a bundle is that it contains all the code and resources are
in
one ... bundle.
Evidently, but the only bundle that really matters is the "Synergy Advance.app" bundle, because that's the one that shields the user from all the details inside.
It seems to me that this:
Plug-ins/A.bundle Plug-ins/B.bundle Plug-ins/C.bundle PreferencePanes/X.prefPane PreferencePanes/Y.prefPane PreferencePanes/Z.prefPane
Is more elegant than variations like this:
Plug-ins/A.bundle/Contents/Resources/X.prefPane Plug-ins/B.bundle/Contents/Resources/PreferencePanes/Y.prefPane PreferencePanes/Z.prefPane/Contents/Resources/Plug-ins/C.bundle
The thing to remember is that many plug-ins won't have a preference pane of their own and in many cases there is no one-to-one correspondence between preference panes and plug-ins. For example, you don't want a separate preference pane for the Amazon (US) plug-in and one for the Amazon (UK) plug-in; you want a single preference pane for all of the different cover art sources. That preference pane will be here:
Synergy Advance.app/Contents/Resources/PreferencePanes/
And the cover art plug-ins will be here:
Synergy Advance.app/Contents/Resources/Plug-ins/
This is an example of where there is no one-to-one relationship between plug-ins and preference panes. If a plug-in needs to display custom UI for adjusting its preferences it can embed it in its own nib file (the-plug-in.bundle/Contents/Resources/the-nib-file.nib) and the preference pane responsible for that plug-in (and its siblings if there are any) takes care of showing the UI when appropriate.
All of these details are neatly hidden from the user. Most plug-ins will be bundled inside the Synergy Advance app bundle (even though it is possible for a user to install additional plug-ins into the appropriate place in their Library folder). This is true of preference panes too; I could get Synergy Advance to look for them in the Library folder as well but so far I haven't seen a case where it would be necessary.
If you were a plug-in author and really, really, really wanted to put a PreferencePanes subfolder in your bundle then there's nothing stopping you from doing so, but your app would become responsible for loading and displaying the pane. I really can't imagine why anyone would want to do this. Most plug- ins, by their nature, will do one small job and nothing more and so there's no need for complicated preference UIs, we're talking about at most one view for adjusting the settings.
When I wrote the plug-in handling code I did think about having a system reminiscent of the Mac OS 9 system of having one folder called "Plug-ins" and another called "Plug-ins (disabled)" wherein the user could disable or enable plug-ins by dragging them from one folder into another. Mac OS X still uses this style of management in at least one case that I know of (when you uncheck localizations in the Finder's "Get Info" window for an app).
In the end I decided to forget that idea because it's impractical for plug-ins inside the Synergy Advance app bundle itself (which will be most of them), and it just doesn't work at all if you run Synergy Advance from a read-only volume like a mounted disk image. So instead Synergy Advance maintains a list of which plug-ins are to be loaded and which are to be disabled, you control this using checkboxes in the UI, and no moving of plug-ins between folders takes place. This really is the only way to do it on a multi-user system because it allows each user on the machine to have their personal preferences about which plug-ins are active and which are not.
As far as enabling/disabling preference panes goes there's really no need for it. If you don't want a preference pane to be loaded into memory simply don't ever open it. It won't be loaded into memory and it won't use any resources. You can look at any of the other preference panes if you wish (ie. the preferences window doesn't load them all at once, it only loads each pane when and if you decide to actually open it).
If you disable a particular plug-in then you'll never see its preference settings in the UI. Note that here when I say "disable" I mean "prevent it from being loaded into memory". Some plug-ins may at their discretion provide a checkbox that enables/disables them in another sense; they will still be loaded into memory but they won't actually do anything unless turned on.
-
Greg Hurrell
Changing assignment to reflect my new email address.
https://wincent.dev/a/news/archives/2006/05/change_of_email.php
Add a comment
Comments are now closed for this issue.