zim-wiki team mailing list archive

[Mariano Draghi <mdraghi@xxxxxxxxx>]

On Wed, Mar 7, 2012 at 11:31 AM, Jaap Karssenberg
<jaap.karssenberg@xxxxxxxxx> wrote:
> 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
> new preferences.
>

I'm closer to publish a branch with all these changes for review,
probably during the weekend or next week. But apart from a little more
testing and some unit tests that I'd like to add, there are two
standing issues:

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:
 1) Refactor a little bit more the logic in
NotebookInterface/GtkInterface to detect this situation, and load the
plugins before hand if there's no notebook involved.
 2) Implement some helper hack for the unit-tests (something like
marking all the default plugins as notebook independent --at runtime,
not in their source code--, for example). The tests that want to play
with things like for example asserting if the default plugins were
loaded can be refactored to use this helper. AFAIK there are only two
tests that would need this.

The 1st approach might be more "purist" and clean, but maybe it will
also add some unnecessary logic. In real life, there's no much point
in using Zim without opening a Notebook ;-) That's why I was also
thinking in a more "hackish" approach specific to the unit-tests.

What do you think? Which path should I take to fix the issue?

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?

Thank you!

-- 
Mariano