Continued on docs/tickets/52. The CalendarStore not only needed a idProperty but also an idIndex config option. I didn’t understand 100% why, but now it works perfectly.
The color of a
lino_xl.lib.cal.Calendar no longer
is a virtual field but a simple models.IntegerField. There’s currently
not even a ComboBox (because Lino doesn’t yet know how to implement Comboboxes for Integers),
users must know that this field is meant to contain a value between 1 and 32.
One important thing is missing before we can say that CalendarPanel is integrated: creating and updating events doesn’t work because my handlers currently don’t forward it to Lino.
There is also an almost philosphical question: where should the label “Calendar”
(and it’s translations) be defined? Currently it is in
lino.reports.Calendar. The whole pot-pourri of actors and actions
(Report, Frame, Detail, Action) might get an internal revision soon:
is it necessary to instantiate Actors? Should the instantiation of an actor represent a request?
Split “Report” into “List” and “Detail”: both of them get their own store. Note that one Detail would contain the equivalent of all .dtl files. Replace .dtl files (one per tab) by a single configuration file. The possibility of local configuration should remain, but convert them to Python code.
Actions should be rather like fields: instantiated within the subclass definition.