Integrating Calendar into Thunderbird
paul at thunderbird.net
Tue Jan 7 22:15:33 UTC 2020
As you may know we have started working toward the integration of
Lightning/Calendar into Thunderbird. See this meta bug:
Philipp, Magnus, Alessandro, and I have thoroughly discussed two
possible options (system add-on and direct integration) while
considering input from Geoff and others. We have now decided on the
direct integration option, with some guidelines for the handling of
Calendar code. This email is to announce the decision and share those
guidelines, which are below.
The primary goal of these guidelines is to maintain the modularity of
the Calendar code. The guidelines should be clear (feel free to skip
ahead and read them), but a concrete example may help to illustrate
things. Take menu integration, for example. For a single Calendar menu
item in a Thunderbird menu, it would make sense to just inline it in the
Thunderbird UI file, using code comments and/or naming conventions to
communicate that it is a calendar integration point. For an entire menu
or perhaps a menu item with many sub-menus, it would make sense for that
UI code to be in a file in the calendar directory. It could then be
included in the Thunderbird UI code by using a preprocessor directive in
the Thunderbird UI code. Basically, smaller parts could be directly
in-lined, and larger parts would stay in the calendar directory and be
included by preprocessing.
Any questions about any of this are welcome.
Guidelines for Calendar Integration in Thunderbird
We will be transitioning Lightning/Calendar away from being an add-on so
that it is, from the user’s perspective, just a part of Thunderbird.
Going forward, we will adopt these guidelines in order to maintain, at
the level of code and from the programmer’s perspective, the modularity
of Calendar as a separate component within Thunderbird. The goal is to
keep open the possibility of re-use of the calendar component/code, with
minimal effort, in other ways or contexts in the future (e.g. a separate
Calendar application), by not letting it become too coupled with
To that end we will seek to maintain (e.g. in code reviews) a separation
of concerns between Calendar’s (1) UI integration code, (2) core UI
code, and (3) “business logic” code.
1. UI Integration code should live in the calendar/ directory, but may
be placed in other directories if necessary. Acceptable use cases include:
- Use of preprocessor defines to reference files in the calendar/ directory
- Single UI elements, properly identified as calendar items. For example
using naming conventions (calendar-foobar-menuitem)
2. Core UI code must live in the calendar directory.
3. Business logic must live in the calendar directory as well.
Review of calendar code continues to require a peer of the calendar
module. This includes larger chunks of calendar code outside of the
calendar/ directory. To the contrary, use of preprocessor includes as
well as similar use cases mentioned above don't require a calendar review.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning