Preview snap lines; revisiting Bug 800

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Preview snap lines; revisiting Bug 800

James Crook
[Moved to quality.]

On 7/15/2017 5:39 PM, Paul Licameli wrote:

> I am holding out for TAB or some other key for cycling hit test targets, in
> this or another release.  It seems so very obvious to me that this is very
> valuable, maybe because it was an obvious problem needing solution in the
> 3d CAD programs I once worked on, but no less here when several things are
> overlain in a small space to convey information and they are interactive
> too.
>
> I am disappointed that this idea isn't a bigger immediate hit, but I have
> James with me here, and I hope to make the idea grow on the rest of you.  I
> would like to put it into 2.2.0 if only as a nondefault preference.

I am fine with Tab doing that in 2.2.0, where it does not interfere with
Tab for other uses, and I am fine with Tab being not (or barely)
discoverable.  I don't want Tab in a portmanteau tooltip. It makes the
tooltip too busy and I think tooltips need to be single topic.

In a 3D CAD application it is impossible to avoid things that you want
to drag ending up in the same location.  In Audacity, by careful design,
it can be made to be rare.  We could have diverse handles on clips for
dragging (position) resizing (stretch), resizing (repeat/crop)
clip-connecting, selecting (clip multiselect) without all those handles
overlapping, just by making smart choices about where to put the
handles.  So I see 'Tab for resolving overlap' as a last port of call.  
It comes to the rescue when overlap is unavoidable.

An envelope point can overlap a sample point, when zoomed in far enough
to see sample points.  In that case Tab could come to the rescue.  Also
later when we allow layering of tracks, e.g. a label track over a wave
track, tab could be handy.  We could instead use the rule of top-track
is the one hit, but we might be forever dragging things out the way.  
Tab could be a handy way to drill down.

The scheme I currently like best is use of circular menus rather than
cycling, so that clicking Tab arranges 'bubbles' for selectable things
nicely spaced out in a circle around the cursor, and you move the mouse
onto the bubble you want.  Repeated Tab, I suppose, could walk around
the circle, rather than requiring that the mouse move. If the bubbles
have short help text, the Tab also then doubles as a way to get help on
anything solitary that is clickable.

A second scheme I like is that Right-Click gives a context menu, and the
last item in the menu is 'select' with select being a submenu listing
the nearby options.

Or even clicking on an ambiguous target could bring up the 'select' menu.

The schemes I like would take more design and thinking and
implementation, and would be too much for 2.2.0.




>
> Just as right-click should (will?) be the universal "more actions"
> convention, and as Esc key IS (!!! since 2.2.0, you're welcome) the
> universal "stop this drag" convention, so too there should be a universal,
> easily described and remembered, "rotate among targets" convention.
>
> I like TAB for this purpose because it already does analogous things, as
> with toolbar control navigation and the cycle of labels, and also because
> it is one of the keys you can't reassign in keyboard preferences.  I think
> the rotation key really should be reserved for that and not reassignable.
>
> I do not like solutions that resort to special modifier key combinations
> that are hard to remember and also lengthen the complete status bar
> message.
+1

> I would rather reserve shift- or control-click for a few things,
> such as distinguishing new selection from adjustment, analogously with most
> text editors.
>
> I would really dislike a resort to modifier keys such as suggested in
> comment #8 here http://bugzilla.audacityteam.org/show_bug.cgi?id=800, or
> solutions such as Gale has mentioned, that distinguish at button-up whether
> there was a drag or only a click, and do very unrelated things in those two
> cases.
>
> Yes to the variety of possible actions, no to overloading Shift, Ctrl, etc.
> too much.  Yes to cursor and other appearance changes, in response to the
> rotation key, that let you anticipate what a simple click and drag will do,
> before you do it.
>
> I do not like solutions, such as what I saw James doing, changing the long
> familiar appearance of things, just to fix this special case of
> disambiguation of picks.
So we need to discuss drag-handles for clips.  They will be new, and we
need to decide what they look like.  We also need to discuss drag
handles for Labels.  Dragging can drag just one end, or move both ends.  
To avoid being special case we need to discuss handles as a general topic.


> Let me emphasize again that this is about more than just the split lines.
> I don't want to have a hack that only addresses them.
>
> A good target-rotation convention, if it had been in place already, would
> have mooted this discussion from the start.
>
> 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
|  
Report Content as Inappropriate

Re: Preview snap lines; revisiting Bug 800

Paul Licameli


On Sat, Jul 15, 2017 at 1:38 PM, James Crook <[hidden email]> wrote:
[Moved to quality.]

On 7/15/2017 5:39 PM, Paul Licameli wrote:

I am holding out for TAB or some other key for cycling hit test targets, in
this or another release.  It seems so very obvious to me that this is very
valuable, maybe because it was an obvious problem needing solution in the
3d CAD programs I once worked on, but no less here when several things are
overlain in a small space to convey information and they are interactive
too.

I am disappointed that this idea isn't a bigger immediate hit, but I have
James with me here, and I hope to make the idea grow on the rest of you.  I
would like to put it into 2.2.0 if only as a nondefault preference.

I am fine with Tab doing that in 2.2.0, where it does not interfere with Tab for other uses, and I am fine with Tab being not (or barely) discoverable.  I don't want Tab in a portmanteau tooltip. It makes the tooltip too busy and I think tooltips need to be single topic.

What are the interfering uses of Tab you are thinking of?  I mention navigation among toolbar controls, and rotation among labels of the focused label track.  I know I fixed interference with the latter, when it provoked some immediate outcry.
 

In a 3D CAD application it is impossible to avoid things that you want to drag ending up in the same location.  In Audacity, by careful design, it can be made to be rare.  We could have diverse handles on clips for dragging (position) resizing (stretch), resizing (repeat/crop) clip-connecting, selecting (clip multiselect) without all those handles overlapping, just by making smart choices about where to put the handles.  So I see 'Tab for resolving overlap' as a last port of call.  It comes to the rescue when overlap is unavoidable.

I think Tab could make ingenious special handles unnecessary.  The tab alternative might even make them objectionable as needless visual clutter.  But even if not, you do not deny the value of tab as a (not sole) alternative.


An envelope point can overlap a sample point, when zoomed in far enough to see sample points.  In that case Tab could come to the rescue.

Exactly one of the cases I was thinking of, as I reorganized the multi-tool hit test code.  I mention too that if you get the Note track stretch handle but don't want it, you hit Tab and get the select tool.

I have also implemented Tab as a way to cycle between snapping and non-snapping selection, either before the click or after it.  That too might be useful if you really don't want the snap and want fine positional control of selection bounds.
 
Also later when we allow layering of tracks, e.g. a label track over a wave track, tab could be handy.  We could instead use the rule of top-track is the one hit, but we might be forever dragging things out the way.  Tab could be a handy way to drill down.

The scheme I currently like best is use of circular menus rather than cycling, so that clicking Tab arranges 'bubbles' for selectable things nicely spaced out in a circle around the cursor, and you move the mouse onto the bubble you want.  Repeated Tab, I suppose, could walk around the circle, rather than requiring that the mouse move. If the bubbles have short help text, the Tab also then doubles as a way to get help on anything solitary that is clickable.

I don't undertstand the bit about text.

Perhaps the bubbles appear just in response to mouse motion whenever there are multiple possibilities.  Perhaps they will jump and dance in a cute animated fashion.

I just imagined a simpler fantasy, but still needing some work.  Do some image manipulation, so that every cursor has an alternative form with "[TAB]" in a tiny font, or something else, added to it.  Use that cursor whenever a TAB cycle of more than one exists.  This makes it unnecessary to mention Tab key in tooltips.  I hope the three letter text "TAB" need not be internationalized too, but it might even be done.
 

A second scheme I like is that Right-Click gives a context menu, and the last item in the menu is 'select' with select being a submenu listing the nearby options.

Not sure I like that.  I think of right click as meaning "do something with what I selected" and not the means of selection.

Common with the bubbles, it would require me to move the pointer away from the actual target I am selecting.  I don't like that.  I think it better to understand a convention that engages the other hand and doesn't move the pointer.

(Or the other fingers?  Maybe thumb buttons, on the fancy mice that have them, can be alternatives to tab, making complicated selections all one-handed.)
 

Or even clicking on an ambiguous target could bring up the 'select' menu.

The schemes I like would take more design and thinking and implementation, and would be too much for 2.2.0.

Indeed.

But I am happy to have accomplished the preliminary organization of the multiple hit-target abstraction, independent of all this.  I must say, that even if consensus turns against anything (even nondefault preference) in 2.2.0, still the code reorganization I have lately achieved feels very good to me personally.  I did not have quite such a good feeling only after rebasing my two-year old stuff.  Certain problems with my initial reorganization became apparent, making me uncomfortable.  The thing still felt half-done even after that earlier difficult mark was reached.  But no longer.

more... 






Just as right-click should (will?) be the universal "more actions"
convention, and as Esc key IS (!!! since 2.2.0, you're welcome) the
universal "stop this drag" convention, so too there should be a universal,
easily described and remembered, "rotate among targets" convention.

I like TAB for this purpose because it already does analogous things, as
with toolbar control navigation and the cycle of labels, and also because
it is one of the keys you can't reassign in keyboard preferences.  I think
the rotation key really should be reserved for that and not reassignable.

I do not like solutions that resort to special modifier key combinations
that are hard to remember and also lengthen the complete status bar
message.
+1

I would rather reserve shift- or control-click for a few things,
such as distinguishing new selection from adjustment, analogously with most
text editors.

I would really dislike a resort to modifier keys such as suggested in
comment #8 here http://bugzilla.audacityteam.org/show_bug.cgi?id=800, or
solutions such as Gale has mentioned, that distinguish at button-up whether
there was a drag or only a click, and do very unrelated things in those two
cases.

Yes to the variety of possible actions, no to overloading Shift, Ctrl, etc.
too much.  Yes to cursor and other appearance changes, in response to the
rotation key, that let you anticipate what a simple click and drag will do,
before you do it.

I do not like solutions, such as what I saw James doing, changing the long
familiar appearance of things, just to fix this special case of
disambiguation of picks.
So we need to discuss drag-handles for clips.  They will be new, and we need to decide what they look like.  We also need to discuss drag handles for Labels.  Dragging can drag just one end, or move both ends.  To avoid being special case we need to discuss handles as a general topic.


Steve has mentioned some inadequacies about labels, which we won't address just now.  But I have been thinking of the problem of distinct actions for movement of one label, versus adjustment of a chain of labels, each ending exactly where the next starts (pick on any one of the circles); or a third thing, moving the boundary between two abutting labels, while leaving outer boundaries fixed.

I would simply let the tab choose among these three, when more than one is possible for a given click point.  There can be distinct highlighting states of the circles and chevrons.  Then after you click, there could also be yellow snaps as with selection, and Tab switches between snapping and non-snapping during drag, as is now done during selection.

These possibilities are more easily open with the code reorganization.

PRL

 

Let me emphasize again that this is about more than just the split lines.
I don't want to have a hack that only addresses them.

A good target-rotation convention, if it had been in place already, would
have mooted this discussion from the start.

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
|  
Report Content as Inappropriate

Re: Preview snap lines; revisiting Bug 800

James Crook
On 7/15/2017 7:49 PM, Paul Licameli wrote:

> On Sat, Jul 15, 2017 at 1:38 PM, James Crook <[hidden email]> wrote:
>
>> [Moved to quality.]
>>
>> On 7/15/2017 5:39 PM, Paul Licameli wrote:
>>
>> I am holding out for TAB or some other key for cycling hit test targets, in
>>> this or another release.  It seems so very obvious to me that this is very
>>> valuable, maybe because it was an obvious problem needing solution in the
>>> 3d CAD programs I once worked on, but no less here when several things are
>>> overlain in a small space to convey information and they are interactive
>>> too.
>>>
>>> I am disappointed that this idea isn't a bigger immediate hit, but I have
>>> James with me here, and I hope to make the idea grow on the rest of you.
>>> I
>>> would like to put it into 2.2.0 if only as a nondefault preference.
>>>
>> I am fine with Tab doing that in 2.2.0, where it does not interfere with
>> Tab for other uses, and I am fine with Tab being not (or barely)
>> discoverable.  I don't want Tab in a portmanteau tooltip. It makes the
>> tooltip too busy and I think tooltips need to be single topic.
>>
> What are the interfering uses of Tab you are thinking of?
Labels.  Yes I know you fixed that.  I mentioned non-interference as a
catch-all, just in case.

> I mention navigation among toolbar controls, and rotation among labels of the focused
> label track.  I know I fixed interference with the latter, when it provoked
> some immediate outcry.
>
>
>> In a 3D CAD application it is impossible to avoid things that you want to
>> drag ending up in the same location.  In Audacity, by careful design, it
>> can be made to be rare.  We could have diverse handles on clips for
>> dragging (position) resizing (stretch), resizing (repeat/crop)
>> clip-connecting, selecting (clip multiselect) without all those handles
>> overlapping, just by making smart choices about where to put the handles.
>> So I see 'Tab for resolving overlap' as a last port of call.  It comes to
>> the rescue when overlap is unavoidable.
>>
> I think Tab could make ingenious special handles unnecessary.  The tab
> alternative might even make them objectionable as needless visual clutter.
> But even if not, you do not deny the value of tab as a (not sole)
> alternative.
>
>
>> An envelope point can overlap a sample point, when zoomed in far enough to
>> see sample points.  In that case Tab could come to the rescue.
>
> Exactly one of the cases I was thinking of, as I reorganized the multi-tool
> hit test code.  I mention too that if you get the Note track stretch handle
> but don't want it, you hit Tab and get the select tool.
>
> I have also implemented Tab as a way to cycle between snapping and
> non-snapping selection, either before the click or after it.
That is a slippery slope, because it is not really selecting 'different
things'.  Before long there will be calls to use Tab to switch between
snap-to on and off, and snap-to-zero-crossings on and off.


> That too might be useful if you really don't want the snap and want fine positional
> control of selection bounds.
Why would I expect Tab to switch it on and off and not some setting or
button somewhere?

>
>> Also later when we allow layering of tracks, e.g. a label track over a
>> wave track, tab could be handy.  We could instead use the rule of top-track
>> is the one hit, but we might be forever dragging things out the way.  Tab
>> could be a handy way to drill down.
>>
>> The scheme I currently like best is use of circular menus rather than
>> cycling, so that clicking Tab arranges 'bubbles' for selectable things
>> nicely spaced out in a circle around the cursor, and you move the mouse
>> onto the bubble you want.  Repeated Tab, I suppose, could walk around the
>> circle, rather than requiring that the mouse move. If the bubbles have
>> short help text, the Tab also then doubles as a way to get help on anything
>> solitary that is clickable.
>>
> I don't undertstand the bit about text.
Bubbles have icons and text.

Sample Bubble: Icon for a sample being dragged, and text 'change just
this sample'
Envelope-point bubble: Icon for an envelope point being dragged, and
text 'change envelope point position'

Text is (maybe) hyperlinked to help.


>
> Perhaps the bubbles appear just in response to mouse motion whenever there
> are multiple possibilities.  Perhaps they will jump and dance in a cute
> animated fashion.
>
> I just imagined a simpler fantasy, but still needing some work.  Do some
> image manipulation, so that every cursor has an alternative form with
> "[TAB]" in a tiny font, or something else, added to it.  Use that cursor
> whenever a TAB cycle of more than one exists.  This makes it unnecessary to
> mention Tab key in tooltips.  I hope the three letter text "TAB" need not
> be internationalized too, but it might even be done.
>
>
>> A second scheme I like is that Right-Click gives a context menu, and the
>> last item in the menu is 'select' with select being a submenu listing the
>> nearby options.
>>
> Not sure I like that.  I think of right click as meaning "do something with
> what I selected" and not the means of selection.
>
> Common with the bubbles, it would require me to move the pointer away from
> the actual target I am selecting.  I don't like that.  I think it better to
> understand a convention that engages the other hand and doesn't move the
> pointer.
>
> (Or the other fingers?  Maybe thumb buttons, on the fancy mice that have
> them, can be alternatives to tab, making complicated selections all
> one-handed.)
>
>
>> Or even clicking on an ambiguous target could bring up the 'select' menu.
>>
>> The schemes I like would take more design and thinking and implementation,
>> and would be too much for 2.2.0.
>
> Indeed.
>
> But I am happy to have accomplished the preliminary organization of the
> multiple hit-target abstraction, independent of all this.  I must say, that
> even if consensus turns against anything (even nondefault preference) in
> 2.2.0, still the code reorganization I have lately achieved feels very good
> to me personally.  I did not have quite such a good feeling only after
> rebasing my two-year old stuff.  Certain problems with my initial
> reorganization became apparent, making me uncomfortable.  The thing still
> felt half-done even after that earlier difficult mark was reached.  But no
> longer.
>
> more...
>
>>
>>
>>
>>
>>
>>> Just as right-click should (will?) be the universal "more actions"
>>> convention, and as Esc key IS (!!! since 2.2.0, you're welcome) the
>>> universal "stop this drag" convention, so too there should be a universal,
>>> easily described and remembered, "rotate among targets" convention.
>>>
>>> I like TAB for this purpose because it already does analogous things, as
>>> with toolbar control navigation and the cycle of labels, and also because
>>> it is one of the keys you can't reassign in keyboard preferences.  I think
>>> the rotation key really should be reserved for that and not reassignable.
>>>
>>> I do not like solutions that resort to special modifier key combinations
>>> that are hard to remember and also lengthen the complete status bar
>>> message.
>>>
>> +1
>>
>> I would rather reserve shift- or control-click for a few things,
>>> such as distinguishing new selection from adjustment, analogously with
>>> most
>>> text editors.
>>>
>>> I would really dislike a resort to modifier keys such as suggested in
>>> comment #8 here http://bugzilla.audacityteam.org/show_bug.cgi?id=800, or
>>> solutions such as Gale has mentioned, that distinguish at button-up
>>> whether
>>> there was a drag or only a click, and do very unrelated things in those
>>> two
>>> cases.
>>>
>>> Yes to the variety of possible actions, no to overloading Shift, Ctrl,
>>> etc.
>>> too much.  Yes to cursor and other appearance changes, in response to the
>>> rotation key, that let you anticipate what a simple click and drag will
>>> do,
>>> before you do it.
>>>
>>> I do not like solutions, such as what I saw James doing, changing the long
>>> familiar appearance of things, just to fix this special case of
>>> disambiguation of picks.
>>>
>> So we need to discuss drag-handles for clips.  They will be new, and we
>> need to decide what they look like.  We also need to discuss drag handles
>> for Labels.  Dragging can drag just one end, or move both ends.  To avoid
>> being special case we need to discuss handles as a general topic.
>>
>>
> Steve has mentioned some inadequacies about labels, which we won't address
> just now.  But I have been thinking of the problem of distinct actions for
> movement of one label, versus adjustment of a chain of labels, each ending
> exactly where the next starts (pick on any one of the circles); or a third
> thing, moving the boundary between two abutting labels, while leaving outer
> boundaries fixed.
>
> I would simply let the tab choose among these three, when more than one is
> possible for a given click point.  There can be distinct highlighting
> states of the circles and chevrons.  Then after you click, there could also
> be yellow snaps as with selection, and Tab switches between snapping and
> non-snapping during drag, as is now done during selection.
And we should think of using the same idiom for labels and for clips.

For example, Ctrl-I in the text of a label should split the text into
two labels at the text cursor.

Moving a label without changing size is really multi-select.  You are
selecting both ends of a label and dragging both at the same time.

--James


>
> These possibilities are more easily open with the code reorganization.
>
> 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
|  
Report Content as Inappropriate

Re: Preview snap lines; revisiting Bug 800

Paul Licameli


On Sat, Jul 15, 2017 at 3:12 PM, James Crook <[hidden email]> wrote:
On 7/15/2017 7:49 PM, Paul Licameli wrote:
On Sat, Jul 15, 2017 at 1:38 PM, James Crook <[hidden email]> wrote:

[Moved to quality.]

On 7/15/2017 5:39 PM, Paul Licameli wrote:

I am holding out for TAB or some other key for cycling hit test targets, in
this or another release.  It seems so very obvious to me that this is very
valuable, maybe because it was an obvious problem needing solution in the
3d CAD programs I once worked on, but no less here when several things are
overlain in a small space to convey information and they are interactive
too.

I am disappointed that this idea isn't a bigger immediate hit, but I have
James with me here, and I hope to make the idea grow on the rest of you.
I
would like to put it into 2.2.0 if only as a nondefault preference.

I am fine with Tab doing that in 2.2.0, where it does not interfere with
Tab for other uses, and I am fine with Tab being not (or barely)
discoverable.  I don't want Tab in a portmanteau tooltip. It makes the
tooltip too busy and I think tooltips need to be single topic.

What are the interfering uses of Tab you are thinking of?
Labels.  Yes I know you fixed that.  I mentioned non-interference as a catch-all, just in case.

I just had another idea.  This thread is too long and I will start another.
 


I mention navigation among toolbar controls, and rotation among labels of the focused
label track.  I know I fixed interference with the latter, when it provoked
some immediate outcry.


In a 3D CAD application it is impossible to avoid things that you want to
drag ending up in the same location.  In Audacity, by careful design, it
can be made to be rare.  We could have diverse handles on clips for
dragging (position) resizing (stretch), resizing (repeat/crop)
clip-connecting, selecting (clip multiselect) without all those handles
overlapping, just by making smart choices about where to put the handles.
So I see 'Tab for resolving overlap' as a last port of call.  It comes to
the rescue when overlap is unavoidable.

I think Tab could make ingenious special handles unnecessary.  The tab
alternative might even make them objectionable as needless visual clutter.
But even if not, you do not deny the value of tab as a (not sole)
alternative.


An envelope point can overlap a sample point, when zoomed in far enough to
see sample points.  In that case Tab could come to the rescue.

Exactly one of the cases I was thinking of, as I reorganized the multi-tool
hit test code.  I mention too that if you get the Note track stretch handle
but don't want it, you hit Tab and get the select tool.

I have also implemented Tab as a way to cycle between snapping and
non-snapping selection, either before the click or after it.
That is a slippery slope, because it is not really selecting 'different things'.  Before long there will be calls to use Tab to switch between snap-to on and off, and snap-to-zero-crossings on and off.


That too might be useful if you really don't want the snap and want fine positional
control of selection bounds.
Why would I expect Tab to switch it on and off and not some setting or button somewhere?

I had contemplated Esc instead to "escape" snap lines.  That has some appeal.  Downside is overloading the other meanings of Esc to stop a drag.  Would you like to hit Esc not once but twice to escape a selection drag that is a snapped position?

But maybe you are right and I should reconsider that.  Maybe that would not be so bad that way, both before and after the click.

PRL
 




Also later when we allow layering of tracks, e.g. a label track over a
wave track, tab could be handy.  We could instead use the rule of top-track
is the one hit, but we might be forever dragging things out the way.  Tab
could be a handy way to drill down.

The scheme I currently like best is use of circular menus rather than
cycling, so that clicking Tab arranges 'bubbles' for selectable things
nicely spaced out in a circle around the cursor, and you move the mouse
onto the bubble you want.  Repeated Tab, I suppose, could walk around the
circle, rather than requiring that the mouse move. If the bubbles have
short help text, the Tab also then doubles as a way to get help on anything
solitary that is clickable.

I don't undertstand the bit about text.
Bubbles have icons and text.

Sample Bubble: Icon for a sample being dragged, and text 'change just this sample'
Envelope-point bubble: Icon for an envelope point being dragged, and text 'change envelope point position'

Text is (maybe) hyperlinked to help.




Perhaps the bubbles appear just in response to mouse motion whenever there
are multiple possibilities.  Perhaps they will jump and dance in a cute
animated fashion.

I just imagined a simpler fantasy, but still needing some work.  Do some
image manipulation, so that every cursor has an alternative form with
"[TAB]" in a tiny font, or something else, added to it.  Use that cursor
whenever a TAB cycle of more than one exists.  This makes it unnecessary to
mention Tab key in tooltips.  I hope the three letter text "TAB" need not
be internationalized too, but it might even be done.


A second scheme I like is that Right-Click gives a context menu, and the
last item in the menu is 'select' with select being a submenu listing the
nearby options.

Not sure I like that.  I think of right click as meaning "do something with
what I selected" and not the means of selection.

Common with the bubbles, it would require me to move the pointer away from
the actual target I am selecting.  I don't like that.  I think it better to
understand a convention that engages the other hand and doesn't move the
pointer.

(Or the other fingers?  Maybe thumb buttons, on the fancy mice that have
them, can be alternatives to tab, making complicated selections all
one-handed.)


Or even clicking on an ambiguous target could bring up the 'select' menu.

The schemes I like would take more design and thinking and implementation,
and would be too much for 2.2.0.

Indeed.

But I am happy to have accomplished the preliminary organization of the
multiple hit-target abstraction, independent of all this.  I must say, that
even if consensus turns against anything (even nondefault preference) in
2.2.0, still the code reorganization I have lately achieved feels very good
to me personally.  I did not have quite such a good feeling only after
rebasing my two-year old stuff.  Certain problems with my initial
reorganization became apparent, making me uncomfortable.  The thing still
felt half-done even after that earlier difficult mark was reached.  But no
longer.

more...






Just as right-click should (will?) be the universal "more actions"
convention, and as Esc key IS (!!! since 2.2.0, you're welcome) the
universal "stop this drag" convention, so too there should be a universal,
easily described and remembered, "rotate among targets" convention.

I like TAB for this purpose because it already does analogous things, as
with toolbar control navigation and the cycle of labels, and also because
it is one of the keys you can't reassign in keyboard preferences.  I think
the rotation key really should be reserved for that and not reassignable.

I do not like solutions that resort to special modifier key combinations
that are hard to remember and also lengthen the complete status bar
message.

+1

I would rather reserve shift- or control-click for a few things,
such as distinguishing new selection from adjustment, analogously with
most
text editors.

I would really dislike a resort to modifier keys such as suggested in
comment #8 here http://bugzilla.audacityteam.org/show_bug.cgi?id=800, or
solutions such as Gale has mentioned, that distinguish at button-up
whether
there was a drag or only a click, and do very unrelated things in those
two
cases.

Yes to the variety of possible actions, no to overloading Shift, Ctrl,
etc.
too much.  Yes to cursor and other appearance changes, in response to the
rotation key, that let you anticipate what a simple click and drag will
do,
before you do it.

I do not like solutions, such as what I saw James doing, changing the long
familiar appearance of things, just to fix this special case of
disambiguation of picks.

So we need to discuss drag-handles for clips.  They will be new, and we
need to decide what they look like.  We also need to discuss drag handles
for Labels.  Dragging can drag just one end, or move both ends.  To avoid
being special case we need to discuss handles as a general topic.


Steve has mentioned some inadequacies about labels, which we won't address
just now.  But I have been thinking of the problem of distinct actions for
movement of one label, versus adjustment of a chain of labels, each ending
exactly where the next starts (pick on any one of the circles); or a third
thing, moving the boundary between two abutting labels, while leaving outer
boundaries fixed.

I would simply let the tab choose among these three, when more than one is
possible for a given click point.  There can be distinct highlighting
states of the circles and chevrons.  Then after you click, there could also
be yellow snaps as with selection, and Tab switches between snapping and
non-snapping during drag, as is now done during selection.
And we should think of using the same idiom for labels and for clips.

For example, Ctrl-I in the text of a label should split the text into two labels at the text cursor.

Moving a label without changing size is really multi-select.  You are selecting both ends of a label and dragging both at the same time.

--James




These possibilities are more easily open with the code reorganization.

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