Since Nicolas' recent change to treat Harmony elements as SimpleText rather
than unstyled text, which in principle may be a good idea, I have noticed
some issues which need to be addressed. I have discovered some reasons but
not yet the correct fix.
1. If a Harmony element was already in a score that is loaded, the first
attempt to edit it causes it to be emptied.
2. If a Harmony element was entered into the current document, editing
it again causes the edit box to be populated with the original text input
from the last time it was edited, rather than with the canonical form of
the chord.
These two behaviours are related, due to the following reasons:
a) When entering edit mode, we get the following sequence:
ScoreView::startEdit()
Harmony::startEdit()
Text::startEdit()
SimpleText::startEdit()
In Harmony::startEdit(), the canonical text for the chord is fetched by
calling harmonyName() and placed in SimpleText::_text using setText().
In SimpleText::startEdit(), it tests whether _layout is empty, and if so,
it calls layout(). (As a side issue, this is virtual - shouldn't it call
SimpleText::layout() at this point?).
The call to layout() is intended to populate _layout from _text, but
within SimpleText::layout(), this population is ONLY done when NOT in
edit mode. Since at this point we ARE already in edit mode, the editing
operation starts with _layout containing a single empty line. This is
the reason for issue 1 above.
b) When entering edit mode for a second time on the same Harmony element,
the contents of SimpleText::_layout is unchanged from the previous call,
and so layout() is not called anyway in SimpleText::startEdit(). This
means again that the canonical value put into SimpleText::_text is not
used, and editing just continues with the values left in _layout on the
previous edit of that element.
3. A third issue is that the red squiggle for spelling check of chord
names no longer works, because Harmony::edit() is fetching and testing
the value of text() (from _text), but this is the unchanged initial
value, and has not been updated with the edits in _layout.
I'm not sure of the best way to fix these. It's almost as if Harmony
needs to be based on an EvenSimplerText class that doesn't need to handle
multiple lines, and operates directly on _text, since it is only in edit
mode that this base class layout is used. When not in edit mode,
Harmony does its own layout.
The above problems could be overcome by reverting to unstyled text,
re-adding a call to setUnstyled() in the Harmony constructor after
initialising the style, but in that case we are back to the incorrect
positioning of the edit-mode text box, since unstyled text layout
doesn't handle BaseLine alignment.
Comments?
Cheers
Tony
--
Tony Mountifield
Work: t...@softins.co.uk - http://www.softins.co.uk
Play: t...@mountifield.org - http://tony.mountifield.org
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer
