denemo-devel
[Top][All Lists]
Advanced

[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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]