Release Manager is calling HALT on the clip move project

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Release Manager is calling HALT on the clip move project

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release Manager is calling HALT on the clip move project

Paul Licameli
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



On Tue, May 16, 2017 at 6:52 PM, Paul Licameli <[hidden email]> wrote:
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release Manager is calling HALT on the clip move project

David Bailes-3
On Wed, May 17, 2017 at 12:38 AM, Paul Licameli <[hidden email]> wrote:
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.

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.)

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).

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. 

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.

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.



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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release Manager is calling HALT on the clip move project

Robert Hänggi
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

On 17/05/2017, David Bailes <[hidden email]> wrote:

> On Wed, May 17, 2017 at 12:38 AM, Paul Licameli <[hidden email]>
> wrote:
>
>> 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.
>>
>>
> 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.)
>
>>
>> 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).
>
>>
>> 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.
>
>>
>> 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.
>
>>
>> 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.
>
>
>
>> 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 <[hidden email]>
>> wrote:
>>
>>> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release Manager is calling HALT on the clip move project

David Bailes-3
In reply to this post by David Bailes-3
On Wed, May 17, 2017 at 1:53 PM, David Bailes <[hidden email]> wrote:
On Wed, May 17, 2017 at 12:38 AM, Paul Licameli <[hidden email]> wrote:
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.

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.)

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).

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. 

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.

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!)

David.
 



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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release Manager is calling HALT on the clip move project

David Bailes-3
On Wed, May 17, 2017 at 4:10 PM, David Bailes <[hidden email]> wrote:
On Wed, May 17, 2017 at 1:53 PM, David Bailes <[hidden email]> wrote:
On Wed, May 17, 2017 at 12:38 AM, Paul Licameli <[hidden email]> wrote:
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.

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.)

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).

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. 

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.

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!)

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. 

David.
 



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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release Manager is calling HALT on the clip move project

Paul Licameli
In reply to this post by Robert Hänggi


On Wed, May 17, 2017 at 10:40 AM, Robert Hänggi <[hidden email]> wrote:
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


I, too, was about to mention exactly these commands asn another example where we might want better consolidation.

PRL

 
On 17/05/2017, David Bailes <[hidden email]> wrote:
> On Wed, May 17, 2017 at 12:38 AM, Paul Licameli <[hidden email]>
> wrote:
>
>> 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.
>>
>>
> 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.)
>
>>
>> 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).
>
>>
>> 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.
>
>>
>> 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.
>
>>
>> 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.
>
>
>
>> 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 <[hidden email]>
>> wrote:
>>
>>> 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
>> [hidden email]
>> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release Manager is calling HALT on the clip move project

Paul Licameli
In reply to this 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





On Tue, May 16, 2017 at 7:38 PM, Paul Licameli <[hidden email]> wrote:
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



On Tue, May 16, 2017 at 6:52 PM, Paul Licameli <[hidden email]> wrote:
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release Manager is calling HALT on the clip move project

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.

PRL


On Thu, May 18, 2017 at 8:17 AM, Paul Licameli <[hidden email]> wrote:
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





On Tue, May 16, 2017 at 7:38 PM, Paul Licameli <[hidden email]> wrote:
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



On Tue, May 16, 2017 at 6:52 PM, Paul Licameli <[hidden email]> wrote:
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release Manager is calling HALT on the clip move project

Paul Licameli
In reply to this post by David Bailes-3


On Wed, May 17, 2017 at 11:10 AM, David Bailes <[hidden email]> wrote:
On Wed, May 17, 2017 at 1:53 PM, David Bailes <[hidden email]> wrote:
On Wed, May 17, 2017 at 12:38 AM, Paul Licameli <[hidden email]> wrote:
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.

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.

 

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.
 

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. 

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.
 

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?
 
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.

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.
 

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!)

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

 

David.
 



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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release Manager is calling HALT on the clip move project

David Bailes-3
In reply to this post by Paul Licameli
On Thu, May 18, 2017 at 2:06 PM, Paul Licameli <[hidden email]> wrote:
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:

Is this OK now?
David.
 

PRL


On Thu, May 18, 2017 at 8:17 AM, Paul Licameli <[hidden email]> wrote:
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





On Tue, May 16, 2017 at 7:38 PM, Paul Licameli <[hidden email]> wrote:
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



On Tue, May 16, 2017 at 6:52 PM, Paul Licameli <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release Manager is calling HALT on the clip move project

Paul Licameli


On Tue, May 23, 2017 at 6:10 AM, David Bailes <[hidden email]> wrote:
On Thu, May 18, 2017 at 2:06 PM, Paul Licameli <[hidden email]> wrote:
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:

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

 
 

PRL


On Thu, May 18, 2017 at 8:17 AM, Paul Licameli <[hidden email]> wrote:
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





On Tue, May 16, 2017 at 7:38 PM, Paul Licameli <[hidden email]> wrote:
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



On Tue, May 16, 2017 at 6:52 PM, Paul Licameli <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Release Manager is calling HALT on the clip move project

David Bailes-3
On Wed, May 24, 2017 at 1:27 AM, Paul Licameli <[hidden email]> wrote:


On Tue, May 23, 2017 at 6:10 AM, David Bailes <[hidden email]> wrote:
On Thu, May 18, 2017 at 2:06 PM, Paul Licameli <[hidden email]> wrote:
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:

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.
 

PRL

 
 

PRL


On Thu, May 18, 2017 at 8:17 AM, Paul Licameli <[hidden email]> wrote:
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





On Tue, May 16, 2017 at 7:38 PM, Paul Licameli <[hidden email]> wrote:
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



On Tue, May 16, 2017 at 6:52 PM, Paul Licameli <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel