Preview snap lines; revisiting Bug 800

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

Preview snap lines; revisiting Bug 800

Paul Licameli
I hope Gale enjoys this present.

At commit 9072628b4cd194dcfc85702df46daa0c1e55393c

I implemented something I promised earlier:  Yellow snap lines appear before button-down, and if you do button-down then the snap applies.

Try it in a project with labels.

So, either or both ends of a selection drag can snap.  If you want the left edge of your selection to snap, you don't have to drag right-to-left.  If you want both ends to snap, you don't need to drag first one way, then release, then shift-drag to adjust the other end.

You can also hit TAB, either before button down or during drag, to toggle snapping off.  So maybe you want to make a fine selection near a snap boundary but not exactly on it.  You can do that now without increasing magnification to avoid the snapping.

I also undid James' change of cursor to finger when exactly over a cutline, as unnecessary.

Now the question arises:  Do we still really want the other thing James did related to Bug 800, the change in appearance of the split lines?

Suppose not.  Alternatives:
  1. We accept the TAB key cycling as a sufficient fix for the difficulty.  But the objection might be that it isn't discoverable enough.  Do we add a status message hint?
  2. We keep the old appearance of split lines, but just change the hot zone for hitting them to be a part of their height.  Then, a user who doesn't know about TAB could still discover that the cursor changes to arrow at some heights, but the yellow snap appears at other heights.
  3. As (2) but also we light up the split line when it is the hit test target, as in EXPERIMENTAL_TRACK_PANEL_HIGHLIGHTING, but choosing other colors than the intentionaly ugly ones I used there.
Other questions arise.  Should the same TAB toggling be done for snap lines in time-shift?  Dragging of labels doesn't snap at all, but should it?  These lesser used tools, however, I am determined to ignore for now, as I catch up in review of the pending MIDI playback improvements.

PRL


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

Re: Preview snap lines; revisiting Bug 800

Gale
Administrator
On 13 July 2017 at 17:59, Paul Licameli <[hidden email]> wrote:

> I hope Gale enjoys this present.
>
> At commit 9072628b4cd194dcfc85702df46daa0c1e55393c
>
> I implemented something I promised earlier:  Yellow snap lines appear before
> button-down, and if you do button-down then the snap applies.
>
> Try it in a project with labels.
>
> So, either or both ends of a selection drag can snap.  If you want the left
> edge of your selection to snap, you don't have to drag right-to-left.  If
> you want both ends to snap, you don't need to drag first one way, then
> release, then shift-drag to adjust the other end.
>
> You can also hit TAB, either before button down or during drag, to toggle
> snapping off.  So maybe you want to make a fine selection near a snap
> boundary but not exactly on it.  You can do that now without increasing
> magnification to avoid the snapping.

I don't fully understand this and wonder if it is discoverable.

I'd have thought if you get the snap guide with mouse up and click and
release then you merge. If you click and drag you select. This happens
whatever Y point we use, i.e. we don't want the strange central area
of the split line which merges. In particular we want the same visibility
for a split line after moving away from it as when created - not a much
thinner line (which I can barely see).

This makes sense to me if TAB merely toggles the Snap Guide. Is that
all it does?


Gale


> I also undid James' change of cursor to finger when exactly over a cutline,
> as unnecessary.
>
> Now the question arises:  Do we still really want the other thing James did
> related to Bug 800, the change in appearance of the split lines?
>
> Suppose not.  Alternatives:
>
> We accept the TAB key cycling as a sufficient fix for the difficulty.  But
> the objection might be that it isn't discoverable enough.  Do we add a
> status message hint?
> We keep the old appearance of split lines, but just change the hot zone for
> hitting them to be a part of their height.  Then, a user who doesn't know
> about TAB could still discover that the cursor changes to arrow at some
> heights, but the yellow snap appears at other heights.
> As (2) but also we light up the split line when it is the hit test target,
> as in EXPERIMENTAL_TRACK_PANEL_HIGHLIGHTING, but choosing other colors than
> the intentionaly ugly ones I used there.
>
> Other questions arise.  Should the same TAB toggling be done for snap lines
> in time-shift?  Dragging of labels doesn't snap at all, but should it?
> These lesser used tools, however, I am determined to ignore for now, as I
> catch up in review of the pending MIDI playback improvements.
>
> PRL
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

Re: Preview snap lines; revisiting Bug 800

Paul Licameli


On Thu, Jul 13, 2017 at 3:01 PM, Gale Andrews <[hidden email]> wrote:
On 13 July 2017 at 17:59, Paul Licameli <[hidden email]> wrote:
> I hope Gale enjoys this present.
>
> At commit 9072628b4cd194dcfc85702df46daa0c1e55393c
>
> I implemented something I promised earlier:  Yellow snap lines appear before
> button-down, and if you do button-down then the snap applies.
>
> Try it in a project with labels.
>
> So, either or both ends of a selection drag can snap.  If you want the left
> edge of your selection to snap, you don't have to drag right-to-left.  If
> you want both ends to snap, you don't need to drag first one way, then
> release, then shift-drag to adjust the other end.
>
> You can also hit TAB, either before button down or during drag, to toggle
> snapping off.  So maybe you want to make a fine selection near a snap
> boundary but not exactly on it.  You can do that now without increasing
> magnification to avoid the snapping.

I don't fully understand this and wonder if it is discoverable.

True, the TAB key part may not be very discoverable, but the pre-highlighting of snap positions before button down is very obvious -- try it with some labels but no split lines.  Don't you agree?
 
I'd have thought if you get the snap guide with mouse up and click and
release then you merge. If you click and drag you select.

I don't like that proposal, for one, because a third possibility is that you want a point selection at the edge, by clicking and releasing with no drag.  How to distinguish that?  Better I think to do that with cursor changes and snap lines before you click.

But as things stand now, you can do it with different Y coordinates.  Which I don't necessarily like.  But TAB key gives you another way that you can still choose among all three, if only you discover the TAB.
 
This happens
whatever Y point we use, i.e. we don't want the strange central area
of the split line which merges.

So you dislike the appearance and hit test changes added at dc1193a0af83f1d43de5a30aea6b6b09087eea58 ?  I am not very pleased with them either but did not presume to change it.

Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 (the finger cursor) was a hasty solution that shouldn't stand, and even James seemed to agree about that.

In particular we want the same visibility
for a split line after moving away from it as when created - not a much
thinner line (which I can barely see).

So that's another vote against the display change?
 

This makes sense to me if TAB merely toggles the Snap Guide. Is that
all it does?

TAB is intended to do more.  See other email discussions from today.  I want TAB or some other key to disambiguate hit targets that are all at the same x and y coordinates.

For instance, in Note track, TAB key toggles the stretch cursor off, and gives you just the plain select cursor, before you click, if that is what you want. TAB in multi-tool and in a wave track can even cycle among four things, cut line, envelope, sample, and select, when all are possible at the same point.

I want TAB key cycling as an aid to some possible future developments after 2.2.0.  For instance, clips might overlap and have adjustable cross-fade zones at their edges.  TAB key might be the way to choose those for adjustments rather than other things.

TAB key cycling might be what lets us get rid of the Tools toolbar, or to simplify it (I think, to just a Multi-select tool and a Zoom tool), which is an ambition James agrees with.

PRL

 


Gale


> I also undid James' change of cursor to finger when exactly over a cutline,
> as unnecessary.
>
> Now the question arises:  Do we still really want the other thing James did
> related to Bug 800, the change in appearance of the split lines?
>
> Suppose not.  Alternatives:
>
> We accept the TAB key cycling as a sufficient fix for the difficulty.  But
> the objection might be that it isn't discoverable enough.  Do we add a
> status message hint?
> We keep the old appearance of split lines, but just change the hot zone for
> hitting them to be a part of their height.  Then, a user who doesn't know
> about TAB could still discover that the cursor changes to arrow at some
> heights, but the yellow snap appears at other heights.
> As (2) but also we light up the split line when it is the hit test target,
> as in EXPERIMENTAL_TRACK_PANEL_HIGHLIGHTING, but choosing other colors than
> the intentionaly ugly ones I used there.
>
> Other questions arise.  Should the same TAB toggling be done for snap lines
> in time-shift?  Dragging of labels doesn't snap at all, but should it?
> These lesser used tools, however, I am determined to ignore for now, as I
> catch up in review of the pending MIDI playback improvements.
>
> PRL
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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


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

Re: Preview snap lines; revisiting Bug 800

James Crook
On 7/13/2017 10:10 PM, Paul Licameli wrote:

> Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
> (the finger cursor) was a hasty solution that shouldn't stand, and even
> James seemed to agree about that.
Split SplitLines, as in
https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
seem to me a workable/acceptable way of allowing selection and also
split line removal at the exact same x coordinate.

https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 
is kind of 'virtual cursors', where every split line is a virtual
cursor.  Virtual cursors aren't a bad idea, but do need more thought.  
For example it could make sense for every clip boundary/snap-line to be
a virtual cursor.    My implementation is only 1px wide, which is not
consistent with true cursor.  My code is also, kind of, minimum effort
to get the result, and I totally accept less hacky implementation is
possible.

I think virtual cursors are unnecessary, but I did want to close Bug 800
quickly, and Gale felt that the cursor change and status message change
were essential.

Gale gave Bug 800 a P2.  That makes it an RM decides.
https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 
probably makes it possible to close Bug 800.  But it is also totally OK
for RM to decide that
https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 
is bad for the code, and that 'virtual cursors' should therefore be
postponed, and live with the P2, suitably updated, for 2.2.0.

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

Re: Preview snap lines; revisiting Bug 800

Stevethefiddle
I thought that we had agreed to leave this Tab cycling stuff until
after 2.2.0. I strongly think we should. If we continue with it I fear
that we will either be releasing a highly visible new feature that is
nowhere near ready for release, or the release will be massively
delayed. We were very close to a good new release with lots of bug
fixes and new features a month ago. We now appear to be further away
from release with a spate of new bugs appearing (including very high
priority bugs) and now this highly visible and contentious (and buggy)
new feature.

Steve

On 14 July 2017 at 10:07, James Crook <[hidden email]> wrote:

> On 7/13/2017 10:10 PM, Paul Licameli wrote:
>
>> Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>> (the finger cursor) was a hasty solution that shouldn't stand, and even
>> James seemed to agree about that.
>
> Split SplitLines, as in
> https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
> seem to me a workable/acceptable way of allowing selection and also split
> line removal at the exact same x coordinate.
>
> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
> is kind of 'virtual cursors', where every split line is a virtual cursor.
> Virtual cursors aren't a bad idea, but do need more thought.  For example it
> could make sense for every clip boundary/snap-line to be a virtual cursor.
> My implementation is only 1px wide, which is not consistent with true
> cursor.  My code is also, kind of, minimum effort to get the result, and I
> totally accept less hacky implementation is possible.
>
> I think virtual cursors are unnecessary, but I did want to close Bug 800
> quickly, and Gale felt that the cursor change and status message change were
> essential.
>
> Gale gave Bug 800 a P2.  That makes it an RM decides.
> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
> probably makes it possible to close Bug 800.  But it is also totally OK for
> RM to decide that
> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
> is bad for the code, and that 'virtual cursors' should therefore be
> postponed, and live with the P2, suitably updated, for 2.2.0.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

Re: Preview snap lines; revisiting Bug 800

Peter Sampson-2
+1 to what Steve says here

comments in-line below

On Fri, Jul 14, 2017 at 11:25 AM, Steve the Fiddle <[hidden email]> wrote:
I thought that we had agreed to leave this Tab cycling stuff until
after 2.2.0. I strongly think we should. If we continue with it I fear
that we will either be releasing a highly visible new feature that is
nowhere near ready for release, or the release will be massively
delayed.

I agree - and this is anew feature that has not been discussed fully and for which
there was no proposal or design document.  It doesn'y need to be elaborate
but such things help when it comes to testing and documentation.  As it is now
it is extremely hard to follow the many small commits.

This sort of change is the sort of thing that should be attempted at the beginning
of a development cycle, not roght at the end as we are about to move to release
cycle - else we don't get enough time to test and appriase the potential changes.

 
We were very close to a good new release with lots of bug
fixes and new features a month ago.

Yes we had more than enough visible new features for a new release, as Steve
says, with themes and menu roroganization etc.

 
We now appear to be further away
from release with a spate of new bugs appearing (including very high
priority bugs) and now this highly visible and contentious (and buggy)
new feature.

Yes, this worries me greatly.  We are now almost four months away since the
last release 2.1.3 on 17Mar17 - and it will likely be at least another month
before we get 2.2.0 out the door (if not longer).

We really should be aiming to get more regular releases out the door, as was
discussed three years ago at AU14, to show that we are and active dynamic
project.

Peter

 

Steve

On 14 July 2017 at 10:07, James Crook <[hidden email]> wrote:
> On 7/13/2017 10:10 PM, Paul Licameli wrote:
>
>> Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>> (the finger cursor) was a hasty solution that shouldn't stand, and even
>> James seemed to agree about that.
>
> Split SplitLines, as in
> https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
> seem to me a workable/acceptable way of allowing selection and also split
> line removal at the exact same x coordinate.
>
> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
> is kind of 'virtual cursors', where every split line is a virtual cursor.
> Virtual cursors aren't a bad idea, but do need more thought.  For example it
> could make sense for every clip boundary/snap-line to be a virtual cursor.
> My implementation is only 1px wide, which is not consistent with true
> cursor.  My code is also, kind of, minimum effort to get the result, and I
> totally accept less hacky implementation is possible.
>
> I think virtual cursors are unnecessary, but I did want to close Bug 800
> quickly, and Gale felt that the cursor change and status message change were
> essential.
>
> Gale gave Bug 800 a P2.  That makes it an RM decides.
> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
> probably makes it possible to close Bug 800.  But it is also totally OK for
> RM to decide that
> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
> is bad for the code, and that 'virtual cursors' should therefore be
> postponed, and live with the P2, suitably updated, for 2.2.0.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

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


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

Re: Preview snap lines; revisiting Bug 800

Paul Licameli
In reply to this post by James Crook


On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
On 7/13/2017 10:10 PM, Paul Licameli wrote:

Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
(the finger cursor) was a hasty solution that shouldn't stand, and even
James seemed to agree about that.
Split SplitLines, as in https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
seem to me a workable/acceptable way of allowing selection and also split line removal at the exact same x coordinate.

https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 is kind of 'virtual cursors', where every split line is a virtual cursor.  Virtual cursors aren't a bad idea, but do need more thought.  For example it could make sense for every clip boundary/snap-line to be a virtual cursor.    My implementation is only 1px wide, which is not consistent with true cursor.  My code is also, kind of, minimum effort to get the result, and I totally accept less hacky implementation is possible.

I think virtual cursors are unnecessary, but I did want to close Bug 800 quickly, and Gale felt that the cursor change and status message change were essential.

Gale gave Bug 800 a P2.  That makes it an RM decides. https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 probably makes it possible to close Bug 800.  But it is also totally OK for RM to decide that https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 is bad for the code, and that 'virtual cursors' should therefore be postponed, and live with the P2, suitably updated, for 2.2.0.

I say aa8be0c4 was a non-solution to the problem.

Merely by changing the cursor, it aided the user in making a click close to the split line, measured in pixels.  But how close is that in time terms?  That is variable with magnification, and so you would still not get the exactitude you really want in the selection.

But the snapping code is intended to give that, independent of magnification.  A true solution of bug 800 really needs it.

PRL
 


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


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

Re: Preview snap lines; revisiting Bug 800

Peter Sampson-2
We could fix Bug 800 in a simpler way it seems to me:

1) revert out clip lines to the simple ones that we have always
had in 2.1.3 and earlier.

2) Do *not* allow left-click on a clip line to delete it
(this is one of the major problems here)

3) Use right-click to delete the slpit line - or use right-click to pop a
dropdown menu with "Delete Clip line" in it.

4) I do like the way that the clip lines show the yellow snap guide as you
move the cursor close to the split line (without needing the left click).


Personally, apart form the removal of the clip line with the left click, I have
never found it "too hard" to select with clips/clip boundaries - as Bug 800
states:

a) to partially select just clip outside.inside the clip and drag to the clip edge
where the yellow snap guide appears - simple,

b) to select the whole clip just doble click inside it - even simpler.

Peter.



On Fri, Jul 14, 2017 at 1:03 PM, Paul Licameli <[hidden email]> wrote:


On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
On 7/13/2017 10:10 PM, Paul Licameli wrote:

Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
(the finger cursor) was a hasty solution that shouldn't stand, and even
James seemed to agree about that.
Split SplitLines, as in https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
seem to me a workable/acceptable way of allowing selection and also split line removal at the exact same x coordinate.

https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 is kind of 'virtual cursors', where every split line is a virtual cursor.  Virtual cursors aren't a bad idea, but do need more thought.  For example it could make sense for every clip boundary/snap-line to be a virtual cursor.    My implementation is only 1px wide, which is not consistent with true cursor.  My code is also, kind of, minimum effort to get the result, and I totally accept less hacky implementation is possible.

I think virtual cursors are unnecessary, but I did want to close Bug 800 quickly, and Gale felt that the cursor change and status message change were essential.

Gale gave Bug 800 a P2.  That makes it an RM decides. https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 probably makes it possible to close Bug 800.  But it is also totally OK for RM to decide that https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 is bad for the code, and that 'virtual cursors' should therefore be postponed, and live with the P2, suitably updated, for 2.2.0.

I say aa8be0c4 was a non-solution to the problem.

Merely by changing the cursor, it aided the user in making a click close to the split line, measured in pixels.  But how close is that in time terms?  That is variable with magnification, and so you would still not get the exactitude you really want in the selection.

But the snapping code is intended to give that, independent of magnification.  A true solution of bug 800 really needs it.

PRL
 


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


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



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

Re: Preview snap lines; revisiting Bug 800

Stevethefiddle
The thing that is bugging me is that we are having a protracted
discussion about a minor enhancement (as far as I'm aware there has
only ever been one person out of millions that considered bug 800 to
be more than a minor issue), when we should be preparing for a major
new release. There are many possible solutions to bug 800, some of
which disadvantage as many or more users than they benefit, so we
should not be rushing to a solution imo, but more to the point we
should not be spending so much time on this now when there are far
more importing issues, such as the 52! P1 and P2 bugs that aren't yet
FIX MADE.

Steve

On 14 July 2017 at 13:16, Peter Sampson <[hidden email]> wrote:

> We could fix Bug 800 in a simpler way it seems to me:
>
> 1) revert out clip lines to the simple ones that we have always
> had in 2.1.3 and earlier.
>
> 2) Do *not* allow left-click on a clip line to delete it
> (this is one of the major problems here)
>
> 3) Use right-click to delete the slpit line - or use right-click to pop a
> dropdown menu with "Delete Clip line" in it.
>
> 4) I do like the way that the clip lines show the yellow snap guide as you
> move the cursor close to the split line (without needing the left click).
>
>
> Personally, apart form the removal of the clip line with the left click, I
> have
> never found it "too hard" to select with clips/clip boundaries - as Bug 800
> states:
>
> a) to partially select just clip outside.inside the clip and drag to the
> clip edge
> where the yellow snap guide appears - simple,
>
> b) to select the whole clip just doble click inside it - even simpler.
>
> Peter.
>
>
>
> On Fri, Jul 14, 2017 at 1:03 PM, Paul Licameli <[hidden email]>
> wrote:
>>
>>
>>
>> On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
>>>
>>> On 7/13/2017 10:10 PM, Paul Licameli wrote:
>>>
>>>> Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>>> (the finger cursor) was a hasty solution that shouldn't stand, and even
>>>> James seemed to agree about that.
>>>
>>> Split SplitLines, as in
>>> https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
>>> seem to me a workable/acceptable way of allowing selection and also split
>>> line removal at the exact same x coordinate.
>>>
>>>
>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>> is kind of 'virtual cursors', where every split line is a virtual cursor.
>>> Virtual cursors aren't a bad idea, but do need more thought.  For example it
>>> could make sense for every clip boundary/snap-line to be a virtual cursor.
>>> My implementation is only 1px wide, which is not consistent with true
>>> cursor.  My code is also, kind of, minimum effort to get the result, and I
>>> totally accept less hacky implementation is possible.
>>>
>>> I think virtual cursors are unnecessary, but I did want to close Bug 800
>>> quickly, and Gale felt that the cursor change and status message change were
>>> essential.
>>>
>>> Gale gave Bug 800 a P2.  That makes it an RM decides.
>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>> probably makes it possible to close Bug 800.  But it is also totally OK for
>>> RM to decide that
>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>> is bad for the code, and that 'virtual cursors' should therefore be
>>> postponed, and live with the P2, suitably updated, for 2.2.0.
>>
>>
>> I say aa8be0c4 was a non-solution to the problem.
>>
>> Merely by changing the cursor, it aided the user in making a click close
>> to the split line, measured in pixels.  But how close is that in time terms?
>> That is variable with magnification, and so you would still not get the
>> exactitude you really want in the selection.
>>
>> But the snapping code is intended to give that, independent of
>> magnification.  A true solution of bug 800 really needs it.
>>
>> PRL
>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

Re: Preview snap lines; revisiting Bug 800

Paul Licameli
In reply to this post by Peter Sampson-2


On Fri, Jul 14, 2017 at 8:16 AM, Peter Sampson <[hidden email]> wrote:
We could fix Bug 800 in a simpler way it seems to me:

1) revert out clip lines to the simple ones that we have always
had in 2.1.3 and earlier.

I favor this.
 

2) Do *not* allow left-click on a clip line to delete it
(this is one of the major problems here)

3) Use right-click to delete the slpit line - or use right-click to pop a
dropdown menu with "Delete Clip line" in it.

Good idea to have context menus.  Not this release.
 

4) I do like the way that the clip lines show the yellow snap guide as you
move the cursor close to the split line (without needing the left click).

I was hoping you would,  If we do (1) then you would not see the line until after hitting TAB once.  You would also be clued about TAB by the new tooltips.  Have you seen those tooltips yet?
 


Personally, apart form the removal of the clip line with the left click, I have
never found it "too hard" to select with clips/clip boundaries - as Bug 800
states:

a) to partially select just clip outside.inside the clip and drag to the clip edge
where the yellow snap guide appears - simple,

There was not until now a good way to make a single selection that snaps visibly both at the start and the end.
 

b) to select the whole clip just doble click inside it - even simpler.

Simple, but not general enough.  Because boundaries of the clip that the pointer is in, are not the only positions where you can snap.  There may be labels and there may be clip boundaries in other tracks.

So I say these ideas aren't good enough.

PRL

 


Peter.



On Fri, Jul 14, 2017 at 1:03 PM, Paul Licameli <[hidden email]> wrote:


On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
On 7/13/2017 10:10 PM, Paul Licameli wrote:

Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
(the finger cursor) was a hasty solution that shouldn't stand, and even
James seemed to agree about that.
Split SplitLines, as in https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
seem to me a workable/acceptable way of allowing selection and also split line removal at the exact same x coordinate.

https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 is kind of 'virtual cursors', where every split line is a virtual cursor.  Virtual cursors aren't a bad idea, but do need more thought.  For example it could make sense for every clip boundary/snap-line to be a virtual cursor.    My implementation is only 1px wide, which is not consistent with true cursor.  My code is also, kind of, minimum effort to get the result, and I totally accept less hacky implementation is possible.

I think virtual cursors are unnecessary, but I did want to close Bug 800 quickly, and Gale felt that the cursor change and status message change were essential.

Gale gave Bug 800 a P2.  That makes it an RM decides. https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 probably makes it possible to close Bug 800.  But it is also totally OK for RM to decide that https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 is bad for the code, and that 'virtual cursors' should therefore be postponed, and live with the P2, suitably updated, for 2.2.0.

I say aa8be0c4 was a non-solution to the problem.

Merely by changing the cursor, it aided the user in making a click close to the split line, measured in pixels.  But how close is that in time terms?  That is variable with magnification, and so you would still not get the exactitude you really want in the selection.

But the snapping code is intended to give that, independent of magnification.  A true solution of bug 800 really needs it.

PRL
 


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


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



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



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

Re: Preview snap lines; revisiting Bug 800

James Crook
In reply to this post by Paul Licameli
On 7/14/2017 1:03 PM, Paul Licameli wrote:

> On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
>
>> On 7/13/2017 10:10 PM, Paul Licameli wrote:
>>
>> Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>> (the finger cursor) was a hasty solution that shouldn't stand, and even
>>> James seemed to agree about that.
>>>
>> Split SplitLines, as in https://github.com/audacity/au
>> dacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
>> seem to me a workable/acceptable way of allowing selection and also split
>> line removal at the exact same x coordinate.
>>
>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>> fd03e0b85bdf097b2ed37de9 is kind of 'virtual cursors', where every split
>> line is a virtual cursor.  Virtual cursors aren't a bad idea, but do need
>> more thought.  For example it could make sense for every clip
>> boundary/snap-line to be a virtual cursor.    My implementation is only 1px
>> wide, which is not consistent with true cursor.  My code is also, kind of,
>> minimum effort to get the result, and I totally accept less hacky
>> implementation is possible.
>>
>> I think virtual cursors are unnecessary, but I did want to close Bug 800
>> quickly, and Gale felt that the cursor change and status message change
>> were essential.
>>
>> Gale gave Bug 800 a P2.  That makes it an RM decides.
>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>> fd03e0b85bdf097b2ed37de9 probably makes it possible to close Bug 800.
>> But it is also totally OK for RM to decide that
>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>> fd03e0b85bdf097b2ed37de9 is bad for the code, and that 'virtual cursors'
>> should therefore be postponed, and live with the P2, suitably updated, for
>> 2.2.0.
>
> I say aa8be0c4 was a non-solution to the problem.
>
> Merely by changing the cursor, it aided the user in making a click close to
> the split line, measured in pixels.  But how close is that in time terms?
> That is variable with magnification, and so you would still not get the
> exactitude you really want in the selection.
I agree, and go slightly further, and say it is a non solution to a non
problem.  Steve also commented that Bug 800 did not merit a P2 rating.  
Given it had that rating, I wanted it closed.  There are many other more
important P2s that it distracts from.  I am of course also fine if you
revert aa8be0c4 and as RM you're entitled to go through to release with
Bug 800 present.


>
> But the snapping code is intended to give that, independent of
> magnification.  A true solution of bug 800 really needs it.
>
> PRL
>
>


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

Re: Preview snap lines; revisiting Bug 800

Paul Licameli


On Fri, Jul 14, 2017 at 10:06 AM, James Crook <[hidden email]> wrote:
On 7/14/2017 1:03 PM, Paul Licameli wrote:
On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:

On 7/13/2017 10:10 PM, Paul Licameli wrote:

Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
(the finger cursor) was a hasty solution that shouldn't stand, and even
James seemed to agree about that.

Split SplitLines, as in https://github.com/audacity/au
dacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
seem to me a workable/acceptable way of allowing selection and also split
line removal at the exact same x coordinate.

https://github.com/audacity/audacity/commit/aa8be0c413d107e3
fd03e0b85bdf097b2ed37de9 is kind of 'virtual cursors', where every split
line is a virtual cursor.  Virtual cursors aren't a bad idea, but do need
more thought.  For example it could make sense for every clip
boundary/snap-line to be a virtual cursor.    My implementation is only 1px
wide, which is not consistent with true cursor.  My code is also, kind of,
minimum effort to get the result, and I totally accept less hacky
implementation is possible.

I think virtual cursors are unnecessary, but I did want to close Bug 800
quickly, and Gale felt that the cursor change and status message change
were essential.

Gale gave Bug 800 a P2.  That makes it an RM decides.
https://github.com/audacity/audacity/commit/aa8be0c413d107e3
fd03e0b85bdf097b2ed37de9 probably makes it possible to close Bug 800.
But it is also totally OK for RM to decide that
https://github.com/audacity/audacity/commit/aa8be0c413d107e3
fd03e0b85bdf097b2ed37de9 is bad for the code, and that 'virtual cursors'
should therefore be postponed, and live with the P2, suitably updated, for
2.2.0.

I say aa8be0c4 was a non-solution to the problem.

Merely by changing the cursor, it aided the user in making a click close to
the split line, measured in pixels.  But how close is that in time terms?
That is variable with magnification, and so you would still not get the
exactitude you really want in the selection.
I agree, and go slightly further, and say it is a non solution to a non problem.

Actually, I must retract this criticism.  When the starting click is in snapping distance of a snap point (not necessarily a split line), the adjustment really is made at button down.  You can observe that in 2.1.3.  So it was making the precise selection you want.

But as for giving the user an improved visual guide to that snap (there was no such guide in 2.1.3), I still don't like the finger, with its hot zone only one pixel wide.  I would rather do nothing or do the work of making a yellow snap line just as for other snaps.
 
Steve also commented that Bug 800 did not merit a P2 rating.  Given it had that rating, I wanted it closed.  There are many other more important P2s that it distracts from.  I am of course also fine if you revert aa8be0c4 and as RM you're entitled to go through to release with Bug 800 present.

I am asking for a fair consideration of my recent work.  I felt better presenting an alternative than just reverting your work based on some personal opinions.
 

PRL





But the snapping code is intended to give that, independent of
magnification.  A true solution of bug 800 really needs it.

PRL




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


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

Re: Preview snap lines; revisiting Bug 800

Gale
Administrator
In reply to this post by Paul Licameli
On 14 July 2017 at 13:03, Paul Licameli <[hidden email]> wrote:

>
>
> On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
>>
>> On 7/13/2017 10:10 PM, Paul Licameli wrote:
>>
>>> Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>> (the finger cursor) was a hasty solution that shouldn't stand, and even
>>> James seemed to agree about that.
>>
>> Split SplitLines, as in
>> https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
>> seem to me a workable/acceptable way of allowing selection and also split
>> line removal at the exact same x coordinate.
>>
>>
>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>> is kind of 'virtual cursors', where every split line is a virtual cursor.
>> Virtual cursors aren't a bad idea, but do need more thought.  For example it
>> could make sense for every clip boundary/snap-line to be a virtual cursor.
>> My implementation is only 1px wide, which is not consistent with true
>> cursor.  My code is also, kind of, minimum effort to get the result, and I
>> totally accept less hacky implementation is possible.
>>
>> I think virtual cursors are unnecessary, but I did want to close Bug 800
>> quickly, and Gale felt that the cursor change and status message change were
>> essential.
>>
>> Gale gave Bug 800 a P2.  That makes it an RM decides.
>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>> probably makes it possible to close Bug 800.  But it is also totally OK for
>> RM to decide that
>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>> is bad for the code, and that 'virtual cursors' should therefore be
>> postponed, and live with the P2, suitably updated, for 2.2.0.
>
>
> I say aa8be0c4 was a non-solution to the problem.

+1. I think it was a non-standard solution inferior to Paul's solution,
though I supported aa8be0c4 at the time because it was on offer and
an improvement.

I am now very unconvinced by
https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58

I think we would be creating a new bug that "Split lines are not visible
enough" and be getting complaints from those who do want to merge.
In a spiky passage around +/-0.0, on returning to the split line after
clicking elsewhere I can't even see the broader part of the split line
unless I knew it was there anyway, so am reliant on figuring out to
use the Status Bar.

It's true doing away with this change and having click and drag select
makes it harder to select the line. In practice doing that was very rarely
complained about in my experience - selecting from the split line was
the "bugbear". You can select then use left arrow to select the split line.

OTOH people who just select from the central area of the line because it's
"where the song waves are" will still delete the line when they click and
drag. And that would not close the bug IMO.

TAB could toggle Snap as you intend. If you do that you see the yellow
border line but the line is forced throughout its height as a line to select
from. Click will not merge but will select the line.

Or use Option (Alt) click to disallow click to merge - it selects the line.

Sorry, this is how I feel about it right now.


Gale


> Merely by changing the cursor, it aided the user in making a click close to
> the split line, measured in pixels.  But how close is that in time terms?
> That is variable with magnification, and so you would still not get the
> exactitude you really want in the selection.
>
> But the snapping code is intended to give that, independent of
> magnification.  A true solution of bug 800 really needs it.
>
> PRL
>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

Re: Preview snap lines; revisiting Bug 800

Paul Licameli
In reply to this post by James Crook


On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
On 7/13/2017 10:10 PM, Paul Licameli wrote:

Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
(the finger cursor) was a hasty solution that shouldn't stand, and even
James seemed to agree about that.
Split SplitLines, as in https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
seem to me a workable/acceptable way of allowing selection and also split line removal at the exact same x coordinate.

https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 is kind of 'virtual cursors', where every split line is a virtual cursor.  Virtual cursors aren't a bad idea, but do need more thought.  For example it could make sense for every clip boundary/snap-line to be a virtual cursor.    My implementation is only 1px wide, which is not consistent with true cursor.  My code is also, kind of, minimum effort to get the result, and I totally accept less hacky implementation is possible.

I think virtual cursors are unnecessary, but I did want to close Bug 800 quickly, and Gale felt that the cursor change and status message change were essential.


(What I don't understand about your comments.  Commit aa8be0c was about, simply, a cursor.  Explain "virtual.")
 
Gale gave Bug 800 a P2.  That makes it an RM decides. https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 probably makes it possible to close Bug 800.  But it is also totally OK for RM to decide that https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9 is bad for the code, and that 'virtual cursors' should therefore be postponed, and live with the P2, suitably updated, for 2.2.0.

There is one important thing to find agreement on soon:  whether to keep the appearance change in split lines, which affects Peter's work.  I am not yet dictating it but will vote, -1.

The change is from the earlier of James' two commits at issue, dc1193a, not part of the theming project.

I dislike it, not as strongly as the later aa8be0c which changed the cursor, but I do dislike it too.  Gale has said he dislikes it, making the split line "too thin" for visibility -- I think this means the more prominent top and bottom are too thin.

And at bottom I got the sense of a hasty and too special-case fix of what is really a more general problem -- what to do when there is more than one thing you may want to interact with near the pointer.  And that is something I have been thinking about, and preparing much groundwork for, for more reasons than just this bug.

So I want to fix 800 by better, general, means, or just not fix it now.  But I have also worked on the "other means" -- the Tab key, the changes in selection snapping, and the tooltips that aid in discovering these.  (These three things are separable.  You can give me opinions about then separately.)  I will lobby hard for the features or something like them in 2.2.1, if they are not in sooner.

I would like them sooner.  So please, try them, and give me opinions.

I think they are the right direction to go.  Tab key can lead to abolishing the Tools toolbar, and also let us add interactive things to TrackPanel without needing to make more toolbar buttons.  Tab key can also escape snapping selection when you don't want it.  I think all of this is very valuable.

But besides this, if the visible feature is not in, what will certainly be in, for the sake of future development, is a lot of the difficult internals work that make the feature easy to add.  Getting this work right is a major reason why the schedule slipped a bit, and I am not apologizing for insisting on making it right for 2.2.0.  I had come to realize that the state of things at https://github.com/audacity/audacity/commit/6eac877de6453542dc278b2439eb0f9c983cee89 was a halfway state that wasn't good enough, that the sort of problem James fixed at http://bugzilla.audacityteam.org/show_bug.cgi?id=1677 needed more comprehensive work to be sure there were not others like it, and now that work is accomplished.  I was thinking that when we go for a beta testing period, then I want to load more of these needed internal changes in to get more benefit from that period and lessen the motivation to do a beta period again in the next release.

PRL
 


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


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

Re: Preview snap lines; revisiting Bug 800

Gale
Administrator
In reply to this post by Stevethefiddle
On 14 July 2017 at 13:58, Steve the Fiddle <[hidden email]> wrote:
> The thing that is bugging me is that we are having a protracted
> discussion about a minor enhancement (as far as I'm aware there has
> only ever been one person out of millions that considered bug 800 to
> be more than a minor issue)

This is nonsense/exaggeration. But it is P2 not P1 and RM sees it as
worth pursuing. I am not convinced the positional solution with thicker
centre is good so RM could decide to let this P2 through till 2.2.1.

I do see a solution fits with wider goals.

The extra Status Bar messages and highlighting and hit targets are not
rated. I am less sure why we are pursuing them given the testing and
wider bug risk.


Gale


>  when we should be preparing for a major
> new release. There are many possible solutions to bug 800, some of
> which disadvantage as many or more users than they benefit, so we
> should not be rushing to a solution imo, but more to the point we
> should not be spending so much time on this now when there are far
> more importing issues, such as the 52! P1 and P2 bugs that aren't yet
> FIX MADE.
>
> Steve
>
> On 14 July 2017 at 13:16, Peter Sampson <[hidden email]> wrote:
>> We could fix Bug 800 in a simpler way it seems to me:
>>
>> 1) revert out clip lines to the simple ones that we have always
>> had in 2.1.3 and earlier.
>>
>> 2) Do *not* allow left-click on a clip line to delete it
>> (this is one of the major problems here)
>>
>> 3) Use right-click to delete the slpit line - or use right-click to pop a
>> dropdown menu with "Delete Clip line" in it.
>>
>> 4) I do like the way that the clip lines show the yellow snap guide as you
>> move the cursor close to the split line (without needing the left click).
>>
>>
>> Personally, apart form the removal of the clip line with the left click, I
>> have
>> never found it "too hard" to select with clips/clip boundaries - as Bug 800
>> states:
>>
>> a) to partially select just clip outside.inside the clip and drag to the
>> clip edge
>> where the yellow snap guide appears - simple,
>>
>> b) to select the whole clip just doble click inside it - even simpler.
>>
>> Peter.
>>
>>
>>
>> On Fri, Jul 14, 2017 at 1:03 PM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
>>>>
>>>> On 7/13/2017 10:10 PM, Paul Licameli wrote:
>>>>
>>>>> Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>>>> (the finger cursor) was a hasty solution that shouldn't stand, and even
>>>>> James seemed to agree about that.
>>>>
>>>> Split SplitLines, as in
>>>> https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
>>>> seem to me a workable/acceptable way of allowing selection and also split
>>>> line removal at the exact same x coordinate.
>>>>
>>>>
>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>>> is kind of 'virtual cursors', where every split line is a virtual cursor.
>>>> Virtual cursors aren't a bad idea, but do need more thought.  For example it
>>>> could make sense for every clip boundary/snap-line to be a virtual cursor.
>>>> My implementation is only 1px wide, which is not consistent with true
>>>> cursor.  My code is also, kind of, minimum effort to get the result, and I
>>>> totally accept less hacky implementation is possible.
>>>>
>>>> I think virtual cursors are unnecessary, but I did want to close Bug 800
>>>> quickly, and Gale felt that the cursor change and status message change were
>>>> essential.
>>>>
>>>> Gale gave Bug 800 a P2.  That makes it an RM decides.
>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>>> probably makes it possible to close Bug 800.  But it is also totally OK for
>>>> RM to decide that
>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>>> is bad for the code, and that 'virtual cursors' should therefore be
>>>> postponed, and live with the P2, suitably updated, for 2.2.0.
>>>
>>>
>>> I say aa8be0c4 was a non-solution to the problem.
>>>
>>> Merely by changing the cursor, it aided the user in making a click close
>>> to the split line, measured in pixels.  But how close is that in time terms?
>>> That is variable with magnification, and so you would still not get the
>>> exactitude you really want in the selection.
>>>
>>> But the snapping code is intended to give that, independent of
>>> magnification.  A true solution of bug 800 really needs it.
>>>
>>> PRL
>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

Re: Preview snap lines; revisiting Bug 800

Gale
Administrator
In reply to this post by Paul Licameli
On 14 July 2017 at 19:42, Paul Licameli <[hidden email]> wrote:

>
>
> On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
>>
>> On 7/13/2017 10:10 PM, Paul Licameli wrote:
>>
>>> Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>> (the finger cursor) was a hasty solution that shouldn't stand, and even
>>> James seemed to agree about that.
>>
>> Split SplitLines, as in
>> https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
>> seem to me a workable/acceptable way of allowing selection and also split
>> line removal at the exact same x coordinate.
>>
>>
>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>> is kind of 'virtual cursors', where every split line is a virtual cursor.
>> Virtual cursors aren't a bad idea, but do need more thought.  For example it
>> could make sense for every clip boundary/snap-line to be a virtual cursor.
>> My implementation is only 1px wide, which is not consistent with true
>> cursor.  My code is also, kind of, minimum effort to get the result, and I
>> totally accept less hacky implementation is possible.
>>
>> I think virtual cursors are unnecessary, but I did want to close Bug 800
>> quickly, and Gale felt that the cursor change and status message change were
>> essential.
>>
>
> (What I don't understand about your comments.  Commit aa8be0c was about,
> simply, a cursor.  Explain "virtual.")
>
>>
>> Gale gave Bug 800 a P2.  That makes it an RM decides.
>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>> probably makes it possible to close Bug 800.  But it is also totally OK for
>> RM to decide that
>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>> is bad for the code, and that 'virtual cursors' should therefore be
>> postponed, and live with the P2, suitably updated, for 2.2.0.
>
>
> There is one important thing to find agreement on soon:  whether to keep the
> appearance change in split lines, which affects Peter's work.  I am not yet
> dictating it but will vote, -1.
>
> The change is from the earlier of James' two commits at issue, dc1193a, not
> part of the theming project.
>
> I dislike it, not as strongly as the later aa8be0c which changed the cursor,
> but I do dislike it too.  Gale has said he dislikes it, making the split
> line "too thin" for visibility -- I think this means the more prominent top
> and bottom are too thin.

The whole line is too thin nor is the centre easily visible in all cases.

I am no longer QM but if I was I would not pass the fix as we have it
now - as I indicated in a previous message. The Split Line in my
opinion must be as visible at all times as it was in 2.1.3.


Gale

> And at bottom I got the sense of a hasty and too special-case fix of what is
> really a more general problem -- what to do when there is more than one
> thing you may want to interact with near the pointer.  And that is something
> I have been thinking about, and preparing much groundwork for, for more
> reasons than just this bug.
>
> So I want to fix 800 by better, general, means, or just not fix it now.  But
> I have also worked on the "other means" -- the Tab key, the changes in
> selection snapping, and the tooltips that aid in discovering these.  (These
> three things are separable.  You can give me opinions about then
> separately.)  I will lobby hard for the features or something like them in
> 2.2.1, if they are not in sooner.
>
> I would like them sooner.  So please, try them, and give me opinions.
>
> I think they are the right direction to go.  Tab key can lead to abolishing
> the Tools toolbar, and also let us add interactive things to TrackPanel
> without needing to make more toolbar buttons.  Tab key can also escape
> snapping selection when you don't want it.  I think all of this is very
> valuable.
>
> But besides this, if the visible feature is not in, what will certainly be
> in, for the sake of future development, is a lot of the difficult internals
> work that make the feature easy to add.  Getting this work right is a major
> reason why the schedule slipped a bit, and I am not apologizing for
> insisting on making it right for 2.2.0.  I had come to realize that the
> state of things at
> https://github.com/audacity/audacity/commit/6eac877de6453542dc278b2439eb0f9c983cee89
> was a halfway state that wasn't good enough, that the sort of problem James
> fixed at http://bugzilla.audacityteam.org/show_bug.cgi?id=1677 needed more
> comprehensive work to be sure there were not others like it, and now that
> work is accomplished.  I was thinking that when we go for a beta testing
> period, then I want to load more of these needed internal changes in to get
> more benefit from that period and lessen the motivation to do a beta period
> again in the next release.
>
> PRL
>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

Re: Preview snap lines; revisiting Bug 800

Stevethefiddle
In reply to this post by Gale
On 14 July 2017 at 19:50, Gale Andrews <[hidden email]> wrote:
> On 14 July 2017 at 13:58, Steve the Fiddle <[hidden email]> wrote:
>> The thing that is bugging me is that we are having a protracted
>> discussion about a minor enhancement (as far as I'm aware there has
>> only ever been one person out of millions that considered bug 800 to
>> be more than a minor issue)
>
> This is nonsense/exaggeration. But it is P2 not P1 and RM sees it as
> worth pursuing. I am not convinced the positional solution with thicker
> centre is good so RM could decide to let this P2 through till 2.2.1.

Perhaps you would like to comment on my main point Gale - the 52 P1
and P2 bugs, 24 days before the scheduled release date.

Steve


>
> I do see a solution fits with wider goals.
>
> The extra Status Bar messages and highlighting and hit targets are not
> rated. I am less sure why we are pursuing them given the testing and
> wider bug risk.
>
>
> Gale
>
>
>>  when we should be preparing for a major
>> new release. There are many possible solutions to bug 800, some of
>> which disadvantage as many or more users than they benefit, so we
>> should not be rushing to a solution imo, but more to the point we
>> should not be spending so much time on this now when there are far
>> more importing issues, such as the 52! P1 and P2 bugs that aren't yet
>> FIX MADE.
>>
>> Steve
>>
>> On 14 July 2017 at 13:16, Peter Sampson <[hidden email]> wrote:
>>> We could fix Bug 800 in a simpler way it seems to me:
>>>
>>> 1) revert out clip lines to the simple ones that we have always
>>> had in 2.1.3 and earlier.
>>>
>>> 2) Do *not* allow left-click on a clip line to delete it
>>> (this is one of the major problems here)
>>>
>>> 3) Use right-click to delete the slpit line - or use right-click to pop a
>>> dropdown menu with "Delete Clip line" in it.
>>>
>>> 4) I do like the way that the clip lines show the yellow snap guide as you
>>> move the cursor close to the split line (without needing the left click).
>>>
>>>
>>> Personally, apart form the removal of the clip line with the left click, I
>>> have
>>> never found it "too hard" to select with clips/clip boundaries - as Bug 800
>>> states:
>>>
>>> a) to partially select just clip outside.inside the clip and drag to the
>>> clip edge
>>> where the yellow snap guide appears - simple,
>>>
>>> b) to select the whole clip just doble click inside it - even simpler.
>>>
>>> Peter.
>>>
>>>
>>>
>>> On Fri, Jul 14, 2017 at 1:03 PM, Paul Licameli <[hidden email]>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
>>>>>
>>>>> On 7/13/2017 10:10 PM, Paul Licameli wrote:
>>>>>
>>>>>> Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>>>>> (the finger cursor) was a hasty solution that shouldn't stand, and even
>>>>>> James seemed to agree about that.
>>>>>
>>>>> Split SplitLines, as in
>>>>> https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
>>>>> seem to me a workable/acceptable way of allowing selection and also split
>>>>> line removal at the exact same x coordinate.
>>>>>
>>>>>
>>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>>>> is kind of 'virtual cursors', where every split line is a virtual cursor.
>>>>> Virtual cursors aren't a bad idea, but do need more thought.  For example it
>>>>> could make sense for every clip boundary/snap-line to be a virtual cursor.
>>>>> My implementation is only 1px wide, which is not consistent with true
>>>>> cursor.  My code is also, kind of, minimum effort to get the result, and I
>>>>> totally accept less hacky implementation is possible.
>>>>>
>>>>> I think virtual cursors are unnecessary, but I did want to close Bug 800
>>>>> quickly, and Gale felt that the cursor change and status message change were
>>>>> essential.
>>>>>
>>>>> Gale gave Bug 800 a P2.  That makes it an RM decides.
>>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>>>> probably makes it possible to close Bug 800.  But it is also totally OK for
>>>>> RM to decide that
>>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>>>> is bad for the code, and that 'virtual cursors' should therefore be
>>>>> postponed, and live with the P2, suitably updated, for 2.2.0.
>>>>
>>>>
>>>> I say aa8be0c4 was a non-solution to the problem.
>>>>
>>>> Merely by changing the cursor, it aided the user in making a click close
>>>> to the split line, measured in pixels.  But how close is that in time terms?
>>>> That is variable with magnification, and so you would still not get the
>>>> exactitude you really want in the selection.
>>>>
>>>> But the snapping code is intended to give that, independent of
>>>> magnification.  A true solution of bug 800 really needs it.
>>>>
>>>> PRL
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> audacity-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

Re: Preview snap lines; revisiting Bug 800

James Crook
In reply to this post by Paul Licameli
This thread elsewhere is getting a bit heated!

- I am fine with my fixes to bug 800 being reverted.
- There is no necessity to fix the bug 800 problem at all for 2.2.0.

I am very glad that groundwork has/is being put in place to abolish the
ToolsToolbar, which has always had a 'stuck in a mode' feel to it for
me.  The bit that will interest me is where and how we will make grab
handles for clips - and the possibility that we will need to visually
differentiate squashy/stretchy clips/silence from clips/silence that is
not squashy/stretchy.   We will need to revisit the sync-lock concept too.

A status message for Tab does not make Tab discoverable, but it really
doesn't matter!
Tab doesn't need to be discoverable in 2.2.0.
The tooltips are horrid, in their current form, and need a rethink.  The
flicker in them is just one problem.  I think tooltips should be for
buttons and sliders only, show only after a delay, and they don't work
in the larger areas.

I'd enjoy conversations about how multiple targets could be
disambiguated in 2.2.1.



On 7/14/2017 7:42 PM, Paul Licameli wrote:

> On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
>
>> On 7/13/2017 10:10 PM, Paul Licameli wrote:
>>
>> Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>> (the finger cursor) was a hasty solution that shouldn't stand, and even
>>> James seemed to agree about that.
>>>
>> Split SplitLines, as in https://github.com/audacity/au
>> dacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
>> seem to me a workable/acceptable way of allowing selection and also split
>> line removal at the exact same x coordinate.
>>
>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>> fd03e0b85bdf097b2ed37de9 is kind of 'virtual cursors', where every split
>> line is a virtual cursor.  Virtual cursors aren't a bad idea, but do need
>> more thought.  For example it could make sense for every clip
>> boundary/snap-line to be a virtual cursor.    My implementation is only 1px
>> wide, which is not consistent with true cursor.  My code is also, kind of,
>> minimum effort to get the result, and I totally accept less hacky
>> implementation is possible.
>>
>> I think virtual cursors are unnecessary, but I did want to close Bug 800
>> quickly, and Gale felt that the cursor change and status message change
>> were essential.
>>
>>
> (What I don't understand about your comments.  Commit aa8be0c was about,
> simply, a cursor.  Explain "virtual.")
It is just a way of looking at it Paul.  In my view there isn't an
actual cursor at the split line, but it as if there is one constructed
temporarily when you hover over it.  It becomes real, if you drag out
from it.

>
>> Gale gave Bug 800 a P2.  That makes it an RM decides.
>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>> fd03e0b85bdf097b2ed37de9 probably makes it possible to close Bug 800.
>> But it is also totally OK for RM to decide that
>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>> fd03e0b85bdf097b2ed37de9 is bad for the code, and that 'virtual cursors'
>> should therefore be postponed, and live with the P2, suitably updated, for
>> 2.2.0.
>
> There is one important thing to find agreement on soon:  whether to keep
> the appearance change in split lines, which affects Peter's work.  I am not
> yet dictating it but will vote, -1.
It does not need a vote.  You are RM, and I am just fine with you
reverting the appearance change.
In any case the appearance change I would have done, had I had more
time, would have been to put a symbol that you have to click on to join
the clips.


> The change is from the earlier of James' two commits at issue, dc1193a, not
> part of the theming project.
>
> I dislike it, not as strongly as the later aa8be0c which changed the
> cursor, but I do dislike it too.  Gale has said he dislikes it, making the
> split line "too thin" for visibility -- I think this means the more
> prominent top and bottom are too thin.
>
> And at bottom I got the sense of a hasty and too special-case fix of what
> is really a more general problem -- what to do when there is more than one
> thing you may want to interact with near the pointer.  And that is
> something I have been thinking about, and preparing much groundwork for,
> for more reasons than just this bug.
>
> So I want to fix 800 by better, general, means, or just not fix it now.
> But I have also worked on the "other means" -- the Tab key, the changes in
> selection snapping, and the tooltips that aid in discovering these.  (These
> three things are separable.  You can give me opinions about then
> separately.)  I will lobby hard for the features or something like them in
> 2.2.1, if they are not in sooner.
>
> I would like them sooner.  So please, try them, and give me opinions.
>
> I think they are the right direction to go.  Tab key can lead to abolishing
> the Tools toolbar, and also let us add interactive things to TrackPanel
> without needing to make more toolbar buttons.  Tab key can also escape
> snapping selection when you don't want it.  I think all of this is very
> valuable.
>
> But besides this, if the visible feature is not in, what will certainly be
> in, for the sake of future development, is a lot of the difficult internals
> work that make the feature easy to add.  Getting this work right is a major
> reason why the schedule slipped a bit, and I am not apologizing for
> insisting on making it right for 2.2.0.  I had come to realize that the
> state of things at https://github.com/audacity/audacity/commit/
> <https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58>
> 6eac877de6453542dc278b2439eb0f9c983cee89 was a halfway state that wasn't
> good enough, that the sort of problem James fixed at
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1677 needed more
> comprehensive work to be sure there were not others like it, and now that
> work is accomplished.

> I was thinking that when we go for a beta testing period, then I want to load more of these needed internal changes in to get more benefit from that period and lessen the motivation to do a beta period
> again in the next release.
I'm not really buying into that logic, though I don't think it matters
much.  I do buy in to the logic of (generally) putting sweeping changes
- restructuring and lib updates - in early in release cycle, and
incremental tweaks and local changes in towards the end of a release
cycle.  Big changes can happen late in release cycle too, and I am +1
for the expat upgrade for 2.2.0, but the RM needs to be very ready to
deal with the risks if they do make big changes late.

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

Re: Preview snap lines; revisiting Bug 800

Paul Licameli
So I gather that Gale concedes the urgency of fixing bug 800 in 2.2.0, and dislikes the appearance change.  James is not insistent on the particular change in split line appearance that was implemented.

I don't think Steve expressed an opinion about the changed appearance, nor has Peter, but Peter has enough to do in updating manual images for theming without this added difficulty.

And I dislike the appearance change.

Therefore, I call that I will revert it.

Next business, the three things of mine I mentioned: (1) more tooltips in TrackPanel, (2) Tab key to rotate among multiple hit targets, (3) yellow snap lines (not just at clip boundaries, but also at label boundaries) appearing before the click.

James says #1 flickers (on which operating system?).  Maybe there is a simple fix for that, maybe not.

For #2 Gale suggests another key, and Steve reports bad behavior on Unix when the mouse moves a little bit away from a point with multiple targets.

I might hide #1 and #2 behnid new EXPERIMENTAL switches then, but I am not convinced quite yet.

I want to hear more opinions about #3.

PRL


On Fri, Jul 14, 2017 at 4:48 PM, James Crook <[hidden email]> wrote:
This thread elsewhere is getting a bit heated!

- I am fine with my fixes to bug 800 being reverted.
- There is no necessity to fix the bug 800 problem at all for 2.2.0.

I am very glad that groundwork has/is being put in place to abolish the ToolsToolbar, which has always had a 'stuck in a mode' feel to it for me.  The bit that will interest me is where and how we will make grab handles for clips - and the possibility that we will need to visually differentiate squashy/stretchy clips/silence from clips/silence that is not squashy/stretchy.   We will need to revisit the sync-lock concept too.

A status message for Tab does not make Tab discoverable, but it really doesn't matter!
Tab doesn't need to be discoverable in 2.2.0.
The tooltips are horrid, in their current form, and need a rethink.  The flicker in them is just one problem.  I think tooltips should be for buttons and sliders only, show only after a delay, and they don't work in the larger areas.

I'd enjoy conversations about how multiple targets could be disambiguated in 2.2.1.



On 7/14/2017 7:42 PM, Paul Licameli wrote:
On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:

On 7/13/2017 10:10 PM, Paul Licameli wrote:

Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
(the finger cursor) was a hasty solution that shouldn't stand, and even
James seemed to agree about that.

Split SplitLines, as in https://github.com/audacity/au
dacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
seem to me a workable/acceptable way of allowing selection and also split
line removal at the exact same x coordinate.

https://github.com/audacity/audacity/commit/aa8be0c413d107e3
fd03e0b85bdf097b2ed37de9 is kind of 'virtual cursors', where every split
line is a virtual cursor.  Virtual cursors aren't a bad idea, but do need
more thought.  For example it could make sense for every clip
boundary/snap-line to be a virtual cursor.    My implementation is only 1px
wide, which is not consistent with true cursor.  My code is also, kind of,
minimum effort to get the result, and I totally accept less hacky
implementation is possible.

I think virtual cursors are unnecessary, but I did want to close Bug 800
quickly, and Gale felt that the cursor change and status message change
were essential.


(What I don't understand about your comments.  Commit aa8be0c was about,
simply, a cursor.  Explain "virtual.")
It is just a way of looking at it Paul.  In my view there isn't an actual cursor at the split line, but it as if there is one constructed temporarily when you hover over it.  It becomes real, if you drag out from it.


Gale gave Bug 800 a P2.  That makes it an RM decides.
https://github.com/audacity/audacity/commit/aa8be0c413d107e3
fd03e0b85bdf097b2ed37de9 probably makes it possible to close Bug 800.
But it is also totally OK for RM to decide that
https://github.com/audacity/audacity/commit/aa8be0c413d107e3
fd03e0b85bdf097b2ed37de9 is bad for the code, and that 'virtual cursors'
should therefore be postponed, and live with the P2, suitably updated, for
2.2.0.

There is one important thing to find agreement on soon:  whether to keep
the appearance change in split lines, which affects Peter's work.  I am not
yet dictating it but will vote, -1.
It does not need a vote.  You are RM, and I am just fine with you reverting the appearance change.
In any case the appearance change I would have done, had I had more time, would have been to put a symbol that you have to click on to join the clips.


The change is from the earlier of James' two commits at issue, dc1193a, not
part of the theming project.

I dislike it, not as strongly as the later aa8be0c which changed the
cursor, but I do dislike it too.  Gale has said he dislikes it, making the
split line "too thin" for visibility -- I think this means the more
prominent top and bottom are too thin.

And at bottom I got the sense of a hasty and too special-case fix of what
is really a more general problem -- what to do when there is more than one
thing you may want to interact with near the pointer.  And that is
something I have been thinking about, and preparing much groundwork for,
for more reasons than just this bug.

So I want to fix 800 by better, general, means, or just not fix it now.
But I have also worked on the "other means" -- the Tab key, the changes in
selection snapping, and the tooltips that aid in discovering these.  (These
three things are separable.  You can give me opinions about then
separately.)  I will lobby hard for the features or something like them in
2.2.1, if they are not in sooner.

I would like them sooner.  So please, try them, and give me opinions.

I think they are the right direction to go.  Tab key can lead to abolishing
the Tools toolbar, and also let us add interactive things to TrackPanel
without needing to make more toolbar buttons.  Tab key can also escape
snapping selection when you don't want it.  I think all of this is very
valuable.

But besides this, if the visible feature is not in, what will certainly be
in, for the sake of future development, is a lot of the difficult internals
work that make the feature easy to add.  Getting this work right is a major
reason why the schedule slipped a bit, and I am not apologizing for
insisting on making it right for 2.2.0.  I had come to realize that the
state of things at https://github.com/audacity/audacity/commit/
<https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58>
6eac877de6453542dc278b2439eb0f9c983cee89 was a halfway state that wasn't
good enough, that the sort of problem James fixed at
http://bugzilla.audacityteam.org/show_bug.cgi?id=1677 needed more
comprehensive work to be sure there were not others like it, and now that
work is accomplished.

I was thinking that when we go for a beta testing period, then I want to load more of these needed internal changes in to get more benefit from that period and lessen the motivation to do a beta period
again in the next release.
I'm not really buying into that logic, though I don't think it matters much.  I do buy in to the logic of (generally) putting sweeping changes - restructuring and lib updates - in early in release cycle, and incremental tweaks and local changes in towards the end of a release cycle.  Big changes can happen late in release cycle too, and I am +1 for the expat upgrade for 2.2.0, but the RM needs to be very ready to deal with the risks if they do make big changes late.

--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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


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

Re: Preview snap lines; revisiting Bug 800

Paul Licameli
As I wrote also at Bugzilla, I have reverted the fix at 

On Fri, Jul 14, 2017 at 6:54 PM, Paul Licameli <[hidden email]> wrote:
So I gather that Gale concedes the urgency of fixing bug 800 in 2.2.0, and dislikes the appearance change.  James is not insistent on the particular change in split line appearance that was implemented.

I don't think Steve expressed an opinion about the changed appearance, nor has Peter, but Peter has enough to do in updating manual images for theming without this added difficulty.

And I dislike the appearance change.

Therefore, I call that I will revert it.

Next business, the three things of mine I mentioned: (1) more tooltips in TrackPanel, (2) Tab key to rotate among multiple hit targets, (3) yellow snap lines (not just at clip boundaries, but also at label boundaries) appearing before the click.

James says #1 flickers (on which operating system?).  Maybe there is a simple fix for that, maybe not.

For #2 Gale suggests another key, and Steve reports bad behavior on Unix when the mouse moves a little bit away from a point with multiple targets.

I might hide #1 and #2 behnid new EXPERIMENTAL switches then, but I am not convinced quite yet.

I want to hear more opinions about #3.

PRL


On Fri, Jul 14, 2017 at 4:48 PM, James Crook <[hidden email]> wrote:
This thread elsewhere is getting a bit heated!

- I am fine with my fixes to bug 800 being reverted.
- There is no necessity to fix the bug 800 problem at all for 2.2.0.

I am very glad that groundwork has/is being put in place to abolish the ToolsToolbar, which has always had a 'stuck in a mode' feel to it for me.  The bit that will interest me is where and how we will make grab handles for clips - and the possibility that we will need to visually differentiate squashy/stretchy clips/silence from clips/silence that is not squashy/stretchy.   We will need to revisit the sync-lock concept too.

A status message for Tab does not make Tab discoverable, but it really doesn't matter!
Tab doesn't need to be discoverable in 2.2.0.
The tooltips are horrid, in their current form, and need a rethink.  The flicker in them is just one problem.  I think tooltips should be for buttons and sliders only, show only after a delay, and they don't work in the larger areas.

I'd enjoy conversations about how multiple targets could be disambiguated in 2.2.1.



On 7/14/2017 7:42 PM, Paul Licameli wrote:
On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:

On 7/13/2017 10:10 PM, Paul Licameli wrote:

Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
(the finger cursor) was a hasty solution that shouldn't stand, and even
James seemed to agree about that.

Split SplitLines, as in https://github.com/audacity/au
dacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
seem to me a workable/acceptable way of allowing selection and also split
line removal at the exact same x coordinate.

https://github.com/audacity/audacity/commit/aa8be0c413d107e3
fd03e0b85bdf097b2ed37de9 is kind of 'virtual cursors', where every split
line is a virtual cursor.  Virtual cursors aren't a bad idea, but do need
more thought.  For example it could make sense for every clip
boundary/snap-line to be a virtual cursor.    My implementation is only 1px
wide, which is not consistent with true cursor.  My code is also, kind of,
minimum effort to get the result, and I totally accept less hacky
implementation is possible.

I think virtual cursors are unnecessary, but I did want to close Bug 800
quickly, and Gale felt that the cursor change and status message change
were essential.


(What I don't understand about your comments.  Commit aa8be0c was about,
simply, a cursor.  Explain "virtual.")
It is just a way of looking at it Paul.  In my view there isn't an actual cursor at the split line, but it as if there is one constructed temporarily when you hover over it.  It becomes real, if you drag out from it.


Gale gave Bug 800 a P2.  That makes it an RM decides.
https://github.com/audacity/audacity/commit/aa8be0c413d107e3
fd03e0b85bdf097b2ed37de9 probably makes it possible to close Bug 800.
But it is also totally OK for RM to decide that
https://github.com/audacity/audacity/commit/aa8be0c413d107e3
fd03e0b85bdf097b2ed37de9 is bad for the code, and that 'virtual cursors'
should therefore be postponed, and live with the P2, suitably updated, for
2.2.0.

There is one important thing to find agreement on soon:  whether to keep
the appearance change in split lines, which affects Peter's work.  I am not
yet dictating it but will vote, -1.
It does not need a vote.  You are RM, and I am just fine with you reverting the appearance change.
In any case the appearance change I would have done, had I had more time, would have been to put a symbol that you have to click on to join the clips.


The change is from the earlier of James' two commits at issue, dc1193a, not
part of the theming project.

I dislike it, not as strongly as the later aa8be0c which changed the
cursor, but I do dislike it too.  Gale has said he dislikes it, making the
split line "too thin" for visibility -- I think this means the more
prominent top and bottom are too thin.

And at bottom I got the sense of a hasty and too special-case fix of what
is really a more general problem -- what to do when there is more than one
thing you may want to interact with near the pointer.  And that is
something I have been thinking about, and preparing much groundwork for,
for more reasons than just this bug.

So I want to fix 800 by better, general, means, or just not fix it now.
But I have also worked on the "other means" -- the Tab key, the changes in
selection snapping, and the tooltips that aid in discovering these.  (These
three things are separable.  You can give me opinions about then
separately.)  I will lobby hard for the features or something like them in
2.2.1, if they are not in sooner.

I would like them sooner.  So please, try them, and give me opinions.

I think they are the right direction to go.  Tab key can lead to abolishing
the Tools toolbar, and also let us add interactive things to TrackPanel
without needing to make more toolbar buttons.  Tab key can also escape
snapping selection when you don't want it.  I think all of this is very
valuable.

But besides this, if the visible feature is not in, what will certainly be
in, for the sake of future development, is a lot of the difficult internals
work that make the feature easy to add.  Getting this work right is a major
reason why the schedule slipped a bit, and I am not apologizing for
insisting on making it right for 2.2.0.  I had come to realize that the
state of things at https://github.com/audacity/audacity/commit/
<https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58>
6eac877de6453542dc278b2439eb0f9c983cee89 was a halfway state that wasn't
good enough, that the sort of problem James fixed at
http://bugzilla.audacityteam.org/show_bug.cgi?id=1677 needed more
comprehensive work to be sure there were not others like it, and now that
work is accomplished.

I was thinking that when we go for a beta testing period, then I want to load more of these needed internal changes in to get more benefit from that period and lessen the motivation to do a beta period
again in the next release.
I'm not really buying into that logic, though I don't think it matters much.  I do buy in to the logic of (generally) putting sweeping changes - restructuring and lib updates - in early in release cycle, and incremental tweaks and local changes in towards the end of a release cycle.  Big changes can happen late in release cycle too, and I am +1 for the expat upgrade for 2.2.0, but the RM needs to be very ready to deal with the risks if they do make big changes late.

--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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



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