Discussion:
[Audacity-devel] Release Manager is calling HALT on the clip move project
Paul Licameli
2017-05-16 22:52:12 UTC
Permalink
Pending further study, I call a halt on David's clip move project, and I
may decide to revert commit b91160795dedce54745102027f8bb0908828772a and
request different solutions be found.

I will state my reasons very soon.

PRL
Paul Licameli
2017-05-16 23:38:13 UTC
Permalink
Two reasons, the first "selfish" and another less so:

1) Selfishly, I do not wish to delay the track panel refactor for another
release. Yes, this is a pet project of Paul without the RM hat on, but I
know I have the strong endorsement of James at least for it.

The efforts of James for theming, Pokechu22 for MIDI playback, and David
for clip move, all make some degree of difficulty in my continuing efforts
to rebase the branch track-panel-refactor onto latest master. I have
already faced a number of such in rebasing that from 2.1.2 onto 2.1.3. I
want to surmount those difficulties, and complete this nearly two-year-old
effort in this release, and then forget about it.

I did green-light David's request to change TrackPanel.* while my attention
was elsewhere. However, I am now finding more than usual difficulties in
rebasing my track-panel-refactor branch onto the latest master, because
this project is introducing new state member variables into class
TrackPanel, but I am trying to eliminate such variables. I can't say the
same for the other two projects.

2) Less "selfishly:" the commit named above causes key down and auto-repeat
to do something analogous to click and drag, and key up to do something
analogous to release, which then (and only then) causes an undo item to be
pushed on the stack. But this is unprecedented. All other existing
keystroke commands using /wantkeyup did not have such implications for Undo.

Bind the new command to some key (I tried Shift + .), press that key, then
hit R, (or C) then release the keys. Regarding the pushing of Undo items
on the stack, what SHOULD happen, and when? What really DOES happen? A
bit of debugging makes me doubt whether this is all handled in a good
crash-proof way, though I haven't yet demonstrated a crash.

In previous release I had to introduce the function
TrackPanel::HandleInterruptedDrag to do something in case the R key (or
worse, Shift + C) is pushed during a mouse click-drag-release and avoid
crashes. I don't know that the necessarily analogous thing is done here
yet.

It might entail difficult work in our dispatching of key events. Or it may
be that I want to complete an undo transaction, with consolidation, at each
auto repeat -- not wait for the key up -- to evade the problems.


David, I want to unblock your efforts as soon as I can. We can talk
further about this. Whatever you do, don't use the word "sorry" in emails
to me! The apologies are all mine.

PRL
Post by Paul Licameli
Pending further study, I call a halt on David's clip move project, and I
may decide to revert commit b91160795dedce54745102027f8bb0908828772a and
request different solutions be found.
I will state my reasons very soon.
PRL
David Bailes
2017-05-17 12:53:22 UTC
Permalink
Post by Paul Licameli
1) Selfishly, I do not wish to delay the track panel refactor for another
release. Yes, this is a pet project of Paul without the RM hat on, but I
know I have the strong endorsement of James at least for it.
The efforts of James for theming, Pokechu22 for MIDI playback, and David
for clip move, all make some degree of difficulty in my continuing efforts
to rebase the branch track-panel-refactor onto latest master. I have
already faced a number of such in rebasing that from 2.1.2 onto 2.1.3. I
want to surmount those difficulties, and complete this nearly two-year-old
effort in this release, and then forget about it.
I did green-light David's request to change TrackPanel.* while my
attention was elsewhere. However, I am now finding more than usual
difficulties in rebasing my track-panel-refactor branch onto the latest
master, because this project is introducing new state member variables into
class TrackPanel, but I am trying to eliminate such variables. I can't say
the same for the other two projects.
Ideally, the keyboard interaction for things like the clips should have be
written at the same time as the mouse interaction. Then, when you started
your refactor work, the requirements would have to there from the start. I
appreciate that me now trying to add keyboard interaction, is not ideal
from your point of view. However, if your refactor doesn't allow for
keyboard command which may need state variables to do equivalent tasks to
those currently only doable using a mouse, then the job of adding keyboard
interactions after your refactor will be more difficult. (There may be
similar issues if anyone tries to add keyboard interaction for envelope
points.)
Post by Paul Licameli
2) Less "selfishly:" the commit named above causes key down and
auto-repeat to do something analogous to click and drag, and key up to do
something analogous to release, which then (and only then) causes an undo
item to be pushed on the stack. But this is unprecedented. All other
existing keystroke commands using /wantkeyup did not have such implications
for Undo.
I think the current behaviour is what the user would expect - if the user
holds down the key assigned to move a clip, he really doesn't want 29
entries in history. (I checked how Reaper handles it. If you hold down a
key to move an item you get two entries in history - one for the first
little move, and one for the rest, which is rather strange, but still a lot
better than 29).
Post by Paul Licameli
Bind the new command to some key (I tried Shift + .), press that key, then
hit R, (or C) then release the keys. Regarding the pushing of Undo items
on the stack, what SHOULD happen, and when? What really DOES happen? A
bit of debugging makes me doubt whether this is all handled in a good
crash-proof way, though I haven't yet demonstrated a crash.
thanks, I hadn't thought about this. My initial thoughts are, that given it
will be very rare for a user to execute another command in the middle of
moving a clip:
1. If it causes a crash, this is obviously unacceptable.
2. If there's a minor issue such as the order of items in the history, then
although not ideal, it's probably not too much of an issue.
Post by Paul Licameli
In previous release I had to introduce the function TrackPanel::HandleInterruptedDrag
to do something in case the R key (or worse, Shift + C) is pushed during a
mouse click-drag-release and avoid crashes. I don't know that the
necessarily analogous thing is done here yet.
On each key down, the command starts from scratch finding clips to move -
it doesn't use any pointers that it assumes have previously been set up.
One thing I haven't finished doing is checking that trying to move clips
using keystrokes and the mouse at the same time is completely safe.
Post by Paul Licameli
It might entail difficult work in our dispatching of key events. Or it
may be that I want to complete an undo transaction, with consolidation, at
each auto repeat -- not wait for the key up -- to evade the problems.
All I can say is that it would be good if adding undo items on key up could
be made to work satisfactorily, as that's what would be most useful for
users. However, if not, then having separate items would be better than
nothing.

David.

ps On Windows there appears to be a problem with ctrl+z working after
moving clips using the keyboard due to some sort of focus issue - I'm
having a look at this problem.
Post by Paul Licameli
David, I want to unblock your efforts as soon as I can. We can talk
further about this. Whatever you do, don't use the word "sorry" in emails
to me! The apologies are all mine.
PRL
Post by Paul Licameli
Pending further study, I call a halt on David's clip move project, and I
may decide to revert commit b91160795dedce54745102027f8bb0908828772a and
request different solutions be found.
I will state my reasons very soon.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Robert Hänggi
2017-05-17 14:40:44 UTC
Permalink
Regarding key-up events:
Shidt+Alt+Up/down changes the gain on the focused track. It creates an
undo entry for each press of the arrow keys and this is annoying from
a user perspective.
Therefore, unprecedented or not, the key handling we currently have
isn't satisfactory in all cases.

Robert
Post by David Bailes
Post by Paul Licameli
1) Selfishly, I do not wish to delay the track panel refactor for another
release. Yes, this is a pet project of Paul without the RM hat on, but I
know I have the strong endorsement of James at least for it.
The efforts of James for theming, Pokechu22 for MIDI playback, and David
for clip move, all make some degree of difficulty in my continuing efforts
to rebase the branch track-panel-refactor onto latest master. I have
already faced a number of such in rebasing that from 2.1.2 onto 2.1.3. I
want to surmount those difficulties, and complete this nearly
two-year-old
effort in this release, and then forget about it.
I did green-light David's request to change TrackPanel.* while my
attention was elsewhere. However, I am now finding more than usual
difficulties in rebasing my track-panel-refactor branch onto the latest
master, because this project is introducing new state member variables into
class TrackPanel, but I am trying to eliminate such variables. I can't say
the same for the other two projects.
Ideally, the keyboard interaction for things like the clips should have be
written at the same time as the mouse interaction. Then, when you started
your refactor work, the requirements would have to there from the start. I
appreciate that me now trying to add keyboard interaction, is not ideal
from your point of view. However, if your refactor doesn't allow for
keyboard command which may need state variables to do equivalent tasks to
those currently only doable using a mouse, then the job of adding keyboard
interactions after your refactor will be more difficult. (There may be
similar issues if anyone tries to add keyboard interaction for envelope
points.)
Post by Paul Licameli
2) Less "selfishly:" the commit named above causes key down and
auto-repeat to do something analogous to click and drag, and key up to do
something analogous to release, which then (and only then) causes an undo
item to be pushed on the stack. But this is unprecedented. All other
existing keystroke commands using /wantkeyup did not have such implications
for Undo.
I think the current behaviour is what the user would expect - if the user
holds down the key assigned to move a clip, he really doesn't want 29
entries in history. (I checked how Reaper handles it. If you hold down a
key to move an item you get two entries in history - one for the first
little move, and one for the rest, which is rather strange, but still a lot
better than 29).
Post by Paul Licameli
Bind the new command to some key (I tried Shift + .), press that key, then
hit R, (or C) then release the keys. Regarding the pushing of Undo items
on the stack, what SHOULD happen, and when? What really DOES happen? A
bit of debugging makes me doubt whether this is all handled in a good
crash-proof way, though I haven't yet demonstrated a crash.
thanks, I hadn't thought about this. My initial thoughts are, that given it
will be very rare for a user to execute another command in the middle of
1. If it causes a crash, this is obviously unacceptable.
2. If there's a minor issue such as the order of items in the history, then
although not ideal, it's probably not too much of an issue.
Post by Paul Licameli
In previous release I had to introduce the function
TrackPanel::HandleInterruptedDrag
to do something in case the R key (or worse, Shift + C) is pushed during a
mouse click-drag-release and avoid crashes. I don't know that the
necessarily analogous thing is done here yet.
On each key down, the command starts from scratch finding clips to move -
it doesn't use any pointers that it assumes have previously been set up.
One thing I haven't finished doing is checking that trying to move clips
using keystrokes and the mouse at the same time is completely safe.
Post by Paul Licameli
It might entail difficult work in our dispatching of key events. Or it
may be that I want to complete an undo transaction, with consolidation, at
each auto repeat -- not wait for the key up -- to evade the problems.
All I can say is that it would be good if adding undo items on key up could
be made to work satisfactorily, as that's what would be most useful for
users. However, if not, then having separate items would be better than
nothing.
David.
ps On Windows there appears to be a problem with ctrl+z working after
moving clips using the keyboard due to some sort of focus issue - I'm
having a look at this problem.
Post by Paul Licameli
David, I want to unblock your efforts as soon as I can. We can talk
further about this. Whatever you do, don't use the word "sorry" in emails
to me! The apologies are all mine.
PRL
Post by Paul Licameli
Pending further study, I call a halt on David's clip move project, and I
may decide to revert commit b91160795dedce54745102027f8bb0908828772a and
request different solutions be found.
I will state my reasons very soon.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-05-17 23:39:57 UTC
Permalink
Post by Robert Hänggi
Shidt+Alt+Up/down changes the gain on the focused track. It creates an
undo entry for each press of the arrow keys and this is annoying from
a user perspective.
Therefore, unprecedented or not, the key handling we currently have
isn't satisfactory in all cases.
Robert
I, too, was about to mention exactly these commands asn another example
where we might want better consolidation.

PRL
Post by Robert Hänggi
Post by David Bailes
Post by Paul Licameli
1) Selfishly, I do not wish to delay the track panel refactor for
another
Post by David Bailes
Post by Paul Licameli
release. Yes, this is a pet project of Paul without the RM hat on, but
I
Post by David Bailes
Post by Paul Licameli
know I have the strong endorsement of James at least for it.
The efforts of James for theming, Pokechu22 for MIDI playback, and David
for clip move, all make some degree of difficulty in my continuing efforts
to rebase the branch track-panel-refactor onto latest master. I have
already faced a number of such in rebasing that from 2.1.2 onto 2.1.3.
I
Post by David Bailes
Post by Paul Licameli
want to surmount those difficulties, and complete this nearly two-year-old
effort in this release, and then forget about it.
I did green-light David's request to change TrackPanel.* while my
attention was elsewhere. However, I am now finding more than usual
difficulties in rebasing my track-panel-refactor branch onto the latest
master, because this project is introducing new state member variables into
class TrackPanel, but I am trying to eliminate such variables. I can't say
the same for the other two projects.
Ideally, the keyboard interaction for things like the clips should have
be
Post by David Bailes
written at the same time as the mouse interaction. Then, when you started
your refactor work, the requirements would have to there from the start.
I
Post by David Bailes
appreciate that me now trying to add keyboard interaction, is not ideal
from your point of view. However, if your refactor doesn't allow for
keyboard command which may need state variables to do equivalent tasks to
those currently only doable using a mouse, then the job of adding
keyboard
Post by David Bailes
interactions after your refactor will be more difficult. (There may be
similar issues if anyone tries to add keyboard interaction for envelope
points.)
Post by Paul Licameli
2) Less "selfishly:" the commit named above causes key down and
auto-repeat to do something analogous to click and drag, and key up to
do
Post by David Bailes
Post by Paul Licameli
something analogous to release, which then (and only then) causes an
undo
Post by David Bailes
Post by Paul Licameli
item to be pushed on the stack. But this is unprecedented. All other
existing keystroke commands using /wantkeyup did not have such implications
for Undo.
I think the current behaviour is what the user would expect - if the user
holds down the key assigned to move a clip, he really doesn't want 29
entries in history. (I checked how Reaper handles it. If you hold down a
key to move an item you get two entries in history - one for the first
little move, and one for the rest, which is rather strange, but still a
lot
Post by David Bailes
better than 29).
Post by Paul Licameli
Bind the new command to some key (I tried Shift + .), press that key, then
hit R, (or C) then release the keys. Regarding the pushing of Undo
items
Post by David Bailes
Post by Paul Licameli
on the stack, what SHOULD happen, and when? What really DOES happen? A
bit of debugging makes me doubt whether this is all handled in a good
crash-proof way, though I haven't yet demonstrated a crash.
thanks, I hadn't thought about this. My initial thoughts are, that given
it
Post by David Bailes
will be very rare for a user to execute another command in the middle of
1. If it causes a crash, this is obviously unacceptable.
2. If there's a minor issue such as the order of items in the history,
then
Post by David Bailes
although not ideal, it's probably not too much of an issue.
Post by Paul Licameli
In previous release I had to introduce the function
TrackPanel::HandleInterruptedDrag
to do something in case the R key (or worse, Shift + C) is pushed during a
mouse click-drag-release and avoid crashes. I don't know that the
necessarily analogous thing is done here yet.
On each key down, the command starts from scratch finding clips to move -
it doesn't use any pointers that it assumes have previously been set up.
One thing I haven't finished doing is checking that trying to move clips
using keystrokes and the mouse at the same time is completely safe.
Post by Paul Licameli
It might entail difficult work in our dispatching of key events. Or it
may be that I want to complete an undo transaction, with consolidation, at
each auto repeat -- not wait for the key up -- to evade the problems.
All I can say is that it would be good if adding undo items on key up
could
Post by David Bailes
be made to work satisfactorily, as that's what would be most useful for
users. However, if not, then having separate items would be better than
nothing.
David.
ps On Windows there appears to be a problem with ctrl+z working after
moving clips using the keyboard due to some sort of focus issue - I'm
having a look at this problem.
Post by Paul Licameli
David, I want to unblock your efforts as soon as I can. We can talk
further about this. Whatever you do, don't use the word "sorry" in emails
to me! The apologies are all mine.
PRL
Post by Paul Licameli
Pending further study, I call a halt on David's clip move project, and
I
Post by David Bailes
Post by Paul Licameli
Post by Paul Licameli
may decide to revert commit b91160795dedce54745102027f8bb0908828772a
and
Post by David Bailes
Post by Paul Licameli
Post by Paul Licameli
request different solutions be found.
I will state my reasons very soon.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
David Bailes
2017-05-17 15:10:36 UTC
Permalink
Post by David Bailes
Post by Paul Licameli
1) Selfishly, I do not wish to delay the track panel refactor for another
release. Yes, this is a pet project of Paul without the RM hat on, but I
know I have the strong endorsement of James at least for it.
The efforts of James for theming, Pokechu22 for MIDI playback, and David
for clip move, all make some degree of difficulty in my continuing efforts
to rebase the branch track-panel-refactor onto latest master. I have
already faced a number of such in rebasing that from 2.1.2 onto 2.1.3. I
want to surmount those difficulties, and complete this nearly two-year-old
effort in this release, and then forget about it.
I did green-light David's request to change TrackPanel.* while my
attention was elsewhere. However, I am now finding more than usual
difficulties in rebasing my track-panel-refactor branch onto the latest
master, because this project is introducing new state member variables into
class TrackPanel, but I am trying to eliminate such variables. I can't say
the same for the other two projects.
Ideally, the keyboard interaction for things like the clips should have be
written at the same time as the mouse interaction. Then, when you started
your refactor work, the requirements would have to there from the start. I
appreciate that me now trying to add keyboard interaction, is not ideal
from your point of view. However, if your refactor doesn't allow for
keyboard command which may need state variables to do equivalent tasks to
those currently only doable using a mouse, then the job of adding keyboard
interactions after your refactor will be more difficult. (There may be
similar issues if anyone tries to add keyboard interaction for envelope
points.)
Post by Paul Licameli
2) Less "selfishly:" the commit named above causes key down and
auto-repeat to do something analogous to click and drag, and key up to do
something analogous to release, which then (and only then) causes an undo
item to be pushed on the stack. But this is unprecedented. All other
existing keystroke commands using /wantkeyup did not have such implications
for Undo.
I think the current behaviour is what the user would expect - if the user
holds down the key assigned to move a clip, he really doesn't want 29
entries in history. (I checked how Reaper handles it. If you hold down a
key to move an item you get two entries in history - one for the first
little move, and one for the rest, which is rather strange, but still a lot
better than 29).
Post by Paul Licameli
Bind the new command to some key (I tried Shift + .), press that key,
then hit R, (or C) then release the keys. Regarding the pushing of Undo
items on the stack, what SHOULD happen, and when? What really DOES
happen? A bit of debugging makes me doubt whether this is all handled in a
good crash-proof way, though I haven't yet demonstrated a crash.
thanks, I hadn't thought about this. My initial thoughts are, that given
it will be very rare for a user to execute another command in the middle of
1. If it causes a crash, this is obviously unacceptable.
2. If there's a minor issue such as the order of items in the history,
then although not ideal, it's probably not too much of an issue.
Post by Paul Licameli
In previous release I had to introduce the function
TrackPanel::HandleInterruptedDrag to do something in case the R key (or
worse, Shift + C) is pushed during a mouse click-drag-release and avoid
crashes. I don't know that the necessarily analogous thing is done here
yet.
On each key down, the command starts from scratch finding clips to move -
it doesn't use any pointers that it assumes have previously been set up.
One thing I haven't finished doing is checking that trying to move clips
using keystrokes and the mouse at the same time is completely safe.
Post by Paul Licameli
It might entail difficult work in our dispatching of key events. Or it
may be that I want to complete an undo transaction, with consolidation, at
each auto repeat -- not wait for the key up -- to evade the problems.
All I can say is that it would be good if adding undo items on key up
could be made to work satisfactorily, as that's what would be most useful
for users. However, if not, then having separate items would be better than
nothing.
David.
ps On Windows there appears to be a problem with ctrl+z working after
moving clips using the keyboard due to some sort of focus issue - I'm
having a look at this problem.
There's a simple fix for this problem (though I'm not sure how it was
working when I tested it before committing it!)
https://github.com/DavidBailes/audacity/commit/60d943bc034c84edc9f2a54bc87355f6e0bc1f62

David.
Post by David Bailes
Post by Paul Licameli
David, I want to unblock your efforts as soon as I can. We can talk
further about this. Whatever you do, don't use the word "sorry" in emails
to me! The apologies are all mine.
PRL
Post by Paul Licameli
Pending further study, I call a halt on David's clip move project, and I
may decide to revert commit b91160795dedce54745102027f8bb0908828772a
and request different solutions be found.
I will state my reasons very soon.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
David Bailes
2017-05-17 15:26:45 UTC
Permalink
Post by David Bailes
Post by David Bailes
Post by Paul Licameli
1) Selfishly, I do not wish to delay the track panel refactor for
another release. Yes, this is a pet project of Paul without the RM hat on,
but I know I have the strong endorsement of James at least for it.
The efforts of James for theming, Pokechu22 for MIDI playback, and David
for clip move, all make some degree of difficulty in my continuing efforts
to rebase the branch track-panel-refactor onto latest master. I have
already faced a number of such in rebasing that from 2.1.2 onto 2.1.3. I
want to surmount those difficulties, and complete this nearly two-year-old
effort in this release, and then forget about it.
I did green-light David's request to change TrackPanel.* while my
attention was elsewhere. However, I am now finding more than usual
difficulties in rebasing my track-panel-refactor branch onto the latest
master, because this project is introducing new state member variables into
class TrackPanel, but I am trying to eliminate such variables. I can't say
the same for the other two projects.
Ideally, the keyboard interaction for things like the clips should have
be written at the same time as the mouse interaction. Then, when you
started your refactor work, the requirements would have to there from the
start. I appreciate that me now trying to add keyboard interaction, is not
ideal from your point of view. However, if your refactor doesn't allow for
keyboard command which may need state variables to do equivalent tasks to
those currently only doable using a mouse, then the job of adding keyboard
interactions after your refactor will be more difficult. (There may be
similar issues if anyone tries to add keyboard interaction for envelope
points.)
Post by Paul Licameli
2) Less "selfishly:" the commit named above causes key down and
auto-repeat to do something analogous to click and drag, and key up to do
something analogous to release, which then (and only then) causes an undo
item to be pushed on the stack. But this is unprecedented. All other
existing keystroke commands using /wantkeyup did not have such implications
for Undo.
I think the current behaviour is what the user would expect - if the user
holds down the key assigned to move a clip, he really doesn't want 29
entries in history. (I checked how Reaper handles it. If you hold down a
key to move an item you get two entries in history - one for the first
little move, and one for the rest, which is rather strange, but still a lot
better than 29).
Post by Paul Licameli
Bind the new command to some key (I tried Shift + .), press that key,
then hit R, (or C) then release the keys. Regarding the pushing of Undo
items on the stack, what SHOULD happen, and when? What really DOES
happen? A bit of debugging makes me doubt whether this is all handled in a
good crash-proof way, though I haven't yet demonstrated a crash.
thanks, I hadn't thought about this. My initial thoughts are, that given
it will be very rare for a user to execute another command in the middle of
1. If it causes a crash, this is obviously unacceptable.
2. If there's a minor issue such as the order of items in the history,
then although not ideal, it's probably not too much of an issue.
Post by Paul Licameli
In previous release I had to introduce the function
TrackPanel::HandleInterruptedDrag to do something in case the R key (or
worse, Shift + C) is pushed during a mouse click-drag-release and avoid
crashes. I don't know that the necessarily analogous thing is done here
yet.
On each key down, the command starts from scratch finding clips to move -
it doesn't use any pointers that it assumes have previously been set up.
One thing I haven't finished doing is checking that trying to move clips
using keystrokes and the mouse at the same time is completely safe.
Post by Paul Licameli
It might entail difficult work in our dispatching of key events. Or it
may be that I want to complete an undo transaction, with consolidation, at
each auto repeat -- not wait for the key up -- to evade the problems.
All I can say is that it would be good if adding undo items on key up
could be made to work satisfactorily, as that's what would be most useful
for users. However, if not, then having separate items would be better than
nothing.
David.
ps On Windows there appears to be a problem with ctrl+z working after
moving clips using the keyboard due to some sort of focus issue - I'm
having a look at this problem.
There's a simple fix for this problem (though I'm not sure how it was
working when I tested it before committing it!)
https://github.com/DavidBailes/audacity/commit/
60d943bc034c84edc9f2a54bc87355f6e0bc1f62
In this patch I've added:
if (mMouseCapture == IsSliding)
+ return;

at the start of the function. Would a better test be something like (
mMouseCapture != IsUncaptured) to stop doing anything. Or something else?

David.
Post by David Bailes
David.
Post by David Bailes
Post by Paul Licameli
David, I want to unblock your efforts as soon as I can. We can talk
further about this. Whatever you do, don't use the word "sorry" in emails
to me! The apologies are all mine.
PRL
Post by Paul Licameli
Pending further study, I call a halt on David's clip move project, and
I may decide to revert commit b91160795dedce54745102027f8bb0908828772a
and request different solutions be found.
I will state my reasons very soon.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-05-18 14:17:20 UTC
Permalink
Post by David Bailes
Post by David Bailes
Post by Paul Licameli
1) Selfishly, I do not wish to delay the track panel refactor for
another release. Yes, this is a pet project of Paul without the RM hat on,
but I know I have the strong endorsement of James at least for it.
The efforts of James for theming, Pokechu22 for MIDI playback, and David
for clip move, all make some degree of difficulty in my continuing efforts
to rebase the branch track-panel-refactor onto latest master. I have
already faced a number of such in rebasing that from 2.1.2 onto 2.1.3. I
want to surmount those difficulties, and complete this nearly two-year-old
effort in this release, and then forget about it.
I did green-light David's request to change TrackPanel.* while my
attention was elsewhere. However, I am now finding more than usual
difficulties in rebasing my track-panel-refactor branch onto the latest
master, because this project is introducing new state member variables into
class TrackPanel, but I am trying to eliminate such variables. I can't say
the same for the other two projects.
Ideally, the keyboard interaction for things like the clips should have
be written at the same time as the mouse interaction. Then, when you
started your refactor work, the requirements would have to there from the
start. I appreciate that me now trying to add keyboard interaction, is not
ideal from your point of view. However, if your refactor doesn't allow for
keyboard command which may need state variables to do equivalent tasks to
those currently only doable using a mouse, then the job of adding keyboard
interactions after your refactor will be more difficult. (There may be
similar issues if anyone tries to add keyboard interaction for envelope
points.)
Track panel refactor is in large part about defining a class that abstracts
click-drag-release actions and making subclasses of it for the several
operations, rather than slicing the problem the other way and having
TrackPanel as one big class reponsible for it all, with many switch
statements.

I am trying to tame the chaos in the code we had. There were not (yet) any
click-drag-release equivalents by the other means of keystrokes before this
attempt, so there was no allowance for it yet in my work.

I ruled against this project, because accommodating it as it was first
written made too difficult an obstacle. But you can be sure that you have
set me thinking how keystroke equivalents ought to be accommodated in a
good general fashoin.
Post by David Bailes
Post by David Bailes
Post by Paul Licameli
2) Less "selfishly:" the commit named above causes key down and
auto-repeat to do something analogous to click and drag, and key up to do
something analogous to release, which then (and only then) causes an undo
item to be pushed on the stack. But this is unprecedented. All other
existing keystroke commands using /wantkeyup did not have such implications
for Undo.
I think the current behaviour is what the user would expect - if the user
holds down the key assigned to move a clip, he really doesn't want 29
entries in history. (I checked how Reaper handles it. If you hold down a
key to move an item you get two entries in history - one for the first
little move, and one for the rest, which is rather strange, but still a lot
better than 29).
Commit 63ae687 addresses this objection. I was aware of it too because the
little-known Stretch feature of MIDI tracks suffered a similar problem, and
improving this and other problems in stretch is one of my smaller aims for
2.2.0.
Post by David Bailes
Post by David Bailes
Post by Paul Licameli
Bind the new command to some key (I tried Shift + .), press that key,
then hit R, (or C) then release the keys. Regarding the pushing of Undo
items on the stack, what SHOULD happen, and when? What really DOES
happen? A bit of debugging makes me doubt whether this is all handled in a
good crash-proof way, though I haven't yet demonstrated a crash.
thanks, I hadn't thought about this. My initial thoughts are, that given
it will be very rare for a user to execute another command in the middle of
1. If it causes a crash, this is obviously unacceptable.
2. If there's a minor issue such as the order of items in the history,
then although not ideal, it's probably not too much of an issue.
I worry about dangling pointers to tracks. Or you could have a pointer to
a track that is in an Undo history state, rather than in the current state
of the project.

It is also possible that part of the shifting changes might get combined
with the recording as one Undo item. Not so serious, but then "Undo
Record" doesn't do exactly what it says.
Post by David Bailes
Post by David Bailes
Post by Paul Licameli
In previous release I had to introduce the function
TrackPanel::HandleInterruptedDrag to do something in case the R key (or
worse, Shift + C) is pushed during a mouse click-drag-release and avoid
crashes. I don't know that the necessarily analogous thing is done here
yet.
On each key down, the command starts from scratch finding clips to move -
it doesn't use any pointers that it assumes have previously been set up.
Not pointers to clips. But to tracks?
Post by David Bailes
One thing I haven't finished doing is checking that trying to move clips
Post by David Bailes
using keystrokes and the mouse at the same time is completely safe.
Post by Paul Licameli
It might entail difficult work in our dispatching of key events. Or it
may be that I want to complete an undo transaction, with consolidation, at
each auto repeat -- not wait for the key up -- to evade the problems.
All I can say is that it would be good if adding undo items on key up
could be made to work satisfactorily, as that's what would be most useful
for users. However, if not, then having separate items would be better than
nothing.
Again, there is improvement now in the behavior of the Undo manager.
Perhaps the program does excessive work consolidating Undo items with each
increment, but the user visible problem is addressed.
Post by David Bailes
Post by David Bailes
David.
ps On Windows there appears to be a problem with ctrl+z working after
moving clips using the keyboard due to some sort of focus issue - I'm
having a look at this problem.
There's a simple fix for this problem (though I'm not sure how it was
working when I tested it before committing it!)
https://github.com/DavidBailes/audacity/commit/
60d943bc034c84edc9f2a54bc87355f6e0bc1f62
This change would conflict with what I lately did. TrackPanel::OnClipMove
becomes a static function.

I don't understand how this would solve the focus issure.

PRL
Post by David Bailes
David.
Post by David Bailes
Post by Paul Licameli
David, I want to unblock your efforts as soon as I can. We can talk
further about this. Whatever you do, don't use the word "sorry" in emails
to me! The apologies are all mine.
PRL
Post by Paul Licameli
Pending further study, I call a halt on David's clip move project, and
I may decide to revert commit b91160795dedce54745102027f8bb0908828772a
and request different solutions be found.
I will state my reasons very soon.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-05-18 12:17:58 UTC
Permalink
David, please see commit d36ac2cedbee316a8298e239b02846b4aff9b544

I reverted some of your work. Time shift commands still do not have undo
items. You must fix that again, differently.

As I explained, please push undo with each key-down (or auto-repeat) event,
even if that is not wholly satisfactory.

The total slide amount may need to be left out of the message. I have
deprived you of a place to store and update that variable.

Another thing: I notice that you form an undo message making assumptions
about word order in the human language. You concatenate "Time shifted
clips" with either "right" or "left". That might be an English bias that
doesn't work well for all languages.

Maybe instead you should format "Time shifted clips %s" supplying either
"leftward" or "rightward" and make an i18n-hint comment explaining the
substitution for %s.

PRL
Post by Paul Licameli
1) Selfishly, I do not wish to delay the track panel refactor for another
release. Yes, this is a pet project of Paul without the RM hat on, but I
know I have the strong endorsement of James at least for it.
The efforts of James for theming, Pokechu22 for MIDI playback, and David
for clip move, all make some degree of difficulty in my continuing efforts
to rebase the branch track-panel-refactor onto latest master. I have
already faced a number of such in rebasing that from 2.1.2 onto 2.1.3. I
want to surmount those difficulties, and complete this nearly two-year-old
effort in this release, and then forget about it.
I did green-light David's request to change TrackPanel.* while my
attention was elsewhere. However, I am now finding more than usual
difficulties in rebasing my track-panel-refactor branch onto the latest
master, because this project is introducing new state member variables into
class TrackPanel, but I am trying to eliminate such variables. I can't say
the same for the other two projects.
2) Less "selfishly:" the commit named above causes key down and
auto-repeat to do something analogous to click and drag, and key up to do
something analogous to release, which then (and only then) causes an undo
item to be pushed on the stack. But this is unprecedented. All other
existing keystroke commands using /wantkeyup did not have such implications
for Undo.
Bind the new command to some key (I tried Shift + .), press that key, then
hit R, (or C) then release the keys. Regarding the pushing of Undo items
on the stack, what SHOULD happen, and when? What really DOES happen? A
bit of debugging makes me doubt whether this is all handled in a good
crash-proof way, though I haven't yet demonstrated a crash.
In previous release I had to introduce the function TrackPanel::HandleInterruptedDrag
to do something in case the R key (or worse, Shift + C) is pushed during a
mouse click-drag-release and avoid crashes. I don't know that the
necessarily analogous thing is done here yet.
It might entail difficult work in our dispatching of key events. Or it
may be that I want to complete an undo transaction, with consolidation, at
each auto repeat -- not wait for the key up -- to evade the problems.
David, I want to unblock your efforts as soon as I can. We can talk
further about this. Whatever you do, don't use the word "sorry" in emails
to me! The apologies are all mine.
PRL
Post by Paul Licameli
Pending further study, I call a halt on David's clip move project, and I
may decide to revert commit b91160795dedce54745102027f8bb0908828772a and
request different solutions be found.
I will state my reasons very soon.
PRL
Paul Licameli
2017-05-18 13:06:05 UTC
Permalink
I have now changed the Undo manager so that consolidation works better.
This addresses the problem of excessive items created by a long train of
auto-repeats of keystrokes, when each pushes.

In case I didn't make it clear, this project is now un-halted with the new
understanding of how it will work.

PRL
Post by Paul Licameli
David, please see commit d36ac2cedbee316a8298e239b02846b4aff9b544
I reverted some of your work. Time shift commands still do not have undo
items. You must fix that again, differently.
As I explained, please push undo with each key-down (or auto-repeat)
event, even if that is not wholly satisfactory.
The total slide amount may need to be left out of the message. I have
deprived you of a place to store and update that variable.
Another thing: I notice that you form an undo message making assumptions
about word order in the human language. You concatenate "Time shifted
clips" with either "right" or "left". That might be an English bias that
doesn't work well for all languages.
Maybe instead you should format "Time shifted clips %s" supplying either
"leftward" or "rightward" and make an i18n-hint comment explaining the
substitution for %s.
PRL
Post by Paul Licameli
1) Selfishly, I do not wish to delay the track panel refactor for another
release. Yes, this is a pet project of Paul without the RM hat on, but I
know I have the strong endorsement of James at least for it.
The efforts of James for theming, Pokechu22 for MIDI playback, and David
for clip move, all make some degree of difficulty in my continuing efforts
to rebase the branch track-panel-refactor onto latest master. I have
already faced a number of such in rebasing that from 2.1.2 onto 2.1.3. I
want to surmount those difficulties, and complete this nearly two-year-old
effort in this release, and then forget about it.
I did green-light David's request to change TrackPanel.* while my
attention was elsewhere. However, I am now finding more than usual
difficulties in rebasing my track-panel-refactor branch onto the latest
master, because this project is introducing new state member variables into
class TrackPanel, but I am trying to eliminate such variables. I can't say
the same for the other two projects.
2) Less "selfishly:" the commit named above causes key down and
auto-repeat to do something analogous to click and drag, and key up to do
something analogous to release, which then (and only then) causes an undo
item to be pushed on the stack. But this is unprecedented. All other
existing keystroke commands using /wantkeyup did not have such implications
for Undo.
Bind the new command to some key (I tried Shift + .), press that key,
then hit R, (or C) then release the keys. Regarding the pushing of Undo
items on the stack, what SHOULD happen, and when? What really DOES
happen? A bit of debugging makes me doubt whether this is all handled in a
good crash-proof way, though I haven't yet demonstrated a crash.
In previous release I had to introduce the function
TrackPanel::HandleInterruptedDrag to do something in case the R key (or
worse, Shift + C) is pushed during a mouse click-drag-release and avoid
crashes. I don't know that the necessarily analogous thing is done here
yet.
It might entail difficult work in our dispatching of key events. Or it
may be that I want to complete an undo transaction, with consolidation, at
each auto repeat -- not wait for the key up -- to evade the problems.
David, I want to unblock your efforts as soon as I can. We can talk
further about this. Whatever you do, don't use the word "sorry" in emails
to me! The apologies are all mine.
PRL
Post by Paul Licameli
Pending further study, I call a halt on David's clip move project, and I
may decide to revert commit b91160795dedce54745102027f8bb0908828772a
and request different solutions be found.
I will state my reasons very soon.
PRL
David Bailes
2017-05-23 10:10:07 UTC
Permalink
Post by Paul Licameli
I have now changed the Undo manager so that consolidation works better.
This addresses the problem of excessive items created by a long train of
auto-repeats of keystrokes, when each pushes.
In case I didn't make it clear, this project is now un-halted with the new
understanding of how it will work.
Thanks for the change to Undo manager. I've just committed a second attempt
at updating history:
https://github.com/audacity/audacity/commit/f46ac268f4420d7fa924f0c218a2ef8ab9f66221

Is this OK now?
David.
Post by Paul Licameli
PRL
Post by Paul Licameli
David, please see commit d36ac2cedbee316a8298e239b02846b4aff9b544
I reverted some of your work. Time shift commands still do not have undo
items. You must fix that again, differently.
As I explained, please push undo with each key-down (or auto-repeat)
event, even if that is not wholly satisfactory.
The total slide amount may need to be left out of the message. I have
deprived you of a place to store and update that variable.
Another thing: I notice that you form an undo message making assumptions
about word order in the human language. You concatenate "Time shifted
clips" with either "right" or "left". That might be an English bias that
doesn't work well for all languages.
Maybe instead you should format "Time shifted clips %s" supplying either
"leftward" or "rightward" and make an i18n-hint comment explaining the
substitution for %s.
PRL
Post by Paul Licameli
1) Selfishly, I do not wish to delay the track panel refactor for
another release. Yes, this is a pet project of Paul without the RM hat on,
but I know I have the strong endorsement of James at least for it.
The efforts of James for theming, Pokechu22 for MIDI playback, and David
for clip move, all make some degree of difficulty in my continuing efforts
to rebase the branch track-panel-refactor onto latest master. I have
already faced a number of such in rebasing that from 2.1.2 onto 2.1.3. I
want to surmount those difficulties, and complete this nearly two-year-old
effort in this release, and then forget about it.
I did green-light David's request to change TrackPanel.* while my
attention was elsewhere. However, I am now finding more than usual
difficulties in rebasing my track-panel-refactor branch onto the latest
master, because this project is introducing new state member variables into
class TrackPanel, but I am trying to eliminate such variables. I can't say
the same for the other two projects.
2) Less "selfishly:" the commit named above causes key down and
auto-repeat to do something analogous to click and drag, and key up to do
something analogous to release, which then (and only then) causes an undo
item to be pushed on the stack. But this is unprecedented. All other
existing keystroke commands using /wantkeyup did not have such implications
for Undo.
Bind the new command to some key (I tried Shift + .), press that key,
then hit R, (or C) then release the keys. Regarding the pushing of Undo
items on the stack, what SHOULD happen, and when? What really DOES
happen? A bit of debugging makes me doubt whether this is all handled in a
good crash-proof way, though I haven't yet demonstrated a crash.
In previous release I had to introduce the function
TrackPanel::HandleInterruptedDrag to do something in case the R key (or
worse, Shift + C) is pushed during a mouse click-drag-release and avoid
crashes. I don't know that the necessarily analogous thing is done here
yet.
It might entail difficult work in our dispatching of key events. Or it
may be that I want to complete an undo transaction, with consolidation, at
each auto repeat -- not wait for the key up -- to evade the problems.
David, I want to unblock your efforts as soon as I can. We can talk
further about this. Whatever you do, don't use the word "sorry" in emails
to me! The apologies are all mine.
PRL
Post by Paul Licameli
Pending further study, I call a halt on David's clip move project, and
I may decide to revert commit b91160795dedce54745102027f8bb0908828772a
and request different solutions be found.
I will state my reasons very soon.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-05-24 00:27:31 UTC
Permalink
Post by David Bailes
Post by Paul Licameli
I have now changed the Undo manager so that consolidation works better.
This addresses the problem of excessive items created by a long train of
auto-repeats of keystrokes, when each pushes.
In case I didn't make it clear, this project is now un-halted with the
new understanding of how it will work.
Thanks for the change to Undo manager. I've just committed a second
https://github.com/audacity/audacity/commit/f46ac268f4420d7fa924f0c218a2ef
8ab9f66221
Is this OK now?
David.
This looks good, but now I think the UndoManager should be changed to make
your change easier so that you don't need to maintain the variable
mNKeyDown.

You may see me commit this soon.

PRL
Post by David Bailes
Post by Paul Licameli
PRL
Post by Paul Licameli
David, please see commit d36ac2cedbee316a8298e239b02846b4aff9b544
I reverted some of your work. Time shift commands still do not have
undo items. You must fix that again, differently.
As I explained, please push undo with each key-down (or auto-repeat)
event, even if that is not wholly satisfactory.
The total slide amount may need to be left out of the message. I have
deprived you of a place to store and update that variable.
Another thing: I notice that you form an undo message making
assumptions about word order in the human language. You concatenate "Time
shifted clips" with either "right" or "left". That might be an English
bias that doesn't work well for all languages.
Maybe instead you should format "Time shifted clips %s" supplying either
"leftward" or "rightward" and make an i18n-hint comment explaining the
substitution for %s.
PRL
Post by Paul Licameli
1) Selfishly, I do not wish to delay the track panel refactor for
another release. Yes, this is a pet project of Paul without the RM hat on,
but I know I have the strong endorsement of James at least for it.
The efforts of James for theming, Pokechu22 for MIDI playback, and
David for clip move, all make some degree of difficulty in my continuing
efforts to rebase the branch track-panel-refactor onto latest master. I
have already faced a number of such in rebasing that from 2.1.2 onto
2.1.3. I want to surmount those difficulties, and complete this nearly
two-year-old effort in this release, and then forget about it.
I did green-light David's request to change TrackPanel.* while my
attention was elsewhere. However, I am now finding more than usual
difficulties in rebasing my track-panel-refactor branch onto the latest
master, because this project is introducing new state member variables into
class TrackPanel, but I am trying to eliminate such variables. I can't say
the same for the other two projects.
2) Less "selfishly:" the commit named above causes key down and
auto-repeat to do something analogous to click and drag, and key up to do
something analogous to release, which then (and only then) causes an undo
item to be pushed on the stack. But this is unprecedented. All other
existing keystroke commands using /wantkeyup did not have such implications
for Undo.
Bind the new command to some key (I tried Shift + .), press that key,
then hit R, (or C) then release the keys. Regarding the pushing of Undo
items on the stack, what SHOULD happen, and when? What really DOES
happen? A bit of debugging makes me doubt whether this is all handled in a
good crash-proof way, though I haven't yet demonstrated a crash.
In previous release I had to introduce the function
TrackPanel::HandleInterruptedDrag to do something in case the R key
(or worse, Shift + C) is pushed during a mouse click-drag-release and avoid
crashes. I don't know that the necessarily analogous thing is done here
yet.
It might entail difficult work in our dispatching of key events. Or it
may be that I want to complete an undo transaction, with consolidation, at
each auto repeat -- not wait for the key up -- to evade the problems.
David, I want to unblock your efforts as soon as I can. We can talk
further about this. Whatever you do, don't use the word "sorry" in emails
to me! The apologies are all mine.
PRL
Post by Paul Licameli
Pending further study, I call a halt on David's clip move project, and
I may decide to revert commit b91160795dedce54745102027f8bb0908828772a
and request different solutions be found.
I will state my reasons very soon.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
David Bailes
2017-05-25 09:17:56 UTC
Permalink
Post by Paul Licameli
Post by David Bailes
Post by Paul Licameli
I have now changed the Undo manager so that consolidation works better.
This addresses the problem of excessive items created by a long train of
auto-repeats of keystrokes, when each pushes.
In case I didn't make it clear, this project is now un-halted with the
new understanding of how it will work.
Thanks for the change to Undo manager. I've just committed a second
https://github.com/audacity/audacity/commit/f46ac268f4420d7f
a924f0c218a2ef8ab9f66221
Is this OK now?
David.
This looks good, but now I think the UndoManager should be changed to make
your change easier so that you don't need to maintain the variable
mNKeyDown.
You may see me commit this soon.
that's better,
David.
Post by Paul Licameli
PRL
Post by David Bailes
Post by Paul Licameli
PRL
Post by Paul Licameli
David, please see commit d36ac2cedbee316a8298e239b02846b4aff9b544
I reverted some of your work. Time shift commands still do not have
undo items. You must fix that again, differently.
As I explained, please push undo with each key-down (or auto-repeat)
event, even if that is not wholly satisfactory.
The total slide amount may need to be left out of the message. I have
deprived you of a place to store and update that variable.
Another thing: I notice that you form an undo message making
assumptions about word order in the human language. You concatenate "Time
shifted clips" with either "right" or "left". That might be an English
bias that doesn't work well for all languages.
Maybe instead you should format "Time shifted clips %s" supplying
either "leftward" or "rightward" and make an i18n-hint comment explaining
the substitution for %s.
PRL
Post by Paul Licameli
1) Selfishly, I do not wish to delay the track panel refactor for
another release. Yes, this is a pet project of Paul without the RM hat on,
but I know I have the strong endorsement of James at least for it.
The efforts of James for theming, Pokechu22 for MIDI playback, and
David for clip move, all make some degree of difficulty in my continuing
efforts to rebase the branch track-panel-refactor onto latest master. I
have already faced a number of such in rebasing that from 2.1.2 onto
2.1.3. I want to surmount those difficulties, and complete this nearly
two-year-old effort in this release, and then forget about it.
I did green-light David's request to change TrackPanel.* while my
attention was elsewhere. However, I am now finding more than usual
difficulties in rebasing my track-panel-refactor branch onto the latest
master, because this project is introducing new state member variables into
class TrackPanel, but I am trying to eliminate such variables. I can't say
the same for the other two projects.
2) Less "selfishly:" the commit named above causes key down and
auto-repeat to do something analogous to click and drag, and key up to do
something analogous to release, which then (and only then) causes an undo
item to be pushed on the stack. But this is unprecedented. All other
existing keystroke commands using /wantkeyup did not have such implications
for Undo.
Bind the new command to some key (I tried Shift + .), press that key,
then hit R, (or C) then release the keys. Regarding the pushing of Undo
items on the stack, what SHOULD happen, and when? What really DOES
happen? A bit of debugging makes me doubt whether this is all handled in a
good crash-proof way, though I haven't yet demonstrated a crash.
In previous release I had to introduce the function
TrackPanel::HandleInterruptedDrag to do something in case the R key
(or worse, Shift + C) is pushed during a mouse click-drag-release and avoid
crashes. I don't know that the necessarily analogous thing is done here
yet.
It might entail difficult work in our dispatching of key events. Or
it may be that I want to complete an undo transaction, with consolidation,
at each auto repeat -- not wait for the key up -- to evade the problems.
David, I want to unblock your efforts as soon as I can. We can talk
further about this. Whatever you do, don't use the word "sorry" in emails
to me! The apologies are all mine.
PRL
On Tue, May 16, 2017 at 6:52 PM, Paul Licameli <
Post by Paul Licameli
Pending further study, I call a halt on David's clip move project,
and I may decide to revert commit b91160795dedce54745102027f8bb0908828772a
and request different solutions be found.
I will state my reasons very soon.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...