[openlp-dev] (no subject)

Tomas Groth second at tgc.dk
Wed Jul 17 12:46:23 EDT 2019

Hi Phill,

See reply below inline.

Den søn. 14. jul. 2019 kl. 22.28 skrev Philip Ridout <phill.ridout at gmail.com

> About a month ago I came up against an issue to do with the way we handle
> chords. The issue was that a user who I was importing songs for used
> "[x/y]" to denote the current verse / total verses and the fact that we use
> the chord pro format (which also uses square brackets), meaning that you
> cannot use square brackets and chords in the same song.

Actually, this should only be an issue if chords are enabled in the
song-settings (if this is not the case then it is a bug). If chords are
disabled, square brackets are ignored in regards to chords.

> I've been thinking about this, instead of the chord pro format, I think we
> should use the method supported by OpenLyrics, that is a chords xml tag.
> This should free up square brackets to be used however they feel fit. Which
> begs the question how should the user  enter tags in the song editor. I
> think I have come up with a solution. We use web view and contenteditable.
> I have created some rather rough sample code (
> htps://jsfiddle.net/c8k31sp4/ <https://jsfiddle.net/c8k31sp4/>).

Since I added the chord pro format I'm totally biased, but I think we
should keep the chord pro notation... At least for now (as in not before
3.0 is released). As mentioned above square brackets are only reserved when
chords are enabled.
I do agree that we should change the internal storage format to actually
use the OpenLyrics XML format in the Songs DB, but then convert to chord
pro on load. That would also make it easier for us to migrate to a
different solution like a WYSIWYG editor as you mention.

> Maybe we can use web view for spell checking and perhaps some other
> WYSIWYG functionality in the future?

Actually, I've done a bit of "research" in this field. Have a look at this:
Feel free to include chord functionality :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openlp.io/pipermail/openlp-dev/attachments/20190717/cb0099ac/attachment.html>

More information about the openlp-dev mailing list