20130913 (Friday, 13 September 2013)

Printing mail labels for all partners of a list

The missing piece of yesterday’s the jigsaw puzzle (2013-09-12) was this: Repetition or conditional inclusion of table cells.

Voilà, any Lino application which uses lino.modlib.contacts has now an additional button “Labels” in the top toolbar of every table on Partner, Person, Company (and every subclass of them), and this button will immediately produce a pdf with address labels.

Site-wide formatting of these labels can be configured by copying /lino/config/Labels.odt to your local config directory and adapt it to your needs.

Moved the Addressable mixin from lino.modlib.contacts to a new module lino.mixins.addressable. Added a get_address_html method and an address_html. property to Updated docstring of lino.dd

New feature: menu buttons

Until now it was not possible to define actions which are grouped into a single “menu button”.

Lino.build_buttons : Cannot any longer write

buttons[i] = new Ext.Toolbar.Button(actions[i]);

the button object is no longer passed as second argument to the panel_btn_handler.

(TODO: rename panel_btn_handler to panel_handler)

The visible result is that the “PDF” button is now usually a menu button with at least two items “Table (portrait)” and “Table (landscape)”. And for Addressables a third item “Labels”. Cool!

(TODO: make this locally configurable)

Replaced Action.called_from by Action.is_callable_from

I noticed that Lino displayed tha button for the pdf action (wrongly) also in a detail form. This incited me to tiny up with that strange system using a static callable_from tuple. (TODO: document it)


The idea behind the fab test_sdist command is to run the following steps before actually releasing to PyPI:

  • run setup.py sdist –dist-dir /home/luc/sdist

  • create a virgin virtualenv and activate it

  • run pip install –extra-index file:/home/luc/sdist mypackage

  • At this point we must be aware of the fact that neither the setup.py nor the tests directory is part of a source distribution. The tests suite often uses a many resources that are not included in a source distribution. So we cannot simply run setup.py test now.

One idea is a new convention: add a module mypackage.selftest which I can invoke using:

$ python -m mypackage.selftest

This would then test everything testable from within a source distribution. Just an idea for the moment. To be tried.