OpenLyrics Integration and Lyrics edit dialog

[GoogleCodeExporter]

OpenLyrics is an open data format for lyrics. It will be used in
Changingsong and OpenLP.org 2.0.

Here are more information about Openlyrics: http://openlyrics.info
Example songs: http://openlyrics.info/dataformat.html#advanced-example 

Implement this in Exposong so that you can use your songs in many programs
without the need to convert all your songs.

Original issue reported on code.google.com by s.mehrbrodt on 2 Mar 2010 at 1:19

• Blocking: #57, #82, #94

[GoogleCodeExporter]

I'm not able to set an owner or a milestone or something else, so you could do 
this,
Brad.

Original comment by s.mehrbrodt on 2 Mar 2010 at 1:19

[GoogleCodeExporter]

Original comment by s.mehrbrodt on 8 Mar 2010 at 2:19

• Added labels: Priority-Medium, Milestone-Release0.7, Component-Persistence, Type-Other

[GoogleCodeExporter]

I've got this partially done. Verse Order is not done this instant, but I may 
work on 
it today more.

Here's a few things to do:

<lines>
-------

Right now, this tag is ignored. I don't know what the best option for this is 
exactly. We could:
 a) Assume that the Nth line in a lines entity correlates to the same line in every 
other lines entity. A good example song "Prince of Peace", where one line the 
men 
sing, the women sing a different line. Inputting would let the user specify 
parts, 
and then they would be color coded in an alternating fashion.
 b) Somehow, let the user format it. I don't really want to do this, as it adds more 
complexity, and it's not easy to do. OpenLyrics does not support an entity 
covering 
this, so it's probably out of the question.

Translations
------------

The translation author should show depending on the current language.

I need to filter based on translation. If de is the current language code, it 
should 
select all verses with German, or if it finds, none, then somehow pick a 
default.

Various Properties
------------------
ccliNo, releaseDate, transposition, tempo, key, variant, publisher, 
customVersion, 
keywords, songbooks, themes, comments, comment (in verse)

Original comment by bradleelandis on 27 Mar 2010 at 9:19

[GoogleCodeExporter]

I added by support for a single author for words and music. I plan on changing 
to a 
list format eventually, so that there can be any number of authors.

Original comment by bradleelandis on 27 Mar 2010 at 10:15

[GoogleCodeExporter]

I'll try to get on this on Saturday. I've been in and out of town and slightly 
unmotivated, but I'd really like to get this done so I can worry about other 
things.

Original comment by bradleelandis on 12 May 2010 at 8:32

• Added labels: Priority-Critical, Type-Task
• Removed labels: Priority-Medium, Type-Other

[GoogleCodeExporter]

One thing where you could also look after is that the authors are only 
displayed on the presentation if they 
exist. This was so in the previous version, but somewhere it must have been 
broken.

Original comment by s.mehrbrodt on 21 May 2010 at 5:08

[GoogleCodeExporter]

Until the OpenSong library gets a permanent version out, in order to use the 
svn trunk, 
you will need to download 
http://openlyrics.googlecode.com/hg/lib/python/openlyrics.py 
and put it in share/exposong/lib/. I'd really prefer to mirror the file, and 
have our 
SVN go and pull that file, but while it might have been possible if both were 
using the 
same VCS, I doubt that svn and hg can work together.

I am slowly but surely getting this implemented. Hopefully today I will be able 
to 
commit something that is working.

Original comment by bradleelandis on 22 May 2010 at 7:46

• Changed state: Started

[GoogleCodeExporter]

I've noticed the interface changes in r369 and I think that entering basic
information should be more simplified.
Here's a mockup how the first two tabs could look.

I think it's good to have the order entry on the same page as the slides so 
that you
can see how the slides are named.

What do you think about it?

Original comment by s.mehrbrodt on 26 May 2010 at 9:29

Attachments:

• editlyrics.png

[GoogleCodeExporter]

The interface is the hardest part of this integration process. Unfortunately, 
it's a 
complicated data structure for people to understand, and has a lot of features 
which 
cause complication.

The tabbed interface was just an idea, but when I tried to put it all on one 
page, it 
came to be longer than the height of my screen.

Slide order with verse sounds good. Eventually we can create drag and drop, but 
not 
this release.

Author looks fine that way, but do are you thinking something similar for 
songbook/title/etc? The thing that I like about the way it is now is that it's 
less 
error prone, as GTK handles most of the work. I can add a help label to explain 
what 
to do.

For comments, we can just do a multiline text entry.

If you want to come up with tab names and fields that should be under those 
tabs, it 
would help me quite a bit. And I guess we could just put multiple tabs on the 
main 
Notebook, instead of creating a secondary Notebook, as long as there are fewer 
than 6 
or 7 tabs.

Original comment by bradleelandis on 26 May 2010 at 10:00

[GoogleCodeExporter]

I'm not aware what you want to do with multilingual songs. Do you want support 
for
them in 0.7 yet (You have already done something for multilingual titles).

I would say that we support only one language per song in this release and 
focus on
multilingual songs in one of the next releases.

Original comment by s.mehrbrodt on 27 May 2010 at 9:28

[GoogleCodeExporter]

For now, I was going to try to find a way to pull the current language, and 
make a 
guess at which verses should be used. For example, if the language is "en_US", 
search 
for "en_US", then "en", then "". I have not found out how to get it, so if you 
figure 
it out, let me know.

That's what my plan is for this release. Maybe down the road, we can split 
language 
like we do <lines>, which right now just prepends the lines.name. I want to 
have set 
colors for each part eventually, which for now might be a setting for the user, 
and 
eventually it will be part of the theme.

Original comment by bradleelandis on 27 May 2010 at 9:45

[GoogleCodeExporter]

There are two kinds of translations:
First, we have an English song and just for people to understand we have a 
German
translation.
Second, we can have an English song, but we have also the same song in German 
and you
can sing both of them. So in this case only the German text should be shown on 
the
screen.

I'm not sure how OpenLyrics handles it, but I think for the second case you 
have to
create a new song and translation covers only the first case.

Original comment by s.mehrbrodt on 27 May 2010 at 9:59

[GoogleCodeExporter]

I think for the most part, we want to have a translation of a song to be stored 
with 
the same song. If it's the same music, and the same meaning, then they should 
be stored 
together.

Original comment by bradleelandis on 27 May 2010 at 11:04

[GoogleCodeExporter]

I've created another mockup with all the fields you had in your draft.
It may be a bit more work than just using a gtk.TreeView, but I find it much 
more
usable this way.
Instead of the "Delete row" button we could put a delete button on the right of 
any
active cell.

Original comment by s.mehrbrodt on 27 May 2010 at 11:06

Attachments:

• editlyricsv2.png

[GoogleCodeExporter]

OK, looks good. I think I will put Songbook, Tempo, and Transposition into 
another tab 
("Music" or something). It should have plenty of room for the tabs.

Original comment by bradleelandis on 27 May 2010 at 11:13

[GoogleCodeExporter]

Well, the problem I'm seeing now is that editing something like the authors is 
difficult to facilitate. Either we need a dialog for add/edit, or we just need 
to let 
the table handle everything.

I will try to do it with a table, and do it well, and you can see what you 
think.

Original comment by bradleelandis on 27 May 2010 at 11:45

[GoogleCodeExporter]

I thought that in my draft you can edit it in the table as it is in yours.
I think it's important to provide an easy way to add the authors the first time,
because that's something you have to do with every song.

But if you want to, you can first do it only with a table and then we'll see if 
it's
good or not.

Original comment by s.mehrbrodt on 1 Jun 2010 at 9:59

[GoogleCodeExporter]

The interface is about 90% complete now. Verses still need to be completed, and 
tempo needs to be moved to one line, but I was trying to get the code to be 
shorter. Take a look and see if the organization makes sense to you.

Original comment by bradleelandis on 9 Jun 2010 at 1:34

[GoogleCodeExporter]

Take a look at this @s.mehrbrodt. This is a working example that shows a label 
beside the lines in a TextView.

Original comment by bradleelandis on 10 Jul 2010 at 7:25

Attachments:

• linenums.py
• line-labels.PNG

[GoogleCodeExporter]

Good, that's how I imagined it.
Just needs some polishing.
Maybe wen can add the ability to choose a color for each part in a later 
release.

Original comment by s.mehrbrodt on 10 Jul 2010 at 8:58

[GoogleCodeExporter]

Hey, I had started some changes without committing, and I tried to incorporate 
as many changes of yours as possible, but some of the work on lyrics.SlideEdit 
could not be converted over. I've added a PartsList widget, and I will also be 
working on the text buffer in order to create the verse names. Hopefully I will 
get it committed tonight.

It would be nice to have lyrics.SlideEdit inherit from text.SlideEdit, but it's 
not a show stopper for 0.7.

Original comment by bradleelandis on 24 Jul 2010 at 3:42

[GoogleCodeExporter]

At my request, openlyrics will be getting rid of the <lines> elements. This 
will make it to where each line can have any part name. It's no longer 
alternating. I'm not sure what GTK element to use... Maybe a treeview with a 
column with Part Name, and another with a Line. This may add some delay.

Maybe we should have put this off until OpenLyrics was a little more finalized 
:).

Original comment by bradleelandis on 31 Jul 2010 at 3:32

[GoogleCodeExporter]

Do you think Parts are so important that they have to be in 0.7 release. For me 
it would be ok if we released ExpoSong 0.7 after fixing the rest of bugs and 
reorganizing the lyrics edit UI a bit as discussed in 
http://groups.google.com/group/exposong/browse_thread/thread/fae88746dd682d34 .

Original comment by s.mehrbrodt on 31 Jul 2010 at 6:56

[GoogleCodeExporter]

Actually, I like that idea. I'm ready to get a release, and parts are a real 
pain, so let's just focus on getting it working without parts.

I'll try to revert back to the changes you had done, so that it uses 
text.SlideEdit as it's super class.

Original comment by bradleelandis on 31 Jul 2010 at 4:20

[GoogleCodeExporter]

Maybe you can create a branch in SVN where you put the parts code and, in 
future, other incomplete code. then when it's ready we can merge it with trunk 
(don't know actually how good svn is in that)

Original comment by s.mehrbrodt on 31 Jul 2010 at 9:19

• Changed title: OpenLyrics Integration and Lyrics edit dialog

[GoogleCodeExporter]

Haven't seen any issues so far. We'll improve the interface for the next 
release. Open new releases for bugs or feature requests.

Original comment by bradleelandis on 12 Aug 2010 at 3:33

• Changed state: Fixed