On Fri, Mar 9, 2012 at 10:10 AM, Jaap Karssenberg
<jaap.karssenb...@gmail.com> wrote:
> On Fri, Mar 9, 2012 at 1:38 PM, Mariano Draghi <mdra...@gmail.com> 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
is_notebook_independent attribute.

>> 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
"preferences-changed" signal.

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.


Mailing list: https://launchpad.net/~zim-wiki
Post to     : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp

Reply via email to