zim-wiki team mailing list archive
Mailing list archive
Re: Disabling/Enabling plugins per Notebook
On Wed, Mar 7, 2012 at 2:34 PM, Mariano Draghi <mdraghi@xxxxxxxxx> wrote:
> On Tue, Mar 6, 2012 at 7:00 AM, Jaap Karssenberg
> <jaap.karssenberg@xxxxxxxxx> wrote:
>> On Tue, Mar 6, 2012 at 5:25 AM, Adam Porter <adam@xxxxxxxxxxxxx> wrote:
>>> Does Zim load the plugins when a notebook is opened, or when the
>>> daemon is loaded?
>> They are opened per instance, but they open before the notebook is
>> opened. So may need a little bit of refactoring.
>> Zim first constructs the GtkInterface object, this loads the plugins,
>> than it loads the Notebook object. Probably we can delay loading
>> preferences in the GtkInterface until the notebook is loaded. Or load
>> the default ones, and replace them when the notebook turns out to have
>> a non-default profile.
> I've been looking at the code yesterday, and I think I have identified
> the process you describe.
> So, using your general idea, what I'm planning to do is this:
> * add a class attribute to the plugin base class,
> is_notebook_independent or something, the default would be False.
> automount (and any other plugin that requires it) should overwrite
> this with True
> * load the general preferences, but as far as plugins is concerned,
> load only those marked with is_notebook_independent
> * open/initialize the notebook
> * try to load a specific notebook profile with preferences. If one is
> found, merge (or replace?) the general preferences. If we merge, the
> specific profile should take precedence.
> * load the plugins
> Does this seem reasonable?
Yes, sounds good to me for first implementation. For now I would not
try to merge, just replace and emit the "preferences-changed" signal.
This signal should trigger any updates in the GUI that follow from the
( Only edge case I can think of is that if in the UI with profile
applied we change a notebook independent plugin, it would be nice to
sync back to the default profile. Or in general we should keep
notebook independent settings in sync between profile and default. But
that can wait as a refinement. )
Also UI options for profile can wait. I think we should be able to
switch profile for a running instance by replacing preferences and
emitting the signal as well. So adding a dropdown in the notebook
properties is easy. I'll have a look at that when merging your work.
P.S. as an implementation detail, please consider putting the logic
for loading profile specific preferences in the NotebookInterface
class, in a method called "finalize_notebook()" or something like
that. Logic is not specific to the Gtk interface, but could also apply
to e.g. the WWW interface.