====================================
20130913 (Friday, 13 September 2013)
====================================

Printing mail labels for all partners of a list
-----------------------------------------------

The missing piece of yesterday's the jigsaw puzzle 
(:blogref:`20130912`)
was this:
`Repetition or conditional inclusion of table cells
<http://appyframework.org/podWritingTemplates.html>`__.

Voilà, any Lino application which uses 
:mod:`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 
:srcref:`/lino/config/Labels.odt` to your local :xfile:`config`
directory and adapt it to your needs.

Moved the 
:class:`Addressable <lino.mixins.addressable.Addressable>`
mixin from :mod:`lino.modlib.contacts`
to a new module :mod:`lino.mixins.addressable`.
Added a
:meth:`get_address_html <lino.mixins.addressable.Addressable.get_address_html>`
method and an 
:attr:`address_html <lino.mixins.addressable.Addressable.address_html>`.
property to
Updated docstring of :mod:`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)



More about :ref:`davlink` 
-------------------------

Gerd and Nicolas reported that 
:ref:`davlink` failed in certain environments.

- Added a ``<param name="separate_jvm" value="true">``
  to the ``<applet>`` tags generated by :mod:`lino.extjs.ext_renderer`.
  This is to work around some problem in certain Java versions.
  
In a post `Java 7 update 21 mixed code warning dialog with signed applet
<http://www.chrisnewland.com/solved-java-7-update-21-mixed-code-warning-dialog-with-signed-applet-339>`__
about "New security feature in 7u21 causes warnings on Java<-->JavaScript communication" I read
that "Starting with Java 7u21 calling between all-permission Java applets
and JavaScript is classed as mixed code and requires the signed jar 
to have the following manifest entry:
`Trusted-Library: true
<http://docs.oracle.com/javase/6/docs/technotes/guides/jweb/mixed_code.html#trusted_library>`__.

According to the docs this attribute should be used
"for applications and applets that are designed to allow unsigned 
components".

- What is an "all-permission Java applet"? 
  Maybe the root of the problems is that my applet asks too much? 
  Maybe I should not set the PermissionManager myself because that is 
  like telling users that they must instruct their browser to give me
  full access to their computer. In fact I need less than that, 
  just permission to run a program from their machine (and permission 
  to store some preferences).

- What is a Manifest file? Why did I not need one until now?
  Answer: 
  http://docs.oracle.com/javase/6/docs/technotes/guides/jweb/mixed_code.html#manifest
  describes "best practices for developers and deployers to protect their 
  applications and applets from being maliciously re-purposed by 
  replacing trusted components with untrusted ones."
  


(Checkin and upgrade :ref:`demos` to newes development version.)



test_sdist
----------

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.