20131206 (Friday, 06 December 2013)

The public demos for Lino Polly and Lino Logos were broken due to a server configuration problem. And I didn’t notice it because they were not listed in Public demo sites.

The conversion of existing renderers to plugins will be an occasion to tidy up some historic ambiguities.

  • The Kernel. The object stored in settings.SITE.ui : is (like SITE itself) a “de facto singleton”. But it remains an independent class/object instance (and is not merged into the Site) because it gets created and imported only when the modules are populated. Might rename it to kernel.

    Until now the activities and methods of the kernel were scattered across ui.base, ui.ui and core.kernel. Now they are all in lino.core.kernel.

This was easy and has no impact on user code. All tests pass. Commit. It helped me to understand the following:

  • My first idea was to convert the three “renderers” (TextRenderer, PlainRenderer and ExtRenderer) to plugins:

    SITE.ui.plain_renderer -> SITE.plugins.plain_ui
SITE.ui.ext_renderer -> SITE.plugins.extjs_ui
SITE.ui.text_renderer -> SITE.plugins.text_ui

  • But they cannot become subclasses of ad.App because they get instantiated only during Kernel startup (i.e. when the Django models are already populated).

  • I’d call them “runtime extensions” or “kernel plugins”, or “features”.

  • Note that “renderer” is the wrong name. These three things are what I would call “user interfaces”. A user interface being “a system of methods and ways to interact with the user”. But before renaming them I should rename all current occurences of “ui” to “kernel”.

  • Not yet sure what to do with SITE.default_renderer

As a result, I’ll leave these ideas open for the moment and first convert the use_extensible setting into a plugin.