Merge lp://qastaging/~sam92/openlp/bug-1695620 into lp://qastaging/openlp

You need to run CI on this to show the success of tests.
Not sure why but this request did a full download when I did a check out. Also cannot run due to chord issues.
Cannot run this but there seem to be lots of line breaks in the footer display. As the footer area is small this will not be displayed and lead to forum comments.
You need some validation do defend against too long footers!

We're moving away from Python generated HTML, and using a JS system based on Reveal.js. Come chat with tgc and myself in IRC.

> Cannot run this but there seem to be lots of line breaks in the footer display. As the footer area is small this will not be displayed and lead to forum comments.

The footer has the same height as before, there should be no difference by default.

So I replaced Pystache with Mako. Should be safe to merge now I think.
As the new renderer is in a very early state atm, I can't see how I can adopt this for the new renderer. Maybe we can merge this now and adopt when the new renderer is ready?

Blank lines!
Will review tomorrow as I have bible study!

So is there a chance this can be reviewed now?

> Blank lines!
What do you mean with that?

Linux tests passed!

Linting passed!

macOS tests passed!

Linux tests passed!

Linting passed!

macOS tests passed!

Looks good to me!

Template should be in its own file so can be tested and not duplicated.
Not happy with the if conditions being removed these have been added as we sometimes get broken databases in the wild and this needs to be guarded against.

@Tim: As discussed on IRC, could you please review again?
I had to remove the conditions so that the variables are always available to the template, even if they are empty. They were there to make sure that no empty lines were added to the footer. But now this checking is done in the template.

Also wrt the template in its own file, after discussion we came to agreement that it's not worth the hassle (packaging etc). So we keep it just as a config string.

So, I like the principle, but I really don't think that using Mako is necessary. Do you think it's plausible to just use string formatting or string templating?

> Do you think it's plausible to just use string formatting or string templating?

Hm while that would allow adding a bit of markup around the strings, you can't add any control structures.

With mako you can do much more, e.g. concatenate multiple authors into one line (as we do using join), display them each on it own line.

The use case I'm especially interested in: Pick just one songbook to be displayed. Using Mako I can just write Python code to only show the songbook we are actually using in the service.

I'm sure there are more valid use cases for this.

You can do the same things in Python. The thing is, we no longer use Mako anywhere else. It's such a small usage, I'd really like it if we could remove the dependency.

I know we're trying to make a customisable footer, but is there any way we can do it without Mako and without introducing another dependency?

Look, if there's no other way around it, then I'll approve this, I'm just trying to reduce/minimize dependencies where possible.

I'm getting conflicts when merging with trunk, can you just re-merge trunk and fix the conflicts please?