zim-wiki team mailing list archive
Mailing list archive
Re: Disabling/Enabling plugins per Notebook
On Fri, Mar 9, 2012 at 10:10 AM, Jaap Karssenberg
> On Fri, Mar 9, 2012 at 1:38 PM, Mariano Draghi <mdraghi@xxxxxxxxx> wrote:
>> The first has to do with some unit tests. A few tests instantiate a
>> NotebookInterface and/or a GtkInterface without opening a notebook,
>> and then perform some asserts on the default plugins. The problem is:
>> the plugins are no longer loaded if there's no notebook opened (all
>> the default plugins are "non independent", and ignored until a
>> notebook is opened). There are two approaches to fix this:
> I would actually suggest a third: modify the test to load a notebook
> first and then assert the default plugins are loaded. This way you
> test the real code that users will see as well. You can use
> "tests.new_notebook()" to get a notebook in the test.
... your approach sounds nicer, cleaner, and even more easy to
implement. It even sounds obvious! (why didn't I think of that?)
Anyway, I'm sold! ;-)
> Btw. are you looking at tests/plugins.py ? This test already loads a
> notebook when testing default plugins are loaded.
Yes, I even added a (very) small test there for the
>> The second issue has to do with how the preferences are persisted. I
>> think that the "preferences-changed" signal that I'm emitting after
>> loading a notebook profile ends up saving the preferences.conf with
>> the refreshed configuration.
> Would need to see the actual code to know exactly what is going on,
> but sounds like you read preferences from the profile, but you keep
> the preferences pointing to the default preferences file. This is why
> the default file is written and other instances than read it.
Yes, exactly :)
I'm just updating the preferences dict in NotebookInstance.
> Same could happen when a user modifies a preference. To make sure
> changes go to the profile file, the link to the default file needs to
> be replaced by a link to the profile file.
> The "preferences" dict is actually an object of the class
> "ConfigDictFile", which inherits from "ConfigFile" so it knows it's
> source file and when "write()" is called saves back there.
> You can not just replace this object, because that would break sub
> structures referenced by other objects. Instead we may need to add a
> method to ConfigFile to change the file. E.g. a method
> "change_file(newfile)". After that a write should go to the new file.
> Hope this helps,
Yes, it helps a lot!
OK, I'll take that route. All I have to do is to implement the
change_file() method in ConfigFile and call it before emitting the
BTW, I'm using the notebook.zim file as the "profile", so apart from
the Notebook section, it might contain the General, GtkInterface and
PageView (plus any *Plugin) sections. Do you agree with this, or would
you prefer a separate file for the profile? (like a "preferences.conf"
in the notebook folder). I went for the notebook.zim route just to
avoid adding another file, but I can change it if you like. If I keep
the notebook.zim file, I just have to add the "Notebook" section to
the preferences ConfigDictFile too before changing the file, so it
doesn't get lost when saving it.