zim-wiki team mailing list archive

[Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx>]

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.

Btw. are you looking at tests/plugins.py ?  This test already loads a
notebook when testing default plugins are loaded.

> 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. This produces an unexpected behavior:
> Any notebook that doesn't have a specific profile ends up using the
> generated configuration for the last opened notebook. Ugly :(
>
> I haven't debugged this much yet, but I'm a little bit lost. I suppose
> I should flag somewhere that the preferences were changed by a profile
> override, lets say, and that they must not be saved. But I'd like to
> have some feedback from someone more familiar with the code... would
> this be a good approach? If so, could anyone help me with the general
> idea as to how implement it?

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.

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,

Jaap