Tuesday, May 5, 2015

I realized that sendchanges won’t help for #178 because the list of subscribers is dynamic. Which indicates that sendchanges was maybe a fundamentally wrong approach.

I changed the on_ui_updated signal: sender is again the database model (i.e. the class object), and the ChangeWatcher is passed as a named argument watcher.

Instead of activating sendchanges, I simply defined (in lino_welfare.modlib.notes.models) a receiver which reports every change on a note to all colleagues.

Note: how to document an upgrade on a production site? pip freeze reports the exact versions which were active before:

-e git+https://gitlab.com/lino-framework/lino.git@fc7d116a02f1752dd09eb91031a2d4e79c146cbf#egg=lino-master
-e git+https://gitlab.com/lino-framework/lino-welfare.git@9969d2bd31bcb9691d713574178785c565376c72#egg=lino_welfare-master

• How can I restore the environment to the state before my git pull?

• How can I store this information in some automated way into lino_noi?

One disadvantage of napoleon is that Emacs (or at least my Emacs) doesn’t know about it.

I started to tidy up in preparation for #181.

After consultation with Gerd, I moved the receiver on notes.Note from lino_welfare.modlib.notes.models to lino_welfare.chatelet.lib.pcsw.models because in Eupen they don’t want this feature. Theoretically I should have created a new module lino_welfare.chatelet.lib.notes (which would inherit from lino_welfare.modlib.notes (which itself inherits from lino.modlib.notes)), but creating a plugin just to add a signal receiver seems overkill. For Django & Lino, a receiver on a model may be defined in another plugin.