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. -- Mariano _______________________________________________ Mailing list: https://launchpad.net/~zim-wiki Post to : email@example.com Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp