[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Denemo-devel] [bug #29571] TimeSignature change in middle of measure im
From: |
Richard Shann |
Subject: |
[Denemo-devel] [bug #29571] TimeSignature change in middle of measure impossible to delete after paste |
Date: |
Sat, 17 Apr 2010 17:03:35 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en; rv:1.9.0.16) Gecko/20080528 Epiphany/2.22 |
Update of bug #29571 (project denemo):
Status: None => Fixed
_______________________________________________________
Follow-up Comment #1:
This is an important issue: the scripting idea was based around an
imaginary user operating the commands in the denemo menu system. This
meant we could create a complete system with little work, just wiring
every command to a d-XXX scheme procedure.
However, it has lead to us fighting features which the original author
put into commands never thinking that they would be used like this. The
one we have hit most often is the cursor move when the cursor is on the
last object in a measure. A new state is entered, the cursor does not go
to the first object in the next measure (if there is such a measure and
if there is any object in it).
The example Dan has raised here is going to involve some disruption to
fix, as there is no-one available to study the code in depth and fully
design a solution.
I propose instead to make some changes and then await reports on any
problems. I will do some testing, before pushing to git, but it will be
unwise to trust git in the way you normally do while we are trying to
resolve this.
OK, that said, I think the first ploy might be to turn off all special
handling of timesignature changes by denemo. "Special Handling" means
all built-in behavior of the cursor around timesig-change objects and
the delete and the insert of timesig-change objects. The danger is that
in the calculations that Denemo makes to decide whether a measure is
full there could be inconsistencies arising and, say, floating point
exceptions. So, e.g. on inserting a timesig change, some "prevailing
timesig" is calculated, and how this will behave if the timesig is not
at the start of a measure, will need some attention.
I think there is a maybe 80% chance that this will be just fine. It
would be easy to put a dialog up to warn users if they are inserting a
timesig change not at the beginning of a measure; the dialog only firing
for non-scripted use.
I have checked in code now; I decided there was no need to change the
behavior of the timesig change dialog - it will always insert at the start of
a measure. But the deletion bug is now fixed.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?29571>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/