Hit test inconsistencies

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

Hit test inconsistencies

Paul Licameli
My track panel refactor took some pains to preserve some old inconsistencies in behavior, complicating the resulting code more than I like.  Perhaps it isn't worth it.  I think what I preserved was a pile of ad-hocs that did not reflect a deliberate design.

I refer to hit-testing matters and the interaction with the Tools toolbar.

(I think the Tools toolbar should be abolished.  I would like to allow multiple hit-test targets at the mouse position in any track, and let the TAB key cycle among candidates.  But that may be too much to try in 2.2.0.)

Can we agree on simple, consistent behavior?

1. Should "special" hit test targets take priority over the tool, or not?  For both buttons, always?  Or only for right button when the target does something?  I describe 2.1.3 behavior.
  • The resizer handle at the bottom of a track is available no matter what tool, for left click, but not for right click or drag in Multi which still does a zoom.
  • Cut-lines and clip boundaries in Wave tracks take priority in all tools and both buttons (except, see 4).  Right-click on cut-line to delete even takes priority over the zooming behavior in multi-tool.  Right-click and drag on a clip boundary does nothing in multi.
  • Label end handles take priority in all tools, though not when right-clicking in Multi.  They have no special right-click action.
  • Label text boxes have no preview cursor or status bar message, passing the default cursor and message for the tool, but take the left click (to edit) and right (for context menu) in all tools.  So I can see a magnifier cursor but still click to edit.
  • The hot-zone for stretching a Note track (at middle height in the selection) takes priority only in Select or Multi and is otherwise unavailable.
  • The grips for time-shift, at left and right edges in Multi, do not take the right click.
  • Other special wave track targets (envelope, samples) do not take priority over right click in Multi.
2. Should right clicks be reserved for context menus, as in many other applications?  Little loss if deletion of a cutline gets a bit more complicated.  Multi would lose the zoom-out, but that is redundant with Ctrl+3.  But this is post 2.2.0 for sure.

3. If it's not Zoom tool (my least favorite of them), then in Time track, there is no possible target but the envelope.  But you can only edit the Time track in Envelope or Multi, which seems an unnecessary nuisance.  But then, any click edits this envelope, where in the Wave track you must click near the curve.

4. Envelope and cutlines and clip boundaries are invisible in spectrogram view.  You are prevented from editing them in Multi, but not in Envelope or Select tools.

So I propose instead these more consistent priorities, regardless which mouse button, even do-nothing right buttons (but, some dependency on modifier keys):
  • Between tracks, resizers always.  Otherwise, in tracks:
  • Zoom tool overrides all targets.  Otherwise, other tools:
  • MIDI stretch zone, Time track (only on the curve), cutline and clip boundary (if not spectrogram), in all tools.
  • Time-shifting of clips in Multi tool, when Ctrl is down.
  • Only if not spectrogram:  Samples in Draw or Multi, wave track envelopes in Envelope or Multi, and time shift grips, in Multi.  Unspecified priorities among these three in Multi.
  • Clips, or (with Shift key down) whole tracks, in Time-shift tool.
  • Right click to zoom in Multi, only in default of everything else.

Did I omit anything?

PRL



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Hit test inconsistencies

Paul Licameli


On Sun, Jun 18, 2017 at 4:37 PM, Paul Licameli <[hidden email]> wrote:
My track panel refactor took some pains to preserve some old inconsistencies in behavior, complicating the resulting code more than I like.  Perhaps it isn't worth it.  I think what I preserved was a pile of ad-hocs that did not reflect a deliberate design.

I refer to hit-testing matters and the interaction with the Tools toolbar.

(I think the Tools toolbar should be abolished.  I would like to allow multiple hit-test targets at the mouse position in any track, and let the TAB key cycle among candidates.  But that may be too much to try in 2.2.0.)

Can we agree on simple, consistent behavior?

1. Should "special" hit test targets take priority over the tool, or not?  For both buttons, always?  Or only for right button when the target does something?  I describe 2.1.3 behavior.
  • The resizer handle at the bottom of a track is available no matter what tool, for left click, but not for right click or drag in Multi which still does a zoom.
  • Cut-lines and clip boundaries in Wave tracks take priority in all tools and both buttons (except, see 4).  Right-click on cut-line to delete even takes priority over the zooming behavior in multi-tool.  Right-click and drag on a clip boundary does nothing in multi.
  • Label end handles take priority in all tools, though not when right-clicking in Multi.  They have no special right-click action.
  • Label text boxes have no preview cursor or status bar message, passing the default cursor and message for the tool, but take the left click (to edit) and right (for context menu) in all tools.  So I can see a magnifier cursor but still click to edit.
  • The hot-zone for stretching a Note track (at middle height in the selection) takes priority only in Select or Multi and is otherwise unavailable.
  • The grips for time-shift, at left and right edges in Multi, do not take the right click.
  • Other special wave track targets (envelope, samples) do not take priority over right click in Multi.
2. Should right clicks be reserved for context menus, as in many other applications?  Little loss if deletion of a cutline gets a bit more complicated.  Multi would lose the zoom-out, but that is redundant with Ctrl+3.  But this is post 2.2.0 for sure.

3. If it's not Zoom tool (my least favorite of them), then in Time track, there is no possible target but the envelope.  But you can only edit the Time track in Envelope or Multi, which seems an unnecessary nuisance.  But then, any click edits this envelope, where in the Wave track you must click near the curve.

4. Envelope and cutlines and clip boundaries are invisible in spectrogram view.  You are prevented from editing them in Multi, but not in Envelope or Select tools.

So I propose instead these more consistent priorities, regardless which mouse button, even do-nothing right buttons (but, some dependency on modifier keys):
  • Between tracks, resizers always.  Otherwise, in tracks:
  • Zoom tool overrides all targets.  Otherwise, other tools:
  • MIDI stretch zone, Time track (only on the curve), cutline and clip boundary (if not spectrogram), in all tools.
I forgot label grips and text boxes, so insert the here.
 
  • Time-shifting of clips in Multi tool, when Ctrl is down.
  • Only if not spectrogram:  Samples in Draw or Multi, wave track envelopes in Envelope or Multi, and time shift grips, in Multi.  Unspecified priorities among these three in Multi.
Insert here, edges of the selection box in Select tool, including spectral selection top, bottom, and center.
 
  • Clips, or (with Shift key down) whole tracks, in Time-shift tool.
Note that whole tracks of three kinds (not Time) can shift. 
  • Right click to zoom in Multi, only in default of everything else.

Did I omit anything?

PRL




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Hit test inconsistencies

James Crook
In reply to this post by Paul Licameli
On 6/18/2017 9:37 PM, Paul Licameli wrote:

> My track panel refactor took some pains to preserve some old
> inconsistencies in behavior, complicating the resulting code more than I
> like.  Perhaps it isn't worth it.  I think what I preserved was a pile of
> ad-hocs that did not reflect a deliberate design.
>
> I refer to hit-testing matters and the interaction with the Tools toolbar.
>
> (I think the Tools toolbar should be abolished.  I would like to allow
> multiple hit-test targets at the mouse position in any track, and let the
> TAB key cycle among candidates.  But that may be too much to try in 2.2.0.)
+1 on abolishing the Tools Toolbar.
With good design TAB key cycling should be unnecessary.
-1 on doing it for 2.2.0


> Can we agree on simple, consistent behavior?
>
> 1. Should "special" hit test targets take priority over the tool, or not?
> For both buttons, always?  Or only for right button when the target does
> something?  I describe 2.1.3 behavior.
>
>
>     - The resizer handle at the bottom of a track is available no matter
>     what tool, for left click, but not for right click or drag in Multi which
>     still does a zoom.
>     - Cut-lines and clip boundaries in Wave tracks take priority in all
>     tools and both buttons (except, see 4).  Right-click on cut-line to delete
>     even takes priority over the zooming behavior in multi-tool.  Right-click
>     and drag on a clip boundary does nothing in multi.
>     - Label end handles take priority in all tools, though not when
>     right-clicking in Multi.  They have no special right-click action.
>     - Label text boxes have no preview cursor or status bar message, passing
>     the default cursor and message for the tool, but take the left click (to
>     edit) and right (for context menu) in all tools.  So I can see a magnifier
>     cursor but still click to edit.
>     - The hot-zone for stretching a Note track (at middle height in the
>     selection) takes priority only in Select or Multi and is otherwise
>     unavailable.
>     - The grips for time-shift, at left and right edges in Multi, do not
>     take the right click.
>     - Other special wave track targets (envelope, samples) do not take
>     priority over right click in Multi.
>
> 2. Should right clicks be reserved for context menus, as in many other
> applications?
Yes.

> Little loss if deletion of a cutline gets a bit more
> complicated.  Multi would lose the zoom-out, but that is redundant with
> Ctrl+3.  But this is post 2.2.0 for sure.
>
> 3. If it's not Zoom tool (my least favorite of them), then in Time track,
> there is no possible target but the envelope.  But you can only edit the
> Time track in Envelope or Multi, which seems an unnecessary nuisance.  But
> then, any click edits this envelope, where in the Wave track you must click
> near the curve.
>
> 4. Envelope and cutlines and clip boundaries are invisible in spectrogram
> view.  You are prevented from editing them in Multi, but not in Envelope or
> Select tools.
>
> So I propose instead these more consistent priorities, regardless which
> mouse button, even do-nothing right buttons (but, some dependency on
> modifier keys):
>
>     - Between tracks, resizers always.  Otherwise, in tracks:
>     - Zoom tool overrides all targets.  Otherwise, other tools:
>     - MIDI stretch zone, Time track (only on the curve), cutline and clip
>     boundary (if not spectrogram), in all tools.
>     - Time-shifting of clips in Multi tool, when Ctrl is down.
>     - Only if not spectrogram:  Samples in Draw or Multi, wave track
>     envelopes in Envelope or Multi, and time shift grips, in Multi.
>     Unspecified priorities among these three in Multi.
>     - Clips, or (with Shift key down) whole tracks, in Time-shift tool.
>     - Right click to zoom in Multi, only in default of everything else.
>
>
> Did I omit anything?
I'd be inclined not to tidy it up for 2.2.0.  Rather go the whole hog,
and do abolishing Tools Toolbar for 2.2.1.  It should be less work as
you are then only supporting one tool mode.  It would also be easier for
us to understand and visualise what we are getting. The first step in
2.2.1 would be to make Multi-Tool do that tool mode, then when we are
happy it makes sense to use it always, abolish ToolsToolbar.

IF team are against a rapid abolition of ToolsToolbar, I was planning to
do it sometime in Dark Audacity.  So that's an option if we want to play
it cautiously in Audacity itself.

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Hit test inconsistencies

Paul Licameli


On Sun, Jun 18, 2017 at 5:36 PM, James Crook <[hidden email]> wrote:
On 6/18/2017 9:37 PM, Paul Licameli wrote:
My track panel refactor took some pains to preserve some old
inconsistencies in behavior, complicating the resulting code more than I
like.  Perhaps it isn't worth it.  I think what I preserved was a pile of
ad-hocs that did not reflect a deliberate design.

I refer to hit-testing matters and the interaction with the Tools toolbar.

(I think the Tools toolbar should be abolished.  I would like to allow
multiple hit-test targets at the mouse position in any track, and let the
TAB key cycle among candidates.  But that may be too much to try in 2.2.0.)
+1 on abolishing the Tools Toolbar.
With good design TAB key cycling should be unnecessary.
-1 on doing it for 2.2.0 

I don't know what you have in mind for disambiguating hit targets that are near each other, if not a special key.  I think TAB makes sense, as a key often used for cycling through choices, and one we can't otherwise reassign in Keyboard preferences.

(An anecdote about the 3d CAD system I worked on decades ago.  The hit test problem in 3D is much more complicated.  Shoot a ray, or narrow cylinder, through the geometric model, and order candidate curves and surfaces that it intersects.  There were 3-button mice, and as I recall you selected by first right-clicking to enter special selection, then left-clicking at a point on the screen, then right-clicking to cycle through candidates, then middle clicking when the one you wanted was highlighted.)

I should mention that I also may want to do projects that enlarge the number of hit test candidates, such as by overlapping clips at one time, and adding cross-fade zones at the ends with some sort of adjustable handles.

I do not want to put the TAB key cycling into 2.2.0, but I may want to do things that smooth the way for it.

As I said, the Zoom tool is my least favorite part of the Tools toolbar, but it seems to be the special tool that ought to remain as a mode of its own, if it does remain, while all others are collapsed into one.  Every other tool but Zoom exists to pick some thing on the screen and do something to that thing.
 


Can we agree on simple, consistent behavior?

1. Should "special" hit test targets take priority over the tool, or not?
For both buttons, always?  Or only for right button when the target does
something?  I describe 2.1.3 behavior.


    - The resizer handle at the bottom of a track is available no matter
    what tool, for left click, but not for right click or drag in Multi which
    still does a zoom.
    - Cut-lines and clip boundaries in Wave tracks take priority in all
    tools and both buttons (except, see 4).  Right-click on cut-line to delete
    even takes priority over the zooming behavior in multi-tool.  Right-click
    and drag on a clip boundary does nothing in multi.
    - Label end handles take priority in all tools, though not when
    right-clicking in Multi.  They have no special right-click action.
    - Label text boxes have no preview cursor or status bar message, passing
    the default cursor and message for the tool, but take the left click (to
    edit) and right (for context menu) in all tools.  So I can see a magnifier
    cursor but still click to edit.
    - The hot-zone for stretching a Note track (at middle height in the
    selection) takes priority only in Select or Multi and is otherwise
    unavailable.
    - The grips for time-shift, at left and right edges in Multi, do not
    take the right click.
    - Other special wave track targets (envelope, samples) do not take
    priority over right click in Multi.

2. Should right clicks be reserved for context menus, as in many other
applications?
Yes.

Very well.  I think they are not hard to do in principle, but we might have difficulty agreeing on just what should go into them.
 
Little loss if deletion of a cutline gets a bit more
complicated.  Multi would lose the zoom-out, but that is redundant with
Ctrl+3.  But this is post 2.2.0 for sure.

3. If it's not Zoom tool (my least favorite of them), then in Time track,
there is no possible target but the envelope.  But you can only edit the
Time track in Envelope or Multi, which seems an unnecessary nuisance.  But
then, any click edits this envelope, where in the Wave track you must click
near the curve.

4. Envelope and cutlines and clip boundaries are invisible in spectrogram
view.  You are prevented from editing them in Multi, but not in Envelope or
Select tools.

So I propose instead these more consistent priorities, regardless which
mouse button, even do-nothing right buttons (but, some dependency on
modifier keys):

    - Between tracks, resizers always.  Otherwise, in tracks:
    - Zoom tool overrides all targets.  Otherwise, other tools:
    - MIDI stretch zone, Time track (only on the curve), cutline and clip
    boundary (if not spectrogram), in all tools.
    - Time-shifting of clips in Multi tool, when Ctrl is down.
    - Only if not spectrogram:  Samples in Draw or Multi, wave track
    envelopes in Envelope or Multi, and time shift grips, in Multi.
    Unspecified priorities among these three in Multi.
    - Clips, or (with Shift key down) whole tracks, in Time-shift tool.
    - Right click to zoom in Multi, only in default of everything else.


Did I omit anything?
I'd be inclined not to tidy it up for 2.2.0.  Rather go the whole hog, and do abolishing Tools Toolbar for 2.2.1.

I disagree.  I am not satisfied with the tidying so far, and these further tidyings will be pleasing to do, if only there is agreement on the details of hit test priorities, which I want to change as described, leaving the Tools bar alone.  I have not yet read any specific objection to these details.

Because, it would make the various HitTest overrides for the various track types much simpler, reading more like a simple list of things, rather than preserving some odd cases as now.

Something more suited then to rewriting in a tabular, interpreted form, which is the better form for easier extension in the future, and more suited to extensions by "plug-in" as I understand that ideal.

I also want to attempt something for more mouse-over highlighting, such as is now done only for label handles.  That demanded first a reexamination of hit test.

PRL
 
It should be less work as you are then only supporting one tool mode.  It would also be easier for us to understand and visualise what we are getting. The first step in 2.2.1 would be to make Multi-Tool do that tool mode, then when we are happy it makes sense to use it always, abolish ToolsToolbar.

IF team are against a rapid abolition of ToolsToolbar, I was planning to do it sometime in Dark Audacity.  So that's an option if we want to play it cautiously in Audacity itself.

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Hit test inconsistencies

James Crook
On 6/19/2017 12:03 AM, Paul Licameli wrote:
On Sun, Jun 18, 2017 at 5:36 PM, James Crook [hidden email] wrote:

On 6/18/2017 9:37 PM, Paul Licameli wrote:

My track panel refactor took some pains to preserve some old
inconsistencies in behavior, complicating the resulting code more than I
like.  Perhaps it isn't worth it.  I think what I preserved was a pile of
ad-hocs that did not reflect a deliberate design.

I refer to hit-testing matters and the interaction with the Tools toolbar.

(I think the Tools toolbar should be abolished.  I would like to allow
multiple hit-test targets at the mouse position in any track, and let the
TAB key cycle among candidates.  But that may be too much to try in
2.2.0.)

+1 on abolishing the Tools Toolbar.
With good design TAB key cycling should be unnecessary.
-1 on doing it for 2.2.0

I don't know what you have in mind for disambiguating hit targets that are
near each other, if not a special key.  I think TAB makes sense, as a key
often used for cycling through choices, and one we can't otherwise reassign
in Keyboard preferences.
As we don't have a 3D model, we can actually design in such a way that the draggable things either don't overlap, or when they do it is very easy and obvious to the user what to do to work around the overlap.   For example a lot of envelope manipulation can be done zoomed out enough that samples are not shown or draggable.

(An anecdote about the 3d CAD system I worked on decades ago.  The hit test
problem in 3D is much more complicated.  Shoot a ray, or narrow cylinder,
through the geometric model, and order candidate curves and surfaces that
it intersects.  There were 3-button mice, and as I recall you selected by
first right-clicking to enter special selection, then left-clicking at a
point on the screen, then right-clicking to cycle through candidates, then
middle clicking when the one you wanted was highlighted.)
TAB isn't  a bad key for last-ditch resolution of overlap.  One design idea is for tab to place icons for the draggable things in a circle around the point, which can then be chosen from.  Another design possibility, that I like because of its discoverability, is for the right click context menu to have a dynamic submenu for nearby objects.

I should mention that I also may want to do projects that enlarge the
number of hit test candidates, such as by overlapping clips at one time,
and adding cross-fade zones at the ends with some sort of adjustable
handles.

I do not want to put the TAB key cycling into 2.2.0, but I may want to do
things that smooth the way for it.

As I said, the Zoom tool is my least favorite part of the Tools toolbar,
but it seems to be the special tool that ought to remain as a mode of its
own, if it does remain, while all others are collapsed into one.  Every
other tool but Zoom exists to pick some thing on the screen and do
something to that thing.
Peter is keen on us improving the zoom buttons on the edit toolbar and splitting them off as a new zoom-toolbar.  If we do, we can reinstate zoom-toggle, which I added and still miss.  Possibly multibuttons to make them configurable will save us from drowning in zoom buttons.

I'm also planning for DA to introduce the zoom-ruler that I demoed in AU14 TrackPanel.  That eliminates the need for a Zoom tool.  It also removes the need for a horizontal scrollbar.  The ideas behind Quick Play would move to the label track to free up that space, at the same time allowing multiple quick-play regions.



Can we agree on simple, consistent behavior?
1. Should "special" hit test targets take priority over the tool, or not?
For both buttons, always?  Or only for right button when the target does
something?  I describe 2.1.3 behavior.


    - The resizer handle at the bottom of a track is available no matter
    what tool, for left click, but not for right click or drag in Multi
which
    still does a zoom.
    - Cut-lines and clip boundaries in Wave tracks take priority in all
    tools and both buttons (except, see 4).  Right-click on cut-line to
delete
    even takes priority over the zooming behavior in multi-tool.
Right-click
    and drag on a clip boundary does nothing in multi.
    - Label end handles take priority in all tools, though not when
    right-clicking in Multi.  They have no special right-click action.
    - Label text boxes have no preview cursor or status bar message,
passing
    the default cursor and message for the tool, but take the left click
(to
    edit) and right (for context menu) in all tools.  So I can see a
magnifier
    cursor but still click to edit.
    - The hot-zone for stretching a Note track (at middle height in the
    selection) takes priority only in Select or Multi and is otherwise
    unavailable.
    - The grips for time-shift, at left and right edges in Multi, do not
    take the right click.
    - Other special wave track targets (envelope, samples) do not take
    priority over right click in Multi.

2. Should right clicks be reserved for context menus, as in many other
applications?

Yes.

Very well.  I think they are not hard to do in principle, but we might have
difficulty agreeing on just what should go into them.
The tricky bit is deciding/agreeing what happens to existing right-clicks.


Little loss if deletion of a cutline gets a bit more
complicated.  Multi would lose the zoom-out, but that is redundant with
Ctrl+3.  But this is post 2.2.0 for sure.

3. If it's not Zoom tool (my least favorite of them), then in Time track,
there is no possible target but the envelope.  But you can only edit the
Time track in Envelope or Multi, which seems an unnecessary nuisance.  But
then, any click edits this envelope, where in the Wave track you must
click
near the curve.

4. Envelope and cutlines and clip boundaries are invisible in spectrogram
view.  You are prevented from editing them in Multi, but not in Envelope
or
Select tools.

So I propose instead these more consistent priorities, regardless which
mouse button, even do-nothing right buttons (but, some dependency on
modifier keys):

    - Between tracks, resizers always.  Otherwise, in tracks:
    - Zoom tool overrides all targets.  Otherwise, other tools:
    - MIDI stretch zone, Time track (only on the curve), cutline and clip
    boundary (if not spectrogram), in all tools.
    - Time-shifting of clips in Multi tool, when Ctrl is down.
    - Only if not spectrogram:  Samples in Draw or Multi, wave track
    envelopes in Envelope or Multi, and time shift grips, in Multi.
    Unspecified priorities among these three in Multi.
    - Clips, or (with Shift key down) whole tracks, in Time-shift tool.
    - Right click to zoom in Multi, only in default of everything else.


Did I omit anything?

I'd be inclined not to tidy it up for 2.2.0.  Rather go the whole hog, and
do abolishing Tools Toolbar for 2.2.1.
I disagree.  I am not satisfied with the tidying so far, and these further
tidyings will be pleasing to do, if only there is agreement on the details
of hit test priorities, which I want to change as described, leaving the
Tools bar alone.  I have not yet read any specific objection to these
details.
I certainly don't object.  Far from it.  I am just on the look out for ways to reduce the overall work.  If you're keen to do work that may only show for one version, and that makes Audacity more logical, the only reason for caution is if it could be more work than you are banking on.  We currently don't in the manual document the details of what trumps what, so changing it does not imply extra work in the manual to update it to the new scheme.

Because, it would make the various HitTest overrides for the various track
types much simpler, reading more like a simple list of things, rather than
preserving some odd cases as now.
Sounds good.  And maybe team will in any case take a very very long time to agree to actually removing the tools toolbar rather than the less extreme turning it off by default.
Something more suited then to rewriting in a tabular, interpreted form,
which is the better form for easier extension in the future, and more
suited to extensions by "plug-in" as I understand that ideal.
Got it.

You might be interested that an earlier version of multi-tool allowed multiple tools to be active at the same time, e.g. you could enable draw and selection tool by pushing those buttons down and not envelope tool.  It worked, but was deemed too complex for users.


I also want to attempt something for more mouse-over highlighting, such as
is now done only for label handles.  That demanded first a reexamination of
hit test.
That would be very good.



PRL


It should be less work as you are then only supporting one tool mode.  It
would also be easier for us to understand and visualise what we are
getting. The first step in 2.2.1 would be to make Multi-Tool do that tool
mode, then when we are happy it makes sense to use it always, abolish
ToolsToolbar.

IF team are against a rapid abolition of ToolsToolbar, I was planning to
do it sometime in Dark Audacity.  So that's an option if we want to play it
cautiously in Audacity itself.

--James.


------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


      

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Hit test inconsistencies

Paul Licameli


On Mon, Jun 19, 2017 at 5:33 AM, James Crook <[hidden email]> wrote:
On 6/19/2017 12:03 AM, Paul Licameli wrote:
On Sun, Jun 18, 2017 at 5:36 PM, James Crook [hidden email] wrote:

On 6/18/2017 9:37 PM, Paul Licameli wrote:

My track panel refactor took some pains to preserve some old
inconsistencies in behavior, complicating the resulting code more than I
like.  Perhaps it isn't worth it.  I think what I preserved was a pile of
ad-hocs that did not reflect a deliberate design.

I refer to hit-testing matters and the interaction with the Tools toolbar.

(I think the Tools toolbar should be abolished.  I would like to allow
multiple hit-test targets at the mouse position in any track, and let the
TAB key cycle among candidates.  But that may be too much to try in
2.2.0.)

+1 on abolishing the Tools Toolbar.
With good design TAB key cycling should be unnecessary.
-1 on doing it for 2.2.0
I don't know what you have in mind for disambiguating hit targets that are
near each other, if not a special key.  I think TAB makes sense, as a key
often used for cycling through choices, and one we can't otherwise reassign
in Keyboard preferences.
As we don't have a 3D model, we can actually design in such a way that the draggable things either don't overlap, or when they do it is very easy and obvious to the user what to do to work around the overlap.   For example a lot of envelope manipulation can be done zoomed out enough that samples are not shown or draggable.

(An anecdote about the 3d CAD system I worked on decades ago.  The hit test
problem in 3D is much more complicated.  Shoot a ray, or narrow cylinder,
through the geometric model, and order candidate curves and surfaces that
it intersects.  There were 3-button mice, and as I recall you selected by
first right-clicking to enter special selection, then left-clicking at a
point on the screen, then right-clicking to cycle through candidates, then
middle clicking when the one you wanted was highlighted.)
TAB isn't  a bad key for last-ditch resolution of overlap.  One design idea is for tab to place icons for the draggable things in a circle around the point, which can then be chosen from.  Another design possibility, that I like because of its discoverability, is for the right click context menu to have a dynamic submenu for nearby objects.

I should mention that I also may want to do projects that enlarge the
number of hit test candidates, such as by overlapping clips at one time,
and adding cross-fade zones at the ends with some sort of adjustable
handles.

I do not want to put the TAB key cycling into 2.2.0, but I may want to do
things that smooth the way for it.

As I said, the Zoom tool is my least favorite part of the Tools toolbar,
but it seems to be the special tool that ought to remain as a mode of its
own, if it does remain, while all others are collapsed into one.  Every
other tool but Zoom exists to pick some thing on the screen and do
something to that thing.
Peter is keen on us improving the zoom buttons on the edit toolbar and splitting them off as a new zoom-toolbar.  If we do, we can reinstate zoom-toggle, which I added and still miss.  Possibly multibuttons to make them configurable will save us from drowning in zoom buttons.

I'm also planning for DA to introduce the zoom-ruler that I demoed in AU14 TrackPanel.  That eliminates the need for a Zoom tool.  It also removes the need for a horizontal scrollbar.  The ideas behind Quick Play would move to the label track to free up that space, at the same time allowing multiple quick-play regions.




Can we agree on simple, consistent behavior?
1. Should "special" hit test targets take priority over the tool, or not?
For both buttons, always?  Or only for right button when the target does
something?  I describe 2.1.3 behavior.


    - The resizer handle at the bottom of a track is available no matter
    what tool, for left click, but not for right click or drag in Multi
which
    still does a zoom.
    - Cut-lines and clip boundaries in Wave tracks take priority in all
    tools and both buttons (except, see 4).  Right-click on cut-line to
delete
    even takes priority over the zooming behavior in multi-tool.
Right-click
    and drag on a clip boundary does nothing in multi.
    - Label end handles take priority in all tools, though not when
    right-clicking in Multi.  They have no special right-click action.
    - Label text boxes have no preview cursor or status bar message,
passing
    the default cursor and message for the tool, but take the left click
(to
    edit) and right (for context menu) in all tools.  So I can see a
magnifier
    cursor but still click to edit.
    - The hot-zone for stretching a Note track (at middle height in the
    selection) takes priority only in Select or Multi and is otherwise
    unavailable.
    - The grips for time-shift, at left and right edges in Multi, do not
    take the right click.
    - Other special wave track targets (envelope, samples) do not take
    priority over right click in Multi.

2. Should right clicks be reserved for context menus, as in many other
applications?

Yes.

Very well.  I think they are not hard to do in principle, but we might have
difficulty agreeing on just what should go into them.
The tricky bit is deciding/agreeing what happens to existing right-clicks.

Considering the proper track areas only, right clicks are very few now.  Right click on label text boxes which already does what we want to generalize.  That leaves utline deletion (and how popular is this cutline thing anyway?), the zooming part of multi-tool.  As I said I don't think those will be missed.  The first becomes an item in a context menu instead, 

Steve objected to repurposing the right-click in vertical rulers for context menus when I attempted that in 2.1.2.  I did not not press the argument, then.  But I still believe it ought to be done in future if we put context menus everywhere as I think we ought.

PRL

 



Little loss if deletion of a cutline gets a bit more
complicated.  Multi would lose the zoom-out, but that is redundant with
Ctrl+3.  But this is post 2.2.0 for sure.

3. If it's not Zoom tool (my least favorite of them), then in Time track,
there is no possible target but the envelope.  But you can only edit the
Time track in Envelope or Multi, which seems an unnecessary nuisance.  But
then, any click edits this envelope, where in the Wave track you must
click
near the curve.

4. Envelope and cutlines and clip boundaries are invisible in spectrogram
view.  You are prevented from editing them in Multi, but not in Envelope
or
Select tools.

So I propose instead these more consistent priorities, regardless which
mouse button, even do-nothing right buttons (but, some dependency on
modifier keys):

    - Between tracks, resizers always.  Otherwise, in tracks:
    - Zoom tool overrides all targets.  Otherwise, other tools:
    - MIDI stretch zone, Time track (only on the curve), cutline and clip
    boundary (if not spectrogram), in all tools.
    - Time-shifting of clips in Multi tool, when Ctrl is down.
    - Only if not spectrogram:  Samples in Draw or Multi, wave track
    envelopes in Envelope or Multi, and time shift grips, in Multi.
    Unspecified priorities among these three in Multi.
    - Clips, or (with Shift key down) whole tracks, in Time-shift tool.
    - Right click to zoom in Multi, only in default of everything else.


Did I omit anything?

I'd be inclined not to tidy it up for 2.2.0.  Rather go the whole hog, and
do abolishing Tools Toolbar for 2.2.1.
I disagree.  I am not satisfied with the tidying so far, and these further
tidyings will be pleasing to do, if only there is agreement on the details
of hit test priorities, which I want to change as described, leaving the
Tools bar alone.  I have not yet read any specific objection to these
details.
I certainly don't object.  Far from it.  I am just on the look out for ways to reduce the overall work.  If you're keen to do work that may only show for one version, and that makes Audacity more logical, the only reason for caution is if it could be more work than you are banking on.  We currently don't in the manual document the details of what trumps what, so changing it does not imply extra work in the manual to update it to the new scheme.

Because, it would make the various HitTest overrides for the various track
types much simpler, reading more like a simple list of things, rather than
preserving some odd cases as now.
Sounds good.  And maybe team will in any case take a very very long time to agree to actually removing the tools toolbar rather than the less extreme turning it off by default.
Something more suited then to rewriting in a tabular, interpreted form,
which is the better form for easier extension in the future, and more
suited to extensions by "plug-in" as I understand that ideal.
Got it.

You might be interested that an earlier version of multi-tool allowed multiple tools to be active at the same time, e.g. you could enable draw and selection tool by pushing those buttons down and not envelope tool.  It worked, but was deemed too complex for users.


I also want to attempt something for more mouse-over highlighting, such as
is now done only for label handles.  That demanded first a reexamination of
hit test.
That would be very good.



PRL


It should be less work as you are then only supporting one tool mode.  It
would also be easier for us to understand and visualise what we are
getting. The first step in 2.2.1 would be to make Multi-Tool do that tool
mode, then when we are happy it makes sense to use it always, abolish
ToolsToolbar.

IF team are against a rapid abolition of ToolsToolbar, I was planning to
do it sometime in Dark Audacity.  So that's an option if we want to play it
cautiously in Audacity itself.

--James.


------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


      

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Hit test inconsistencies

James Crook
In reply to this post by Paul Licameli


On 6/19/2017 5:30 PM, Paul Licameli wrote:

> On Mon, Jun 19, 2017 at 5:33 AM, James Crook <[hidden email]> wrote:
>
>> On 6/19/2017 12:03 AM, Paul Licameli wrote:
>>
>> On Sun, Jun 18, 2017 at 5:36 PM, James Crook <[hidden email]> <[hidden email]> wrote:
>>
>>
>> On 6/18/2017 9:37 PM, Paul Licameli wrote:
>>
>>
>> My track panel refactor took some pains to preserve some old
>> inconsistencies in behavior, complicating the resulting code more than I
>> like.  Perhaps it isn't worth it.  I think what I preserved was a pile of
>> ad-hocs that did not reflect a deliberate design.
>>
>> I refer to hit-testing matters and the interaction with the Tools toolbar.
>>
>> (I think the Tools toolbar should be abolished.  I would like to allow
>> multiple hit-test targets at the mouse position in any track, and let the
>> TAB key cycle among candidates.  But that may be too much to try in
>> 2.2.0.)
>>
>>
>> +1 on abolishing the Tools Toolbar.
>> With good design TAB key cycling should be unnecessary.
>> -1 on doing it for 2.2.0
>>
>> I don't know what you have in mind for disambiguating hit targets that are
>> near each other, if not a special key.  I think TAB makes sense, as a key
>> often used for cycling through choices, and one we can't otherwise reassign
>> in Keyboard preferences.
>>
>> As we don't have a 3D model, we can actually design in such a way that the
>> draggable things either don't overlap, or when they do it is very easy and
>> obvious to the user what to do to work around the overlap.   For example a
>> lot of envelope manipulation can be done zoomed out enough that samples are
>> not shown or draggable.
>>
>> (An anecdote about the 3d CAD system I worked on decades ago.  The hit test
>> problem in 3D is much more complicated.  Shoot a ray, or narrow cylinder,
>> through the geometric model, and order candidate curves and surfaces that
>> it intersects.  There were 3-button mice, and as I recall you selected by
>> first right-clicking to enter special selection, then left-clicking at a
>> point on the screen, then right-clicking to cycle through candidates, then
>> middle clicking when the one you wanted was highlighted.)
>>
>> TAB isn't  a bad key for last-ditch resolution of overlap.  One design
>> idea is for tab to place icons for the draggable things in a circle around
>> the point, which can then be chosen from.  Another design possibility, that
>> I like because of its discoverability, is for the right click context menu
>> to have a dynamic submenu for nearby objects.
>>
>> I should mention that I also may want to do projects that enlarge the
>> number of hit test candidates, such as by overlapping clips at one time,
>> and adding cross-fade zones at the ends with some sort of adjustable
>> handles.
>>
>> I do not want to put the TAB key cycling into 2.2.0, but I may want to do
>> things that smooth the way for it.
>>
>> As I said, the Zoom tool is my least favorite part of the Tools toolbar,
>> but it seems to be the special tool that ought to remain as a mode of its
>> own, if it does remain, while all others are collapsed into one.  Every
>> other tool but Zoom exists to pick some thing on the screen and do
>> something to that thing.
>>
>> Peter is keen on us improving the zoom buttons on the edit toolbar and
>> splitting them off as a new zoom-toolbar.  If we do, we can reinstate
>> zoom-toggle, which I added and still miss.  Possibly multibuttons to make
>> them configurable will save us from drowning in zoom buttons.
>>
>> I'm also planning for DA to introduce the zoom-ruler that I demoed in AU14
>> TrackPanel.  That eliminates the need for a Zoom tool.  It also removes the
>> need for a horizontal scrollbar.  The ideas behind Quick Play would move to
>> the label track to free up that space, at the same time allowing multiple
>> quick-play regions.
>>
>>
>>
>>
>> Can we agree on simple, consistent behavior?
>>
>> 1. Should "special" hit test targets take priority over the tool, or not?
>> For both buttons, always?  Or only for right button when the target does
>> something?  I describe 2.1.3 behavior.
>>
>>
>>      - The resizer handle at the bottom of a track is available no matter
>>      what tool, for left click, but not for right click or drag in Multi
>> which
>>      still does a zoom.
>>      - Cut-lines and clip boundaries in Wave tracks take priority in all
>>      tools and both buttons (except, see 4).  Right-click on cut-line to
>> delete
>>      even takes priority over the zooming behavior in multi-tool.
>> Right-click
>>      and drag on a clip boundary does nothing in multi.
>>      - Label end handles take priority in all tools, though not when
>>      right-clicking in Multi.  They have no special right-click action.
>>      - Label text boxes have no preview cursor or status bar message,
>> passing
>>      the default cursor and message for the tool, but take the left click
>> (to
>>      edit) and right (for context menu) in all tools.  So I can see a
>> magnifier
>>      cursor but still click to edit.
>>      - The hot-zone for stretching a Note track (at middle height in the
>>      selection) takes priority only in Select or Multi and is otherwise
>>      unavailable.
>>      - The grips for time-shift, at left and right edges in Multi, do not
>>      take the right click.
>>      - Other special wave track targets (envelope, samples) do not take
>>      priority over right click in Multi.
>>
>> 2. Should right clicks be reserved for context menus, as in many other
>> applications?
>>
>>
>> Yes.
>>
>>
>> Very well.  I think they are not hard to do in principle, but we might have
>> difficulty agreeing on just what should go into them.
>>
>> The tricky bit is deciding/agreeing what happens to existing right-clicks.
>>
> Considering the proper track areas only, right clicks are very few now.
> Right click on label text boxes which already does what we want to
> generalize.  That leaves utline deletion (and how popular is this cutline
> thing anyway?), the zooming part of multi-tool.  As I said I don't think
> those will be missed.  The first becomes an item in a context menu instead,
>
> Steve objected to repurposing the right-click in vertical rulers for
> context menus when I attempted that in 2.1.2.  I did not not press the
> argument, then.  But I still believe it ought to be done in future if we
> put context menus everywhere as I think we ought.
Should be an easy argument, since my impression is that right-click
currently does same as left-click there.  With 2.2.0 we've got a lot
bolder about making significant GUI changes, so I would expect it to
(now) be not too hard to convince Steve with something more concrete and
a clear path to greater consistency in the GUI.

--James.



>
> PRL
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Hit test inconsistencies

Paul Licameli


On Mon, Jun 19, 2017 at 1:23 PM, James Crook <[hidden email]> wrote:


On 6/19/2017 5:30 PM, Paul Licameli wrote:
On Mon, Jun 19, 2017 at 5:33 AM, James Crook <[hidden email]> wrote:

On 6/19/2017 12:03 AM, Paul Licameli wrote:

On Sun, Jun 18, 2017 at 5:36 PM, James Crook <[hidden email]> <[hidden email]> wrote:


On 6/18/2017 9:37 PM, Paul Licameli wrote:


My track panel refactor took some pains to preserve some old
inconsistencies in behavior, complicating the resulting code more than I
like.  Perhaps it isn't worth it.  I think what I preserved was a pile of
ad-hocs that did not reflect a deliberate design.

I refer to hit-testing matters and the interaction with the Tools toolbar.

(I think the Tools toolbar should be abolished.  I would like to allow
multiple hit-test targets at the mouse position in any track, and let the
TAB key cycle among candidates.  But that may be too much to try in
2.2.0.)


+1 on abolishing the Tools Toolbar.
With good design TAB key cycling should be unnecessary.
-1 on doing it for 2.2.0

I don't know what you have in mind for disambiguating hit targets that are
near each other, if not a special key.  I think TAB makes sense, as a key
often used for cycling through choices, and one we can't otherwise reassign
in Keyboard preferences.

As we don't have a 3D model, we can actually design in such a way that the
draggable things either don't overlap, or when they do it is very easy and
obvious to the user what to do to work around the overlap.   For example a
lot of envelope manipulation can be done zoomed out enough that samples are
not shown or draggable.

(An anecdote about the 3d CAD system I worked on decades ago.  The hit test
problem in 3D is much more complicated.  Shoot a ray, or narrow cylinder,
through the geometric model, and order candidate curves and surfaces that
it intersects.  There were 3-button mice, and as I recall you selected by
first right-clicking to enter special selection, then left-clicking at a
point on the screen, then right-clicking to cycle through candidates, then
middle clicking when the one you wanted was highlighted.)

TAB isn't  a bad key for last-ditch resolution of overlap.  One design
idea is for tab to place icons for the draggable things in a circle around
the point, which can then be chosen from.  Another design possibility, that
I like because of its discoverability, is for the right click context menu
to have a dynamic submenu for nearby objects.

I should mention that I also may want to do projects that enlarge the
number of hit test candidates, such as by overlapping clips at one time,
and adding cross-fade zones at the ends with some sort of adjustable
handles.

I do not want to put the TAB key cycling into 2.2.0, but I may want to do
things that smooth the way for it.

As I said, the Zoom tool is my least favorite part of the Tools toolbar,
but it seems to be the special tool that ought to remain as a mode of its
own, if it does remain, while all others are collapsed into one.  Every
other tool but Zoom exists to pick some thing on the screen and do
something to that thing.

Peter is keen on us improving the zoom buttons on the edit toolbar and
splitting them off as a new zoom-toolbar.  If we do, we can reinstate
zoom-toggle, which I added and still miss.  Possibly multibuttons to make
them configurable will save us from drowning in zoom buttons.

I'm also planning for DA to introduce the zoom-ruler that I demoed in AU14
TrackPanel.  That eliminates the need for a Zoom tool.  It also removes the
need for a horizontal scrollbar.  The ideas behind Quick Play would move to
the label track to free up that space, at the same time allowing multiple
quick-play regions.




Can we agree on simple, consistent behavior?

1. Should "special" hit test targets take priority over the tool, or not?
For both buttons, always?  Or only for right button when the target does
something?  I describe 2.1.3 behavior.


     - The resizer handle at the bottom of a track is available no matter
     what tool, for left click, but not for right click or drag in Multi
which
     still does a zoom.
     - Cut-lines and clip boundaries in Wave tracks take priority in all
     tools and both buttons (except, see 4).  Right-click on cut-line to
delete
     even takes priority over the zooming behavior in multi-tool.
Right-click
     and drag on a clip boundary does nothing in multi.
     - Label end handles take priority in all tools, though not when
     right-clicking in Multi.  They have no special right-click action.
     - Label text boxes have no preview cursor or status bar message,
passing
     the default cursor and message for the tool, but take the left click
(to
     edit) and right (for context menu) in all tools.  So I can see a
magnifier
     cursor but still click to edit.
     - The hot-zone for stretching a Note track (at middle height in the
     selection) takes priority only in Select or Multi and is otherwise
     unavailable.
     - The grips for time-shift, at left and right edges in Multi, do not
     take the right click.
     - Other special wave track targets (envelope, samples) do not take
     priority over right click in Multi.

2. Should right clicks be reserved for context menus, as in many other
applications?


Yes.


Very well.  I think they are not hard to do in principle, but we might have
difficulty agreeing on just what should go into them.

The tricky bit is deciding/agreeing what happens to existing right-clicks.

Considering the proper track areas only, right clicks are very few now.
Right click on label text boxes which already does what we want to
generalize.  That leaves utline deletion (and how popular is this cutline
thing anyway?), the zooming part of multi-tool.  As I said I don't think
those will be missed.  The first becomes an item in a context menu instead,

Steve objected to repurposing the right-click in vertical rulers for
context menus when I attempted that in 2.1.2.  I did not not press the
argument, then.  But I still believe it ought to be done in future if we
put context menus everywhere as I think we ought.
Should be an easy argument, since my impression is that right-click
currently does same as left-click there.  With 2.2.0 we've got a lot
bolder about making significant GUI changes, so I would expect it to
(now) be not too hard to convince Steve with something more concrete and
a clear path to greater consistency in the GUI.

--James.

Scan the code for the few calls to RightUp()

Right clicks and drags zoom out, left, in.

It is also so for NoteTrack, though NoteTrack does not implement all that WaveTrack does, such as shift+right click or mousewheel actions.  I think that deserves to be made consistent, but it's a low priority.

PRL

 




PRL




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Hit test inconsistencies

Stevethefiddle
In reply to this post by James Crook
On 19 June 2017 at 18:23, James Crook <[hidden email]> wrote:

>
>
> On 6/19/2017 5:30 PM, Paul Licameli wrote:
>>
>> On Mon, Jun 19, 2017 at 5:33 AM, James Crook <[hidden email]> wrote:
>>
>>> On 6/19/2017 12:03 AM, Paul Licameli wrote:
>>>
>>> On Sun, Jun 18, 2017 at 5:36 PM, James Crook <[hidden email]>
>>> <[hidden email]> wrote:
>>>
>>>
>>> On 6/18/2017 9:37 PM, Paul Licameli wrote:
>>>
>>>
>>> My track panel refactor took some pains to preserve some old
>>> inconsistencies in behavior, complicating the resulting code more than I
>>> like.  Perhaps it isn't worth it.  I think what I preserved was a pile of
>>> ad-hocs that did not reflect a deliberate design.
>>>
>>> I refer to hit-testing matters and the interaction with the Tools
>>> toolbar.
>>>
>>> (I think the Tools toolbar should be abolished.  I would like to allow
>>> multiple hit-test targets at the mouse position in any track, and let the
>>> TAB key cycle among candidates.  But that may be too much to try in
>>> 2.2.0.)
>>>
>>>
>>> +1 on abolishing the Tools Toolbar.
>>> With good design TAB key cycling should be unnecessary.
>>> -1 on doing it for 2.2.0
>>>
>>> I don't know what you have in mind for disambiguating hit targets that
>>> are
>>> near each other, if not a special key.  I think TAB makes sense, as a key
>>> often used for cycling through choices, and one we can't otherwise
>>> reassign
>>> in Keyboard preferences.
>>>
>>> As we don't have a 3D model, we can actually design in such a way that
>>> the
>>> draggable things either don't overlap, or when they do it is very easy
>>> and
>>> obvious to the user what to do to work around the overlap.   For example
>>> a
>>> lot of envelope manipulation can be done zoomed out enough that samples
>>> are
>>> not shown or draggable.
>>>
>>> (An anecdote about the 3d CAD system I worked on decades ago.  The hit
>>> test
>>> problem in 3D is much more complicated.  Shoot a ray, or narrow cylinder,
>>> through the geometric model, and order candidate curves and surfaces that
>>> it intersects.  There were 3-button mice, and as I recall you selected by
>>> first right-clicking to enter special selection, then left-clicking at a
>>> point on the screen, then right-clicking to cycle through candidates,
>>> then
>>> middle clicking when the one you wanted was highlighted.)
>>>
>>> TAB isn't  a bad key for last-ditch resolution of overlap.  One design
>>> idea is for tab to place icons for the draggable things in a circle
>>> around
>>> the point, which can then be chosen from.  Another design possibility,
>>> that
>>> I like because of its discoverability, is for the right click context
>>> menu
>>> to have a dynamic submenu for nearby objects.
>>>
>>> I should mention that I also may want to do projects that enlarge the
>>> number of hit test candidates, such as by overlapping clips at one time,
>>> and adding cross-fade zones at the ends with some sort of adjustable
>>> handles.
>>>
>>> I do not want to put the TAB key cycling into 2.2.0, but I may want to do
>>> things that smooth the way for it.
>>>
>>> As I said, the Zoom tool is my least favorite part of the Tools toolbar,
>>> but it seems to be the special tool that ought to remain as a mode of its
>>> own, if it does remain, while all others are collapsed into one.  Every
>>> other tool but Zoom exists to pick some thing on the screen and do
>>> something to that thing.
>>>
>>> Peter is keen on us improving the zoom buttons on the edit toolbar and
>>> splitting them off as a new zoom-toolbar.  If we do, we can reinstate
>>> zoom-toggle, which I added and still miss.  Possibly multibuttons to make
>>> them configurable will save us from drowning in zoom buttons.
>>>
>>> I'm also planning for DA to introduce the zoom-ruler that I demoed in
>>> AU14
>>> TrackPanel.  That eliminates the need for a Zoom tool.  It also removes
>>> the
>>> need for a horizontal scrollbar.  The ideas behind Quick Play would move
>>> to
>>> the label track to free up that space, at the same time allowing multiple
>>> quick-play regions.
>>>
>>>
>>>
>>>
>>> Can we agree on simple, consistent behavior?
>>>
>>> 1. Should "special" hit test targets take priority over the tool, or not?
>>> For both buttons, always?  Or only for right button when the target does
>>> something?  I describe 2.1.3 behavior.
>>>
>>>
>>>      - The resizer handle at the bottom of a track is available no matter
>>>      what tool, for left click, but not for right click or drag in Multi
>>> which
>>>      still does a zoom.
>>>      - Cut-lines and clip boundaries in Wave tracks take priority in all
>>>      tools and both buttons (except, see 4).  Right-click on cut-line to
>>> delete
>>>      even takes priority over the zooming behavior in multi-tool.
>>> Right-click
>>>      and drag on a clip boundary does nothing in multi.
>>>      - Label end handles take priority in all tools, though not when
>>>      right-clicking in Multi.  They have no special right-click action.
>>>      - Label text boxes have no preview cursor or status bar message,
>>> passing
>>>      the default cursor and message for the tool, but take the left click
>>> (to
>>>      edit) and right (for context menu) in all tools.  So I can see a
>>> magnifier
>>>      cursor but still click to edit.
>>>      - The hot-zone for stretching a Note track (at middle height in the
>>>      selection) takes priority only in Select or Multi and is otherwise
>>>      unavailable.
>>>      - The grips for time-shift, at left and right edges in Multi, do not
>>>      take the right click.
>>>      - Other special wave track targets (envelope, samples) do not take
>>>      priority over right click in Multi.
>>>
>>> 2. Should right clicks be reserved for context menus, as in many other
>>> applications?
>>>
>>>
>>> Yes.
>>>
>>>
>>> Very well.  I think they are not hard to do in principle, but we might
>>> have
>>> difficulty agreeing on just what should go into them.
>>>
>>> The tricky bit is deciding/agreeing what happens to existing
>>> right-clicks.
>>>
>> Considering the proper track areas only, right clicks are very few now.
>> Right click on label text boxes which already does what we want to
>> generalize.  That leaves utline deletion (and how popular is this cutline
>> thing anyway?), the zooming part of multi-tool.  As I said I don't think
>> those will be missed.  The first becomes an item in a context menu
>> instead,
>>
>> Steve objected to repurposing the right-click in vertical rulers for
>> context menus when I attempted that in 2.1.2.  I did not not press the
>> argument, then.  But I still believe it ought to be done in future if we
>> put context menus everywhere as I think we ought.
>
> Should be an easy argument, since my impression is that right-click
> currently does same as left-click there.  With 2.2.0 we've got a lot
> bolder about making significant GUI changes, so I would expect it to
> (now) be not too hard to convince Steve with something more concrete and
> a clear path to greater consistency in the GUI.

More concrete and a clear path to greater consistency in the GUI could
be a very persuasive argument ;-)

Steve

>
> --James.
>
>
>
>>
>> PRL
>>
>>
>
>
> ------------------------------------------------------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Hit test inconsistencies

Paul Licameli
In reply to this post by Paul Licameli


On Sun, Jun 18, 2017 at 4:42 PM, Paul Licameli <[hidden email]> wrote:


On Sun, Jun 18, 2017 at 4:37 PM, Paul Licameli <[hidden email]> wrote:
My track panel refactor took some pains to preserve some old inconsistencies in behavior, complicating the resulting code more than I like.  Perhaps it isn't worth it.  I think what I preserved was a pile of ad-hocs that did not reflect a deliberate design.

I refer to hit-testing matters and the interaction with the Tools toolbar.

(I think the Tools toolbar should be abolished.  I would like to allow multiple hit-test targets at the mouse position in any track, and let the TAB key cycle among candidates.  But that may be too much to try in 2.2.0.)

Can we agree on simple, consistent behavior?

1. Should "special" hit test targets take priority over the tool, or not?  For both buttons, always?  Or only for right button when the target does something?  I describe 2.1.3 behavior.
  • The resizer handle at the bottom of a track is available no matter what tool, for left click, but not for right click or drag in Multi which still does a zoom.
  • Cut-lines and clip boundaries in Wave tracks take priority in all tools and both buttons (except, see 4).  Right-click on cut-line to delete even takes priority over the zooming behavior in multi-tool.  Right-click and drag on a clip boundary does nothing in multi.
  • Label end handles take priority in all tools, though not when right-clicking in Multi.  They have no special right-click action.
  • Label text boxes have no preview cursor or status bar message, passing the default cursor and message for the tool, but take the left click (to edit) and right (for context menu) in all tools.  So I can see a magnifier cursor but still click to edit.
  • The hot-zone for stretching a Note track (at middle height in the selection) takes priority only in Select or Multi and is otherwise unavailable.
  • The grips for time-shift, at left and right edges in Multi, do not take the right click.
  • Other special wave track targets (envelope, samples) do not take priority over right click in Multi.
2. Should right clicks be reserved for context menus, as in many other applications?  Little loss if deletion of a cutline gets a bit more complicated.  Multi would lose the zoom-out, but that is redundant with Ctrl+3.  But this is post 2.2.0 for sure.

3. If it's not Zoom tool (my least favorite of them), then in Time track, there is no possible target but the envelope.  But you can only edit the Time track in Envelope or Multi, which seems an unnecessary nuisance.  But then, any click edits this envelope, where in the Wave track you must click near the curve.

4. Envelope and cutlines and clip boundaries are invisible in spectrogram view.  You are prevented from editing them in Multi, but not in Envelope or Select tools.

So I propose instead these more consistent priorities, regardless which mouse button, even do-nothing right buttons (but, some dependency on modifier keys):
  • Between tracks, resizers always.  Otherwise, in tracks:
  • Zoom tool overrides all targets.  Otherwise, other tools:
  • MIDI stretch zone, Time track (only on the curve), cutline and clip boundary (if not spectrogram), in all tools.
I forgot label grips and text boxes, so insert the here.
 
  • Time-shifting of clips in Multi tool, when Ctrl is down.
  • Only if not spectrogram:  Samples in Draw or Multi, wave track envelopes in Envelope or Multi, and time shift grips, in Multi.  Unspecified priorities among these three in Multi.
Insert here, edges of the selection box in Select tool, including spectral selection top, bottom, and center.
 
  • Clips, or (with Shift key down) whole tracks, in Time-shift tool.
Note that whole tracks of three kinds (not Time) can shift. 
  • Right click to zoom in Multi, only in default of everything else.

Did I omit anything?

PRL

I have now reimplemented the TrackPanel hit-test priorities as described above, and also defined a status bar message for mouse over the label track text box, as mentioned elsewhere.

Gale, again, you are free to change the three new status messages as you see fit.  One is for the text boxes, another for cutline, another for clip boundaries that can be clicked to merge tracks.

PRL

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Hit test inconsistencies

Gale
Administrator
Just to note if you drag to a split line and cut, the Cut Lines
feature is not available - only the split line is offered. Same
in 2.1.3 and before that too probably.

If we can only show Cut Lines or Split Lines in that case, I
would have thought it made more sense to show Cut Lines.


Gale

On 27 June 2017 at 13:37, Paul Licameli <[hidden email]> wrote:

>
>
> On Sun, Jun 18, 2017 at 4:42 PM, Paul Licameli <[hidden email]>
> wrote:
>>
>>
>>
>> On Sun, Jun 18, 2017 at 4:37 PM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>> My track panel refactor took some pains to preserve some old
>>> inconsistencies in behavior, complicating the resulting code more than I
>>> like.  Perhaps it isn't worth it.  I think what I preserved was a pile of
>>> ad-hocs that did not reflect a deliberate design.
>>>
>>> I refer to hit-testing matters and the interaction with the Tools
>>> toolbar.
>>>
>>> (I think the Tools toolbar should be abolished.  I would like to allow
>>> multiple hit-test targets at the mouse position in any track, and let the
>>> TAB key cycle among candidates.  But that may be too much to try in 2.2.0.)
>>>
>>> Can we agree on simple, consistent behavior?
>>>
>>> 1. Should "special" hit test targets take priority over the tool, or not?
>>> For both buttons, always?  Or only for right button when the target does
>>> something?  I describe 2.1.3 behavior.
>>>
>>> The resizer handle at the bottom of a track is available no matter what
>>> tool, for left click, but not for right click or drag in Multi which still
>>> does a zoom.
>>> Cut-lines and clip boundaries in Wave tracks take priority in all tools
>>> and both buttons (except, see 4).  Right-click on cut-line to delete even
>>> takes priority over the zooming behavior in multi-tool.  Right-click and
>>> drag on a clip boundary does nothing in multi.
>>> Label end handles take priority in all tools, though not when
>>> right-clicking in Multi.  They have no special right-click action.
>>> Label text boxes have no preview cursor or status bar message, passing
>>> the default cursor and message for the tool, but take the left click (to
>>> edit) and right (for context menu) in all tools.  So I can see a magnifier
>>> cursor but still click to edit.
>>> The hot-zone for stretching a Note track (at middle height in the
>>> selection) takes priority only in Select or Multi and is otherwise
>>> unavailable.
>>> The grips for time-shift, at left and right edges in Multi, do not take
>>> the right click.
>>> Other special wave track targets (envelope, samples) do not take priority
>>> over right click in Multi.
>>>
>>> 2. Should right clicks be reserved for context menus, as in many other
>>> applications?  Little loss if deletion of a cutline gets a bit more
>>> complicated.  Multi would lose the zoom-out, but that is redundant with
>>> Ctrl+3.  But this is post 2.2.0 for sure.
>>>
>>> 3. If it's not Zoom tool (my least favorite of them), then in Time track,
>>> there is no possible target but the envelope.  But you can only edit the
>>> Time track in Envelope or Multi, which seems an unnecessary nuisance.  But
>>> then, any click edits this envelope, where in the Wave track you must click
>>> near the curve.
>>>
>>> 4. Envelope and cutlines and clip boundaries are invisible in spectrogram
>>> view.  You are prevented from editing them in Multi, but not in Envelope or
>>> Select tools.
>>>
>>> So I propose instead these more consistent priorities, regardless which
>>> mouse button, even do-nothing right buttons (but, some dependency on
>>> modifier keys):
>>>
>>> Between tracks, resizers always.  Otherwise, in tracks:
>>> Zoom tool overrides all targets.  Otherwise, other tools:
>>> MIDI stretch zone, Time track (only on the curve), cutline and clip
>>> boundary (if not spectrogram), in all tools.
>>
>> I forgot label grips and text boxes, so insert the here.
>>
>>>
>>> Time-shifting of clips in Multi tool, when Ctrl is down.
>>> Only if not spectrogram:  Samples in Draw or Multi, wave track envelopes
>>> in Envelope or Multi, and time shift grips, in Multi.  Unspecified
>>> priorities among these three in Multi.
>>
>> Insert here, edges of the selection box in Select tool, including spectral
>> selection top, bottom, and center.
>>
>>>
>>> Clips, or (with Shift key down) whole tracks, in Time-shift tool.
>>
>> Note that whole tracks of three kinds (not Time) can shift.
>>>
>>> Right click to zoom in Multi, only in default of everything else.
>>>
>>>
>>> Did I omit anything?
>>>
>>> PRL
>
>
> I have now reimplemented the TrackPanel hit-test priorities as described
> above, and also defined a status bar message for mouse over the label track
> text box, as mentioned elsewhere.
>
> Gale, again, you are free to change the three new status messages as you see
> fit.  One is for the text boxes, another for cutline, another for clip
> boundaries that can be clicked to merge tracks.
>
> PRL
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Hit test inconsistencies

Paul Licameli


On Tue, Jun 27, 2017 at 1:59 PM, Gale Andrews <[hidden email]> wrote:
Just to note if you drag to a split line and cut, the Cut Lines
feature is not available - only the split line is offered. Same
in 2.1.3 and before that too probably.

If we can only show Cut Lines or Split Lines in that case, I
would have thought it made more sense to show Cut Lines.


Gale

I am not sure I understand you.  Do you mean that it appears impossible to create a cutline that is exactly at the start of a clip?

Addressing that maty be worth a P3 bug but quite apart from these concerns about status bar messages.

PRL

 

On 27 June 2017 at 13:37, Paul Licameli <[hidden email]> wrote:
>
>
> On Sun, Jun 18, 2017 at 4:42 PM, Paul Licameli <[hidden email]>
> wrote:
>>
>>
>>
>> On Sun, Jun 18, 2017 at 4:37 PM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>> My track panel refactor took some pains to preserve some old
>>> inconsistencies in behavior, complicating the resulting code more than I
>>> like.  Perhaps it isn't worth it.  I think what I preserved was a pile of
>>> ad-hocs that did not reflect a deliberate design.
>>>
>>> I refer to hit-testing matters and the interaction with the Tools
>>> toolbar.
>>>
>>> (I think the Tools toolbar should be abolished.  I would like to allow
>>> multiple hit-test targets at the mouse position in any track, and let the
>>> TAB key cycle among candidates.  But that may be too much to try in 2.2.0.)
>>>
>>> Can we agree on simple, consistent behavior?
>>>
>>> 1. Should "special" hit test targets take priority over the tool, or not?
>>> For both buttons, always?  Or only for right button when the target does
>>> something?  I describe 2.1.3 behavior.
>>>
>>> The resizer handle at the bottom of a track is available no matter what
>>> tool, for left click, but not for right click or drag in Multi which still
>>> does a zoom.
>>> Cut-lines and clip boundaries in Wave tracks take priority in all tools
>>> and both buttons (except, see 4).  Right-click on cut-line to delete even
>>> takes priority over the zooming behavior in multi-tool.  Right-click and
>>> drag on a clip boundary does nothing in multi.
>>> Label end handles take priority in all tools, though not when
>>> right-clicking in Multi.  They have no special right-click action.
>>> Label text boxes have no preview cursor or status bar message, passing
>>> the default cursor and message for the tool, but take the left click (to
>>> edit) and right (for context menu) in all tools.  So I can see a magnifier
>>> cursor but still click to edit.
>>> The hot-zone for stretching a Note track (at middle height in the
>>> selection) takes priority only in Select or Multi and is otherwise
>>> unavailable.
>>> The grips for time-shift, at left and right edges in Multi, do not take
>>> the right click.
>>> Other special wave track targets (envelope, samples) do not take priority
>>> over right click in Multi.
>>>
>>> 2. Should right clicks be reserved for context menus, as in many other
>>> applications?  Little loss if deletion of a cutline gets a bit more
>>> complicated.  Multi would lose the zoom-out, but that is redundant with
>>> Ctrl+3.  But this is post 2.2.0 for sure.
>>>
>>> 3. If it's not Zoom tool (my least favorite of them), then in Time track,
>>> there is no possible target but the envelope.  But you can only edit the
>>> Time track in Envelope or Multi, which seems an unnecessary nuisance.  But
>>> then, any click edits this envelope, where in the Wave track you must click
>>> near the curve.
>>>
>>> 4. Envelope and cutlines and clip boundaries are invisible in spectrogram
>>> view.  You are prevented from editing them in Multi, but not in Envelope or
>>> Select tools.
>>>
>>> So I propose instead these more consistent priorities, regardless which
>>> mouse button, even do-nothing right buttons (but, some dependency on
>>> modifier keys):
>>>
>>> Between tracks, resizers always.  Otherwise, in tracks:
>>> Zoom tool overrides all targets.  Otherwise, other tools:
>>> MIDI stretch zone, Time track (only on the curve), cutline and clip
>>> boundary (if not spectrogram), in all tools.
>>
>> I forgot label grips and text boxes, so insert the here.
>>
>>>
>>> Time-shifting of clips in Multi tool, when Ctrl is down.
>>> Only if not spectrogram:  Samples in Draw or Multi, wave track envelopes
>>> in Envelope or Multi, and time shift grips, in Multi.  Unspecified
>>> priorities among these three in Multi.
>>
>> Insert here, edges of the selection box in Select tool, including spectral
>> selection top, bottom, and center.
>>
>>>
>>> Clips, or (with Shift key down) whole tracks, in Time-shift tool.
>>
>> Note that whole tracks of three kinds (not Time) can shift.
>>>
>>> Right click to zoom in Multi, only in default of everything else.
>>>
>>>
>>> Did I omit anything?
>>>
>>> PRL
>
>
> I have now reimplemented the TrackPanel hit-test priorities as described
> above, and also defined a status bar message for mouse over the label track
> text box, as mentioned elsewhere.
>
> Gale, again, you are free to change the three new status messages as you see
> fit.  One is for the text boxes, another for cutline, another for clip
> boundaries that can be clicked to merge tracks.
>
> PRL
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Hit test inconsistencies

Gale
Administrator
On 27 June 2017 at 19:23, Paul Licameli <[hidden email]> wrote:

>
>
> On Tue, Jun 27, 2017 at 1:59 PM, Gale Andrews <[hidden email]> wrote:
>>
>> Just to note if you drag to a split line and cut, the Cut Lines
>> feature is not available - only the split line is offered. Same
>> in 2.1.3 and before that too probably.
>>
>> If we can only show Cut Lines or Split Lines in that case, I
>> would have thought it made more sense to show Cut Lines.
>>
>>
>> Gale
>
>
> I am not sure I understand you.  Do you mean that it appears impossible to
> create a cutline that is exactly at the start of a clip?

Yes. Try another variation.

1 Generate Tone any length say 30s.
2 Drag a region anywhere in track say 5s to 10s.
3 Ctrl + I to split
4 Ctrl + X to cut. A split line is seen at 5s which
   when clicked performs a merge.

There is no cut line - only a split line, so no way to expand the
cut using the mouse in the track.


Gale


> Addressing that maty be worth a P3 bug but quite apart from these concerns
> about status bar messages.
>
> PRL
>
>
>>
>>
>> On 27 June 2017 at 13:37, Paul Licameli <[hidden email]> wrote:
>> >
>> >
>> > On Sun, Jun 18, 2017 at 4:42 PM, Paul Licameli <[hidden email]>
>> > wrote:
>> >>
>> >>
>> >>
>> >> On Sun, Jun 18, 2017 at 4:37 PM, Paul Licameli
>> >> <[hidden email]>
>> >> wrote:
>> >>>
>> >>> My track panel refactor took some pains to preserve some old
>> >>> inconsistencies in behavior, complicating the resulting code more than
>> >>> I
>> >>> like.  Perhaps it isn't worth it.  I think what I preserved was a pile
>> >>> of
>> >>> ad-hocs that did not reflect a deliberate design.
>> >>>
>> >>> I refer to hit-testing matters and the interaction with the Tools
>> >>> toolbar.
>> >>>
>> >>> (I think the Tools toolbar should be abolished.  I would like to allow
>> >>> multiple hit-test targets at the mouse position in any track, and let
>> >>> the
>> >>> TAB key cycle among candidates.  But that may be too much to try in
>> >>> 2.2.0.)
>> >>>
>> >>> Can we agree on simple, consistent behavior?
>> >>>
>> >>> 1. Should "special" hit test targets take priority over the tool, or
>> >>> not?
>> >>> For both buttons, always?  Or only for right button when the target
>> >>> does
>> >>> something?  I describe 2.1.3 behavior.
>> >>>
>> >>> The resizer handle at the bottom of a track is available no matter
>> >>> what
>> >>> tool, for left click, but not for right click or drag in Multi which
>> >>> still
>> >>> does a zoom.
>> >>> Cut-lines and clip boundaries in Wave tracks take priority in all
>> >>> tools
>> >>> and both buttons (except, see 4).  Right-click on cut-line to delete
>> >>> even
>> >>> takes priority over the zooming behavior in multi-tool.  Right-click
>> >>> and
>> >>> drag on a clip boundary does nothing in multi.
>> >>> Label end handles take priority in all tools, though not when
>> >>> right-clicking in Multi.  They have no special right-click action.
>> >>> Label text boxes have no preview cursor or status bar message, passing
>> >>> the default cursor and message for the tool, but take the left click
>> >>> (to
>> >>> edit) and right (for context menu) in all tools.  So I can see a
>> >>> magnifier
>> >>> cursor but still click to edit.
>> >>> The hot-zone for stretching a Note track (at middle height in the
>> >>> selection) takes priority only in Select or Multi and is otherwise
>> >>> unavailable.
>> >>> The grips for time-shift, at left and right edges in Multi, do not
>> >>> take
>> >>> the right click.
>> >>> Other special wave track targets (envelope, samples) do not take
>> >>> priority
>> >>> over right click in Multi.
>> >>>
>> >>> 2. Should right clicks be reserved for context menus, as in many other
>> >>> applications?  Little loss if deletion of a cutline gets a bit more
>> >>> complicated.  Multi would lose the zoom-out, but that is redundant
>> >>> with
>> >>> Ctrl+3.  But this is post 2.2.0 for sure.
>> >>>
>> >>> 3. If it's not Zoom tool (my least favorite of them), then in Time
>> >>> track,
>> >>> there is no possible target but the envelope.  But you can only edit
>> >>> the
>> >>> Time track in Envelope or Multi, which seems an unnecessary nuisance.
>> >>> But
>> >>> then, any click edits this envelope, where in the Wave track you must
>> >>> click
>> >>> near the curve.
>> >>>
>> >>> 4. Envelope and cutlines and clip boundaries are invisible in
>> >>> spectrogram
>> >>> view.  You are prevented from editing them in Multi, but not in
>> >>> Envelope or
>> >>> Select tools.
>> >>>
>> >>> So I propose instead these more consistent priorities, regardless
>> >>> which
>> >>> mouse button, even do-nothing right buttons (but, some dependency on
>> >>> modifier keys):
>> >>>
>> >>> Between tracks, resizers always.  Otherwise, in tracks:
>> >>> Zoom tool overrides all targets.  Otherwise, other tools:
>> >>> MIDI stretch zone, Time track (only on the curve), cutline and clip
>> >>> boundary (if not spectrogram), in all tools.
>> >>
>> >> I forgot label grips and text boxes, so insert the here.
>> >>
>> >>>
>> >>> Time-shifting of clips in Multi tool, when Ctrl is down.
>> >>> Only if not spectrogram:  Samples in Draw or Multi, wave track
>> >>> envelopes
>> >>> in Envelope or Multi, and time shift grips, in Multi.  Unspecified
>> >>> priorities among these three in Multi.
>> >>
>> >> Insert here, edges of the selection box in Select tool, including
>> >> spectral
>> >> selection top, bottom, and center.
>> >>
>> >>>
>> >>> Clips, or (with Shift key down) whole tracks, in Time-shift tool.
>> >>
>> >> Note that whole tracks of three kinds (not Time) can shift.
>> >>>
>> >>> Right click to zoom in Multi, only in default of everything else.
>> >>>
>> >>>
>> >>> Did I omit anything?
>> >>>
>> >>> PRL
>> >
>> >
>> > I have now reimplemented the TrackPanel hit-test priorities as described
>> > above, and also defined a status bar message for mouse over the label
>> > track
>> > text box, as mentioned elsewhere.
>> >
>> > Gale, again, you are free to change the three new status messages as you
>> > see
>> > fit.  One is for the text boxes, another for cutline, another for clip
>> > boundaries that can be clicked to merge tracks.
>> >
>> > PRL
>> >
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > Audacity-quality mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Hit test inconsistencies

Paul Licameli


On Tue, Jun 27, 2017 at 4:51 PM, Gale Andrews <[hidden email]> wrote:
On 27 June 2017 at 19:23, Paul Licameli <[hidden email]> wrote:
>
>
> On Tue, Jun 27, 2017 at 1:59 PM, Gale Andrews <[hidden email]> wrote:
>>
>> Just to note if you drag to a split line and cut, the Cut Lines
>> feature is not available - only the split line is offered. Same
>> in 2.1.3 and before that too probably.
>>
>> If we can only show Cut Lines or Split Lines in that case, I
>> would have thought it made more sense to show Cut Lines.
>>
>>
>> Gale
>
>
> I am not sure I understand you.  Do you mean that it appears impossible to
> create a cutline that is exactly at the start of a clip?

Yes. Try another variation.

1 Generate Tone any length say 30s.
2 Drag a region anywhere in track say 5s to 10s.
3 Ctrl + I to split
4 Ctrl + X to cut. A split line is seen at 5s which
   when clicked performs a merge.

There is no cut line - only a split line, so no way to expand the
cut using the mouse in the track.

This is a problem unrelated to my present projects.  Please make a bug request.  I don't promise to fix it in 2.2.0.

PRL

 


Gale


> Addressing that maty be worth a P3 bug but quite apart from these concerns
> about status bar messages.
>
> PRL
>
>
>>
>>
>> On 27 June 2017 at 13:37, Paul Licameli <[hidden email]> wrote:
>> >
>> >
>> > On Sun, Jun 18, 2017 at 4:42 PM, Paul Licameli <[hidden email]>
>> > wrote:
>> >>
>> >>
>> >>
>> >> On Sun, Jun 18, 2017 at 4:37 PM, Paul Licameli
>> >> <[hidden email]>
>> >> wrote:
>> >>>
>> >>> My track panel refactor took some pains to preserve some old
>> >>> inconsistencies in behavior, complicating the resulting code more than
>> >>> I
>> >>> like.  Perhaps it isn't worth it.  I think what I preserved was a pile
>> >>> of
>> >>> ad-hocs that did not reflect a deliberate design.
>> >>>
>> >>> I refer to hit-testing matters and the interaction with the Tools
>> >>> toolbar.
>> >>>
>> >>> (I think the Tools toolbar should be abolished.  I would like to allow
>> >>> multiple hit-test targets at the mouse position in any track, and let
>> >>> the
>> >>> TAB key cycle among candidates.  But that may be too much to try in
>> >>> 2.2.0.)
>> >>>
>> >>> Can we agree on simple, consistent behavior?
>> >>>
>> >>> 1. Should "special" hit test targets take priority over the tool, or
>> >>> not?
>> >>> For both buttons, always?  Or only for right button when the target
>> >>> does
>> >>> something?  I describe 2.1.3 behavior.
>> >>>
>> >>> The resizer handle at the bottom of a track is available no matter
>> >>> what
>> >>> tool, for left click, but not for right click or drag in Multi which
>> >>> still
>> >>> does a zoom.
>> >>> Cut-lines and clip boundaries in Wave tracks take priority in all
>> >>> tools
>> >>> and both buttons (except, see 4).  Right-click on cut-line to delete
>> >>> even
>> >>> takes priority over the zooming behavior in multi-tool.  Right-click
>> >>> and
>> >>> drag on a clip boundary does nothing in multi.
>> >>> Label end handles take priority in all tools, though not when
>> >>> right-clicking in Multi.  They have no special right-click action.
>> >>> Label text boxes have no preview cursor or status bar message, passing
>> >>> the default cursor and message for the tool, but take the left click
>> >>> (to
>> >>> edit) and right (for context menu) in all tools.  So I can see a
>> >>> magnifier
>> >>> cursor but still click to edit.
>> >>> The hot-zone for stretching a Note track (at middle height in the
>> >>> selection) takes priority only in Select or Multi and is otherwise
>> >>> unavailable.
>> >>> The grips for time-shift, at left and right edges in Multi, do not
>> >>> take
>> >>> the right click.
>> >>> Other special wave track targets (envelope, samples) do not take
>> >>> priority
>> >>> over right click in Multi.
>> >>>
>> >>> 2. Should right clicks be reserved for context menus, as in many other
>> >>> applications?  Little loss if deletion of a cutline gets a bit more
>> >>> complicated.  Multi would lose the zoom-out, but that is redundant
>> >>> with
>> >>> Ctrl+3.  But this is post 2.2.0 for sure.
>> >>>
>> >>> 3. If it's not Zoom tool (my least favorite of them), then in Time
>> >>> track,
>> >>> there is no possible target but the envelope.  But you can only edit
>> >>> the
>> >>> Time track in Envelope or Multi, which seems an unnecessary nuisance.
>> >>> But
>> >>> then, any click edits this envelope, where in the Wave track you must
>> >>> click
>> >>> near the curve.
>> >>>
>> >>> 4. Envelope and cutlines and clip boundaries are invisible in
>> >>> spectrogram
>> >>> view.  You are prevented from editing them in Multi, but not in
>> >>> Envelope or
>> >>> Select tools.
>> >>>
>> >>> So I propose instead these more consistent priorities, regardless
>> >>> which
>> >>> mouse button, even do-nothing right buttons (but, some dependency on
>> >>> modifier keys):
>> >>>
>> >>> Between tracks, resizers always.  Otherwise, in tracks:
>> >>> Zoom tool overrides all targets.  Otherwise, other tools:
>> >>> MIDI stretch zone, Time track (only on the curve), cutline and clip
>> >>> boundary (if not spectrogram), in all tools.
>> >>
>> >> I forgot label grips and text boxes, so insert the here.
>> >>
>> >>>
>> >>> Time-shifting of clips in Multi tool, when Ctrl is down.
>> >>> Only if not spectrogram:  Samples in Draw or Multi, wave track
>> >>> envelopes
>> >>> in Envelope or Multi, and time shift grips, in Multi.  Unspecified
>> >>> priorities among these three in Multi.
>> >>
>> >> Insert here, edges of the selection box in Select tool, including
>> >> spectral
>> >> selection top, bottom, and center.
>> >>
>> >>>
>> >>> Clips, or (with Shift key down) whole tracks, in Time-shift tool.
>> >>
>> >> Note that whole tracks of three kinds (not Time) can shift.
>> >>>
>> >>> Right click to zoom in Multi, only in default of everything else.
>> >>>
>> >>>
>> >>> Did I omit anything?
>> >>>
>> >>> PRL
>> >
>> >
>> > I have now reimplemented the TrackPanel hit-test priorities as described
>> > above, and also defined a status bar message for mouse over the label
>> > track
>> > text box, as mentioned elsewhere.
>> >
>> > Gale, again, you are free to change the three new status messages as you
>> > see
>> > fit.  One is for the text boxes, another for cutline, another for clip
>> > boundaries that can be clicked to merge tracks.
>> >
>> > PRL
>> >
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > Audacity-quality mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality