Discussion:
Preview snap lines; revisiting Bug 800
(too old to reply)
Paul Licameli
2017-07-13 16:59:04 UTC
Permalink
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
Gale Andrews
2017-07-13 19:01:45 UTC
Permalink
Post by 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 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
Post by Paul Licameli
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?
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-07-13 21:10:56 UTC
Permalink
Post by Paul Licameli
Post by Paul Licameli
I hope Gale enjoys this present.
At commit 9072628b4cd194dcfc85702df46daa0c1e55393c
I implemented something I promised earlier: Yellow snap lines appear
before
Post by Paul Licameli
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
Post by Paul Licameli
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?
Post by Paul Licameli
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.
Post by Paul Licameli
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
Post by Paul Licameli
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?
Post by Paul Licameli
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
Post by Paul Licameli
Gale
Post by Paul Licameli
I also undid James' change of cursor to finger when exactly over a
cutline,
Post by Paul Licameli
as unnecessary.
Now the question arises: Do we still really want the other thing James
did
Post by Paul Licameli
related to Bug 800, the change in appearance of the split lines?
We accept the TAB key cycling as a sufficient fix for the difficulty.
But
Post by Paul Licameli
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
Post by Paul Licameli
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,
Post by Paul Licameli
as in EXPERIMENTAL_TRACK_PANEL_HIGHLIGHTING, but choosing other colors
than
Post by Paul Licameli
the intentionaly ugly ones I used there.
Other questions arise. Should the same TAB toggling be done for snap
lines
Post by Paul Licameli
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
------------------------------------------------------------
------------------
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
James Crook
2017-07-14 09:07:38 UTC
Permalink
Post by Paul Licameli
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.
Steve the Fiddle
2017-07-14 10:25:31 UTC
Permalink
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
Post by James Crook
Post by Paul Licameli
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-07-14 11:41:16 UTC
Permalink
+1 to what Steve says here

comments in-line below
Post by Steve the Fiddle
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.
Post by Steve the Fiddle
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.
Post by Steve the Fiddle
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
Post by Steve the Fiddle
Steve
Post by James Crook
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf09
7b2ed37de9
Post by James Crook
Post by Paul Licameli
(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
Post by James Crook
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
Post by James Crook
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
Post by James Crook
could make sense for every clip boundary/snap-line to be a virtual
cursor.
Post by James Crook
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
Post by James Crook
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
Post by James Crook
essential.
Gale gave Bug 800 a P2. That makes it an RM decides.
https://github.com/audacity/audacity/commit/
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by James Crook
probably makes it possible to close Bug 800. But it is also totally OK
for
Post by James Crook
RM to decide that
https://github.com/audacity/audacity/commit/
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by James Crook
is bad for the code, and that 'virtual cursors' should therefore be
postponed, and live with the P2, suitably updated, for 2.2.0.
------------------------------------------------------------
------------------
Post by James Crook
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-07-14 12:03:49 UTC
Permalink
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
(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.

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

PRL
Post by Paul Licameli
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-07-14 12:16:07 UTC
Permalink
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.
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
(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.
But the snapping code is intended to give that, independent of
magnification. A true solution of bug 800 really needs it.
PRL
Post by Paul Licameli
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Steve the Fiddle
2017-07-14 12:58:42 UTC
Permalink
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
Post by Peter Sampson
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
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.
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
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
Post by James Crook
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-07-14 18:50:05 UTC
Permalink
Post by Steve the Fiddle
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
Post by Steve the Fiddle
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
Post by Peter Sampson
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
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.
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
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
Post by James Crook
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Steve the Fiddle
2017-07-14 19:27:51 UTC
Permalink
Post by Gale Andrews
Post by Steve the Fiddle
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
Post by Gale Andrews
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
Post by Steve the Fiddle
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
Post by Peter Sampson
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
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.
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
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
Post by James Crook
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-07-15 15:32:57 UTC
Permalink
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
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.
A strange expression. There is one P1 and 44 P2.

800 was promoted because otherwise it won't be tackled or taken into
account as part of the more general problem it represents.

The large number of P2s are I think flowing from other changes and
not from bug 800 (unless from enabling work that Paul said he wanted
to do anyway).

I am not aware of a release of 2.2.0 at the end of July:
http://wiki.audacityteam.org/wiki/Next_Release

I had heard from Paul of ten days' delay on "Next Release".


Gale
Post by Steve the Fiddle
Steve
Post by Gale Andrews
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
Post by Steve the Fiddle
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
Post by Peter Sampson
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
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.
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
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
Post by James Crook
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Steve the Fiddle
2017-07-15 15:56:33 UTC
Permalink
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
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.
A strange expression. There is one P1 and 44 P2.
Not strange at all. At the time of writing, this page
http://bugzilla.audacityteam.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=DEVEL%20-%20FIX%20MADE&list_id=10143&priority=P1&priority=P2&query_format=advanced
showed 58 bugs, 6 of which were Devel Fix Made.
Post by Gale Andrews
800 was promoted because otherwise it won't be tackled or taken into
account as part of the more general problem it represents.
Then it would have been clearer to log the "more general problem"
rather than inflating the priority of this specific enhancement.
Post by Gale Andrews
The large number of P2s are I think flowing from other changes and
not from bug 800 (unless from enabling work that Paul said he wanted
to do anyway).
http://wiki.audacityteam.org/wiki/Next_Release
which says:
"07/08/17 - 2.2.0 released." (by my reconning is now 23 days hence)
and (from the page history) previously said:
"28/07/17 - 2.2.0 released."

Steve
Post by Gale Andrews
I had heard from Paul of ten days' delay on "Next Release".
Gale
Post by Steve the Fiddle
Steve
Post by Gale Andrews
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
Post by Steve the Fiddle
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
Post by Peter Sampson
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
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.
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
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
Post by James Crook
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-07-15 15:58:32 UTC
Permalink
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
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.
A strange expression. There is one P1 and 44 P2.
Current Bugzilla count shows 6 x open P1s (of which 5 are fix-made ready
for testing)
(I tested several of them on E10 today).

And 50 x P2 (of which 6 are fix-made ready for testing)

so a total now of 56 open P1 & P2 bugs
Post by Gale Andrews
800 was promoted because otherwise it won't be tackled or taken into
account as part of the more general problem it represents.
We should *not* be using escalated priority settings to try to ensure that
something gets done for a particular release.

Any bug's priority setting should be made according to its severity and its
impact. And I agree with Steve that bug #800 is both loe severity and low
impact.


And anyway, we've lived with bug #800 for two and a half years (and probably
longer before it was reported/logged) and a few releases - so it seems to me
that forcing it through now for 2.2.0 is hardly an imperative - and
certainly
not a show-stopper.

But I do agree that we should fing a (good and not kludgey) way to fix it
though.
Post by Gale Andrews
The large number of P2s are I think flowing from other changes and
not from bug 800
Agreed - I don't think bug 800 impacts any of the other bugs.
Post by Gale Andrews
(unless from enabling work that Paul said he wanted
to do anyway).
http://wiki.audacityteam.org/wiki/Next_Release
That page now shows 31Jul17 as RC1 with 2.2.0 release scheduled for a
week later on 07Aug17 - so pretty datn close to the end of Juy - and right
we are also pretty darn close to the end of July with just a couple of weeks
to go.

And that P1 P2 open bugcount is pretty darn high for being this close to a
potential release
Post by Gale Andrews
I had heard from Paul of ten days' delay on "Next Release".
AFAIK those dates on the Next Release page include the ten days delay that
Pauladded.

James used to keep the old slipped dates on that page, struck out,
adding the new revised dates so that we can see and appraise the slippage.

In contrast Paul just overwrites them (the page history remains available
,of
course).

Peter
Post by Gale Andrews
Gale
Post by Steve the Fiddle
Steve
Post by Gale Andrews
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
Post by Steve the Fiddle
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
Post by Peter Sampson
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
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
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
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
move the cursor close to the split line (without needing the left
click).
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Personally, apart form the removal of the clip line with the left
click, I
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
have
never found it "too hard" to select with clips/clip boundaries - as
Bug 800
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
a) to partially select just clip outside.inside the clip and drag to
the
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
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 <
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf09
7b2ed37de9
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
(the finger cursor) was a hasty solution that shouldn't stand, and
even
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
James seemed to agree about that.
Split SplitLines, as in
https://github.com/audacity/audacity/commit/
dc1193a0af83f1d43de5a30aea6b6b09087eea58
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
seem to me a workable/acceptable way of allowing selection and also
split
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
line removal at the exact same x coordinate.
https://github.com/audacity/audacity/commit/
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
is kind of 'virtual cursors', where every split line is a virtual
cursor.
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
Virtual cursors aren't a bad idea, but do need more thought. For
example it
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
could make sense for every clip boundary/snap-line to be a virtual
cursor.
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
My implementation is only 1px wide, which is not consistent with
true
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
cursor. My code is also, kind of, minimum effort to get the
result, and I
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
totally accept less hacky implementation is possible.
I think virtual cursors are unnecessary, but I did want to close
Bug 800
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
quickly, and Gale felt that the cursor change and status message
change were
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
essential.
Gale gave Bug 800 a P2. That makes it an RM decides.
https://github.com/audacity/audacity/commit/
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
probably makes it possible to close Bug 800. But it is also
totally OK for
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
RM to decide that
https://github.com/audacity/audacity/commit/
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
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
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
to the split line, measured in pixels. But how close is that in
time terms?
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
That is variable with magnification, and so you would still not get
the
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
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
Post by James Crook
------------------------------------------------------------
------------------
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Steve the Fiddle
Post by Gale Andrews
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Steve the Fiddle
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-07-17 17:20:55 UTC
Permalink
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
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.
A strange expression. There is one P1 and 44 P2.
Current Bugzilla count shows 6 x open P1s (of which 5 are fix-made ready for
testing)
(I tested several of them on E10 today).
And 50 x P2 (of which 6 are fix-made ready for testing)
so a total now of 56 open P1 & P2 bugs
Post by Gale Andrews
800 was promoted because otherwise it won't be tackled or taken into
account as part of the more general problem it represents.
We should *not* be using escalated priority settings to try to ensure that
something gets done for a particular release.
That was not how it worked. The developer needs to know the bug
exists.
Any bug's priority setting should be made according to its severity and its
impact. And I agree with Steve that bug #800 is both loe severity and low
impact.
And anyway, we've lived with bug #800 for two and a half years (and probably
longer before it was reported/logged) and a few releases - so it seems to me
that forcing it through now for 2.2.0 is hardly an imperative - and
certainly not a show-stopper.
No P2 is a show stopper and no-one is forcing anything through AFAIK. I had
felt the fix we had worked on was inadequate in the round though I DO think
even now it is in a clear improvement IF user notices the Status Bar.

I just think most folk won't understand or care yet about snapping.

In particular, IMO, you should be able hold Shift or (Ctrl + Shift) and arrow
key to a natural boundary.


Gale
But I do agree that we should fing a (good and not kludgey) way to fix it
though.
Post by Gale Andrews
The large number of P2s are I think flowing from other changes and
not from bug 800
Agreed - I don't think bug 800 impacts any of the other bugs.
Post by Gale Andrews
(unless from enabling work that Paul said he wanted
to do anyway).
http://wiki.audacityteam.org/wiki/Next_Release
That page now shows 31Jul17 as RC1 with 2.2.0 release scheduled for a
week later on 07Aug17 - so pretty datn close to the end of Juy - and right
we are also pretty darn close to the end of July with just a couple of weeks
to go.
And that P1 P2 open bugcount is pretty darn high for being this close to a
potential release
Post by Gale Andrews
I had heard from Paul of ten days' delay on "Next Release".
AFAIK those dates on the Next Release page include the ten days delay that
Pauladded.
James used to keep the old slipped dates on that page, struck out,
adding the new revised dates so that we can see and appraise the slippage.
In contrast Paul just overwrites them (the page history remains available
,of
course).
Peter
Post by Gale Andrews
Gale
Post by Steve the Fiddle
Steve
Post by Gale Andrews
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
Post by Steve the Fiddle
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
Post by Peter Sampson
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
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
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
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
Post by James Crook
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-07-17 17:35:03 UTC
Permalink
Post by Gale Andrews
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
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.
A strange expression. There is one P1 and 44 P2.
Current Bugzilla count shows 6 x open P1s (of which 5 are fix-made ready
for
Post by Peter Sampson
testing)
(I tested several of them on E10 today).
And 50 x P2 (of which 6 are fix-made ready for testing)
so a total now of 56 open P1 & P2 bugs
Post by Gale Andrews
800 was promoted because otherwise it won't be tackled or taken into
account as part of the more general problem it represents.
We should *not* be using escalated priority settings to try to ensure
that
Post by Peter Sampson
something gets done for a particular release.
That was not how it worked. The developer needs to know the bug
exists.
Post by Peter Sampson
Any bug's priority setting should be made according to its severity and
its
Post by Peter Sampson
impact. And I agree with Steve that bug #800 is both loe severity and
low
Post by Peter Sampson
impact.
And anyway, we've lived with bug #800 for two and a half years (and
probably
Post by Peter Sampson
longer before it was reported/logged) and a few releases - so it seems
to me
Post by Peter Sampson
that forcing it through now for 2.2.0 is hardly an imperative - and
certainly not a show-stopper.
No P2 is a show stopper and no-one is forcing anything through AFAIK. I had
felt the fix we had worked on was inadequate in the round though I DO think
even now it is in a clear improvement IF user notices the Status Bar.
I just think most folk won't understand or care yet about snapping.
I totally agree.

I'm thinking that you only need/want the snap guided behavior - either you
want to
select feom the Clip line position or not - the sanp line ensures that.

Plus when you use ESC twice you get the third mode (simple click&drag
select)
BUT this mode is visually indistinguishabel from the basic delete clip mode.

So my vote would be to lose the third mode - and instead let Esc toggle
between the
two remaining modes.

Peter
Post by Gale Andrews
In particular, IMO, you should be able hold Shift or (Ctrl + Shift) and arrow
key to a natural boundary.
Gale
Post by Peter Sampson
But I do agree that we should fing a (good and not kludgey) way to fix it
though.
Post by Gale Andrews
The large number of P2s are I think flowing from other changes and
not from bug 800
Agreed - I don't think bug 800 impacts any of the other bugs.
Post by Gale Andrews
(unless from enabling work that Paul said he wanted
to do anyway).
http://wiki.audacityteam.org/wiki/Next_Release
That page now shows 31Jul17 as RC1 with 2.2.0 release scheduled for a
week later on 07Aug17 - so pretty datn close to the end of Juy - and
right
Post by Peter Sampson
we are also pretty darn close to the end of July with just a couple of
weeks
Post by Peter Sampson
to go.
And that P1 P2 open bugcount is pretty darn high for being this close to
a
Post by Peter Sampson
potential release
Post by Gale Andrews
I had heard from Paul of ten days' delay on "Next Release".
AFAIK those dates on the Next Release page include the ten days delay
that
Post by Peter Sampson
Pauladded.
James used to keep the old slipped dates on that page, struck out,
adding the new revised dates so that we can see and appraise the
slippage.
Post by Peter Sampson
In contrast Paul just overwrites them (the page history remains available
,of
course).
Peter
Post by Gale Andrews
Gale
Post by Steve the Fiddle
Steve
Post by Gale Andrews
I do see a solution fits with wider goals.
The extra Status Bar messages and highlighting and hit targets are
not
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
rated. I am less sure why we are pursuing them given the testing and
wider bug risk.
Gale
Post by Steve the Fiddle
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
FIX MADE.
Steve
On 14 July 2017 at 13:16, Peter Sampson
Post by Peter Sampson
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
a) to partially select just clip outside.inside the clip and drag
to
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
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
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
Whereas I did think that commit
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
(the finger cursor) was a hasty solution that shouldn't stand,
and
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
even
James seemed to agree about that.
Split SplitLines, as in
https://github.com/audacity/audacity/commit/
dc1193a0af83f1d43de5a30aea6b6b09087eea58
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
seem to me a workable/acceptable way of allowing selection and
also
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
split
line removal at the exact same x coordinate.
https://github.com/audacity/audacity/commit/
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
is bad for the code, and that 'virtual cursors' should therefore
be
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
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
Post by James Crook
------------------------------------------------------------
------------------
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Post by Peter Sampson
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Post by Steve the Fiddle
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Gale Andrews
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Peter Sampson
Post by Gale Andrews
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Peter Sampson
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-07-17 21:54:02 UTC
Permalink
On Mon, Jul 17, 2017 at 1:35 PM, Peter Sampson <
Post by Peter Sampson
Post by Gale Andrews
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
On 14 July 2017 at 13:58, Steve the Fiddle <
Post by Steve the Fiddle
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
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.
A strange expression. There is one P1 and 44 P2.
Current Bugzilla count shows 6 x open P1s (of which 5 are fix-made
ready for
Post by Peter Sampson
testing)
(I tested several of them on E10 today).
And 50 x P2 (of which 6 are fix-made ready for testing)
so a total now of 56 open P1 & P2 bugs
Post by Gale Andrews
800 was promoted because otherwise it won't be tackled or taken into
account as part of the more general problem it represents.
We should *not* be using escalated priority settings to try to ensure
that
Post by Peter Sampson
something gets done for a particular release.
That was not how it worked. The developer needs to know the bug
exists.
I acquiesced in the escalation of this bug because I believed in the
importance of getting the fix right in the interests of similar future
developments, and because I had serious reservations about James' quick fix
but wanted to take the time to show how to fix it better rather than just
countermand it.

I even want to thank James and Gale for escalating it and stimulating me to
accelerate the developments I did. I have been repeating that it is my
judgment as a developer that there is more importance in this little issue
than may be apparent just from the user's view of things. There will be
dividends in 2.2.1 and beyond that may not be obvious now.

I considered it worth the delay I declared. Put blame on me, not Gale, if
you are unhappy with this.
Post by Peter Sampson
Post by Gale Andrews
Post by Peter Sampson
Any bug's priority setting should be made according to its severity and
its
Post by Peter Sampson
impact. And I agree with Steve that bug #800 is both loe severity and
low
Post by Peter Sampson
impact.
And anyway, we've lived with bug #800 for two and a half years (and
probably
Post by Peter Sampson
longer before it was reported/logged) and a few releases - so it seems
to me
Post by Peter Sampson
that forcing it through now for 2.2.0 is hardly an imperative - and
certainly not a show-stopper.
No P2 is a show stopper and no-one is forcing anything through AFAIK.
I honestly don't see that the user visible consequences were show-stopping,
but again I didn't want the quick fix to stand. I thought its downsides
outweighed the advantages.
Post by Peter Sampson
I had
Post by Gale Andrews
felt the fix we had worked on was inadequate in the round though I DO think
even now it is in a clear improvement IF user notices the Status Bar.
I just think most folk won't understand or care yet about snapping.
I totally agree.
I'm thinking that you only need/want the snap guided behavior - either you
want to
select feom the Clip line position or not - the sanp line ensures that.
Plus when you use ESC twice you get the third mode (simple click&drag
select)
BUT this mode is visually indistinguishabel from the basic delete clip mode.
That is not correct. Considering the changes in the cursor and in the
yellow line, and even disregarding the status bar, the three are all
distinct.
Post by Peter Sampson
So my vote would be to lose the third mode - and instead let Esc toggle
between the
two remaining modes.
Peter
I oppose losing the third mode. I think it does add some small value and
no inconvenience.

I certainly oppose "toggling" with the Esc key if that means cycling
between two states. As I said, I regard Esc key to mean "pop the stack"
and it should be uni-directional.

PRL
Post by Peter Sampson
Post by Gale Andrews
In particular, IMO, you should be able hold Shift or (Ctrl + Shift) and arrow
key to a natural boundary.
Gale
Post by Peter Sampson
But I do agree that we should fing a (good and not kludgey) way to fix
it
Post by Peter Sampson
though.
Post by Gale Andrews
The large number of P2s are I think flowing from other changes and
not from bug 800
Agreed - I don't think bug 800 impacts any of the other bugs.
Post by Gale Andrews
(unless from enabling work that Paul said he wanted
to do anyway).
http://wiki.audacityteam.org/wiki/Next_Release
That page now shows 31Jul17 as RC1 with 2.2.0 release scheduled for a
week later on 07Aug17 - so pretty datn close to the end of Juy - and
right
Post by Peter Sampson
we are also pretty darn close to the end of July with just a couple of
weeks
Post by Peter Sampson
to go.
And that P1 P2 open bugcount is pretty darn high for being this close
to a
Post by Peter Sampson
potential release
Post by Gale Andrews
I had heard from Paul of ten days' delay on "Next Release".
AFAIK those dates on the Next Release page include the ten days delay
that
Post by Peter Sampson
Pauladded.
James used to keep the old slipped dates on that page, struck out,
adding the new revised dates so that we can see and appraise the
slippage.
Post by Peter Sampson
In contrast Paul just overwrites them (the page history remains
available
Post by Peter Sampson
,of
course).
Peter
Post by Gale Andrews
Gale
Post by Steve the Fiddle
Steve
I do see a solution fits with wider goals.
The extra Status Bar messages and highlighting and hit targets are
not
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
rated. I am less sure why we are pursuing them given the testing and
wider bug risk.
Gale
Post by Steve the Fiddle
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
FIX MADE.
Steve
On 14 July 2017 at 13:16, Peter Sampson
Post by Peter Sampson
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Bug 800
a) to partially select just clip outside.inside the clip and drag
to
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
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
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
Whereas I did think that commit
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
(the finger cursor) was a hasty solution that shouldn't stand,
and
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
even
James seemed to agree about that.
Split SplitLines, as in
https://github.com/audacity/audacity/commit/dc1193a0af83f1d4
3de5a30aea6b6b09087eea58
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
seem to me a workable/acceptable way of allowing selection and
also
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
split
line removal at the exact same x coordinate.
https://github.com/audacity/audacity/commit/aa8be0c413d107e3
fd03e0b85bdf097b2ed37de9
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
is kind of 'virtual cursors', where every split line is a
virtual
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
cursor.
Virtual cursors aren't a bad idea, but do need more thought.
For
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
example it
could make sense for every clip boundary/snap-line to be a
virtual
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
is bad for the code, and that 'virtual cursors' should
therefore be
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
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
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
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
Post by James Crook
------------------------------------------------------------
------------------
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Post by James Crook
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Post by Peter Sampson
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Post by Steve the Fiddle
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Peter Sampson
Post by Gale Andrews
Post by Steve the Fiddle
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Peter Sampson
Post by Gale Andrews
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Peter Sampson
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-07-14 13:36:56 UTC
Permalink
On Fri, Jul 14, 2017 at 8:16 AM, Peter Sampson <
Post by Peter Sampson
1) revert out clip lines to the simple ones that we have always
had in 2.1.3 and earlier.
I favor this.
Post by Peter Sampson
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.
Post by Peter Sampson
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?
Post by Peter Sampson
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
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.
Post by Peter Sampson
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
Post by Peter Sampson
Peter.
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
(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.
But the snapping code is intended to give that, independent of
magnification. A true solution of bug 800 really needs it.
PRL
Post by Paul Licameli
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
James Crook
2017-07-14 14:06:13 UTC
Permalink
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
(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.
Post by Paul Licameli
But the snapping code is intended to give that, independent of
magnification. A true solution of bug 800 really needs it.
PRL
Paul Licameli
2017-07-14 14:28:32 UTC
Permalink
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
(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.
Post by James Crook
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
Post by James Crook
Post by Paul Licameli
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-07-14 18:41:19 UTC
Permalink
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
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
Post by Paul Licameli
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
Post by James Crook
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-07-15 08:00:00 UTC
Permalink
Post by Paul Licameli
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf09
7b2ed37de9
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
(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
Post by Paul Licameli
Post by James Crook
seem to me a workable/acceptable way of allowing selection and also
split
Post by Paul Licameli
Post by James Crook
line removal at the exact same x coordinate.
https://github.com/audacity/audacity/commit/
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
Post by James Crook
is kind of 'virtual cursors', where every split line is a virtual
cursor.
Post by Paul Licameli
Post by James Crook
Virtual cursors aren't a bad idea, but do need more thought. For
example it
Post by Paul Licameli
Post by James Crook
could make sense for every clip boundary/snap-line to be a virtual
cursor.
Post by Paul Licameli
Post by James Crook
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
Post by Paul Licameli
Post by James Crook
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
Post by Paul Licameli
Post by James Crook
essential.
Gale gave Bug 800 a P2. That makes it an RM decides.
https://github.com/audacity/audacity/commit/
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
Post by James Crook
probably makes it possible to close Bug 800. But it is also totally OK
for
Post by Paul Licameli
Post by James Crook
RM to decide that
https://github.com/audacity/audacity/commit/
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
Post by James Crook
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/dc1193a0af83f1d43de5a30aea6b6b
09087eea58
I think we would be creating a new bug that "Split lines are not visible
enough"
I am very +1 on this

I think the new tri-partite split lines are much harder to discen as a
split line, especially
with the thin line top and bottom with the thickline in the middle.

If we are to keep the tri-partite split line then it would be much better,
I believe, to have
the thick lines top and bottom with the thin line in the middle.

But I really don't think that we need the tr-partine line at all and can
happily live with the
split lines as we have always had them - as I still strongly think that the
underlying problem
with bug #800 is that left clicking on the split line removes/delets it -
and that is what can
make selections tricky for folk.

Removing that left-click delete (replacing with a right-click menu that has
Delete and Merge
commands) I still see as a good viable solution to bug #800
Post by Paul Licameli
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".
And that's why the left-click to delete a clip line is a problem ...
Post by Paul Licameli
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.
Not if we remove and replace the left-click delete split line.
Post by Paul Licameli
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.
Or use Alt+click the remove the split line.
Post by Paul Licameli
Sorry, this is how I feel about it right now.
Me too.
Post by Paul Licameli
Gale
Post by Paul Licameli
Merely by changing the cursor, it aided the user in making a click close
to
Post by Paul Licameli
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
Post by James Crook
------------------------------------------------------------
------------------
Post by Paul Licameli
Post by James Crook
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-07-14 18:42:42 UTC
Permalink
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
(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.")
Post by Paul Licameli
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.

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.

PRL
Post by Paul Licameli
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-07-14 19:10:32 UTC
Permalink
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
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.")
Post by James Crook
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
Post by Paul Licameli
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
Post by James Crook
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-07-15 08:06:20 UTC
Permalink
Post by Paul Licameli
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf09
7b2ed37de9
Post by Paul Licameli
Post by James Crook
Post by Paul Licameli
(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
Post by Paul Licameli
Post by James Crook
seem to me a workable/acceptable way of allowing selection and also
split
Post by Paul Licameli
Post by James Crook
line removal at the exact same x coordinate.
https://github.com/audacity/audacity/commit/
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
Post by James Crook
is kind of 'virtual cursors', where every split line is a virtual
cursor.
Post by Paul Licameli
Post by James Crook
Virtual cursors aren't a bad idea, but do need more thought. For
example it
Post by Paul Licameli
Post by James Crook
could make sense for every clip boundary/snap-line to be a virtual
cursor.
Post by Paul Licameli
Post by James Crook
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
Post by Paul Licameli
Post by James Crook
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
Post by Paul Licameli
Post by James Crook
essential.
(What I don't understand about your comments. Commit aa8be0c was about,
simply, a cursor. Explain "virtual.")
Post by James Crook
Gale gave Bug 800 a P2. That makes it an RM decides.
https://github.com/audacity/audacity/commit/
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
Post by James Crook
probably makes it possible to close Bug 800. But it is also totally OK
for
Post by Paul Licameli
Post by James Crook
RM to decide that
https://github.com/audacity/audacity/commit/
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
Post by James Crook
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
Post by Paul Licameli
appearance change in split lines, which affects Peter's work. I am not
yet
Post by Paul Licameli
dictating it but will vote, -1.
The change is from the earlier of James' two commits at issue, dc1193a,
not
Post by Paul Licameli
part of the theming project.
I dislike it, not as strongly as the later aa8be0c which changed the
cursor,
Post by Paul Licameli
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
Post by Paul Licameli
and bottom are too thin.
The whole line is too thin nor is the centre easily visible in all cases.
+1

I find the new tri-partite line far too indiscernable - too easy to
miss/overlook.
not significant enough for it's purpose.
Post by Paul Licameli
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.
+1

Nor am I QM, but if I were I too would not pass this.

But this is two QA votes for reverting to the 2.1.3 (and all earlier) split
line.

With a proper fix for the undeyling issue(s) in bug #800 (as Paul suggests
elsewhere)

Peter.
Post by Paul Licameli
Gale
Post by Paul Licameli
And at bottom I got the sense of a hasty and too special-case fix of
what is
Post by Paul Licameli
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
Post by Paul Licameli
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
Post by Paul Licameli
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
Post by Paul Licameli
three things are separable. You can give me opinions about then
separately.) I will lobby hard for the features or something like them
in
Post by Paul Licameli
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
Post by Paul Licameli
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
Post by Paul Licameli
in, for the sake of future development, is a lot of the difficult
internals
Post by Paul Licameli
work that make the feature easy to add. Getting this work right is a
major
Post by Paul Licameli
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
Post by Paul Licameli
was a halfway state that wasn't good enough, that the sort of problem
James
Post by Paul Licameli
fixed at http://bugzilla.audacityteam.org/show_bug.cgi?id=1677 needed
more
Post by Paul Licameli
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
Post by Paul Licameli
more benefit from that period and lessen the motivation to do a beta
period
Post by Paul Licameli
again in the next release.
PRL
Post by James Crook
------------------------------------------------------------
------------------
Post by Paul Licameli
Post by James Crook
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
James Crook
2017-07-14 20:48:49 UTC
Permalink
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.
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
(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.
Post by Paul Licameli
Post by Paul Licameli
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.
Post by Paul Licameli
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.
Post by Paul Licameli
PRL
Paul Licameli
2017-07-14 22:54:01 UTC
Permalink
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
Post by James Crook
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.
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
(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.
Post by Paul Licameli
Gale gave Bug 800 a P2. That makes it an RM decides.
Post by Paul Licameli
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
Post by Paul Licameli
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/dc1193a0af83f1d
43de5a30aea6b6b09087eea58>
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
Post by Paul Licameli
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.
Post by Paul Licameli
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-07-15 03:15:51 UTC
Permalink
As I wrote also at Bugzilla, I have reverted the fix at

https://github.com/audacity/audacity/commit/c5fc8eef03300e1d3b106f6c8a111602a1b01ad5

PRL
Post by 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
Post by James Crook
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.
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf09
7b2ed37de9
Post by Paul Licameli
(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.
Post by Paul Licameli
Gale gave Bug 800 a P2. That makes it an RM decides.
Post by Paul Licameli
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,
Post by Paul Licameli
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/dc1193a0af83f1d
43de5a30aea6b6b09087eea58>
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
Post by Paul Licameli
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.
Post by Paul Licameli
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-07-15 08:25:10 UTC
Permalink
Post by 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.
My dislike of this kludge change has nothing to do with fixing up a few
images and pages
in the Manual (I could cope with that).

Rather it is all to do with our users, their perceptions and their usabilty
of Audacity.

Long-tem users of clips in Audacity know what clip lines look like and will
be surprised by
the change.

New users of Audacity clips (and there will be plenty of them now that we
add a split line
when doing a, default, record-beside) will find them a little indiscernible
- and will probably
find the different behaviors of the different section tricky to get to
grips with.
Post by Paul Licameli
And I dislike the appearance change.
Therefore, I call that I will revert it.
Good call, I think ...
Post by Paul Licameli
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.
I see no toolip flickering on either W10 or on macOS Sierra.

Tooltips are good GUI because thay operate wher the user's visual attention
is already focusssed.
Post by Paul Licameli
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
Post by James Crook
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.
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf09
7b2ed37de9
Post by Paul Licameli
(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.
Post by Paul Licameli
Gale gave Bug 800 a P2. That makes it an RM decides.
Post by Paul Licameli
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,
Post by Paul Licameli
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/dc1193a0af83f1d
43de5a30aea6b6b09087eea58>
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
Post by Paul Licameli
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.
Post by Paul Licameli
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-07-15 08:54:10 UTC
Permalink
On Sat, Jul 15, 2017 at 9:25 AM, Peter Sampson <
Post by Peter Sampson
Post by 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.
My dislike of this kludge change has nothing to do with fixing up a few
images and pages
in the Manual (I could cope with that).
Rather it is all to do with our users, their perceptions and their
usabilty of Audacity.
Long-tem users of clips in Audacity know what clip lines look like and
will be surprised by
the change.
New users of Audacity clips (and there will be plenty of them now that we
add a split line
when doing a, default, record-beside) will find them a little
indiscernible - and will probably
find the different behaviors of the different section tricky to get to
grips with.
Post by Paul Licameli
And I dislike the appearance change.
Therefore, I call that I will revert it.
Good call, I think ...
Post by Paul Licameli
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.
I see no toolip flickering on either W10 or on macOS Sierra.
Aha, I do now see tooltip flickering when I hover over the Waveform and
the TCP, but
only when I move the cursor and the tooltip gets redrawn as I move it.

But tha's just a factor of being redrawn in the new position I'm thinking -
I dont' really
expect the tooltip to move smothly in such circumstances.

Peter.
Post by Peter Sampson
Tooltips are good GUI because thay operate wher the user's visual
attention is already focusssed.
Post by Paul Licameli
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
Post by James Crook
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.
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf09
7b2ed37de9
Post by Paul Licameli
(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.
Post by Paul Licameli
Gale gave Bug 800 a P2. That makes it an RM decides.
Post by Paul Licameli
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,
Post by Paul Licameli
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/dc1193a0af83f1d
43de5a30aea6b6b09087eea58>
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
Post by Paul Licameli
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.
Post by Paul Licameli
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-07-15 08:13:12 UTC
Permalink
Post by James Crook
This thread elsewhere is getting a bit heated!
Because, I fell, it's quite important to get this right and not just kludge
it ;-)

It's QA's job to get a "bit heated" at times when we spot things that we
know are
likely to have a detrimental effect on our users
Post by James Crook
- I am fine with my fixes to bug 800 being reverted.
Glad to head that ;-)
Post by James Crook
- There is no necessity to fix the bug 800 problem at all for 2.2.0.
Indeed, we have lived with it this way for a long time as an "annoyance" and
not a "catastrophe-causer" - we can live with it a little longer. IMO this
is no
way a P2 bug and I agree with Steve that it should be a P4 Enh, borderline
P3 so we consider release noting it.

But the fix to remove the left-click split line delete and replace it with
a different
command would seem to me to be a relatively easy fix to the underlying
problem
of big #800 which is the accidental deletio
Post by James Crook
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.
+1
Post by James Crook
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.
+1
Post by James Crook
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.
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
(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.
Post by Paul Licameli
Gale gave Bug 800 a P2. That makes it an RM decides.
Post by Paul Licameli
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
Post by Paul Licameli
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/dc1193a0af83f1d
43de5a30aea6b6b09087eea58>
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
Post by Paul Licameli
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.
Post by Paul Licameli
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
David Bailes
2017-07-15 12:47:44 UTC
Permalink
Post by James Crook
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
Post by James Crook
flicker in them is just one problem. I think tooltips should be for
buttons and sliders only, show only after a delay,
+ 1, there should be a delay.
Post by James Crook
and they don't work in the larger areas.
The tooltips in the trackpanel cover up too much of a track's contents and
are too obtrusive - ie, they don't work.

(See for example the use of tooltips in Reaper)
Post by James Crook
I'd enjoy conversations about how multiple targets could be disambiguated
in 2.2.1.
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
(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.
Post by Paul Licameli
Gale gave Bug 800 a P2. That makes it an RM decides.
Post by Paul Licameli
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.
+1. More intuitive than Tab cycling.
Post by James Crook
The change is from the earlier of James' two commits at issue, dc1193a, not
Post by Paul Licameli
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/dc1193a0af83f1d
43de5a30aea6b6b09087eea58>
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
Post by Paul Licameli
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
Post by James Crook
(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.
Post by Paul Licameli
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Steve the Fiddle
2017-07-15 13:40:46 UTC
Permalink
Post by David Bailes
Post by James Crook
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,
+ 1, there should be a delay.
Post by James Crook
and they don't work in the larger areas.
The tooltips in the trackpanel cover up too much of a track's contents and
are too obtrusive - ie, they don't work.
(See for example the use of tooltips in Reaper)
Post by James Crook
I'd enjoy conversations about how multiple targets could be disambiguated
in 2.2.1.
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
(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.
Post by Paul Licameli
Post by Paul Licameli
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.
+1. More intuitive than Tab cycling.
That sounds like it could be good. I'd like to see that.

Steve
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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.
Post by Paul Licameli
PRL
------------------------------------------------------------------------------
Peter Sampson
2017-07-15 15:29:31 UTC
Permalink
Post by James Crook
Post by David Bailes
Post by James Crook
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.
Post by David Bailes
Post by James Crook
The bit that will interest me is where and how we will make grab
handles for
Post by David Bailes
Post by James Crook
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
Post by David Bailes
Post by James Crook
and sliders only, show only after a delay,
+ 1, there should be a delay.
Post by James Crook
and they don't work in the larger areas.
The tooltips in the trackpanel cover up too much of a track's contents
and
Post by David Bailes
are too obtrusive - ie, they don't work.
(See for example the use of tooltips in Reaper)
Post by James Crook
I'd enjoy conversations about how multiple targets could be
disambiguated
Post by David Bailes
Post by James Crook
in 2.2.1.
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf09
7b2ed37de9
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
(the finger cursor) was a hasty solution that shouldn't stand, and
even
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
quickly, and Gale felt that the cursor change and status message
change
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
were essential.
(What I don't understand about your comments. Commit aa8be0c was
about,
Post by David Bailes
Post by James Crook
Post by Paul Licameli
simply, a cursor. Explain "virtual.")
It is just a way of looking at it Paul. In my view there isn't an
actual
Post by David Bailes
Post by James Crook
cursor at the split line, but it as if there is one constructed
temporarily
Post by David Bailes
Post by James Crook
when you hover over it. It becomes real, if you drag out from it.
Post by Paul Licameli
Post by Paul Licameli
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'
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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,
Post by David Bailes
Post by James Crook
would have been to put a symbol that you have to click on to join the
clips.
Post by David Bailes
+1. More intuitive than Tab cycling.
That sounds like it could be good. I'd like to see that.
That sounds like it could be the basis of a good solution.

Peter.
Post by James Crook
Steve
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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,
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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>
Post by David Bailes
Post by James Crook
Post by Paul Licameli
6eac877de6453542dc278b2439eb0f9c983cee89 was a halfway state that
wasn't
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
work is accomplished.
I was thinking that when we go for a beta testing period, then I want
to
Post by David Bailes
Post by James Crook
Post by Paul Licameli
load more of these needed internal changes in to get more benefit from
that
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
early in release cycle, and incremental tweaks and local changes in
towards
Post by David Bailes
Post by James Crook
the end of a release cycle. Big changes can happen late in release
cycle
Post by David Bailes
Post by James Crook
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.
Post by Paul Licameli
PRL
------------------------------------------------------------
------------------
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-07-15 16:02:45 UTC
Permalink
Post by Peter Sampson
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
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,
+ 1, there should be a delay.
Post by James Crook
and they don't work in the larger areas.
The tooltips in the trackpanel cover up too much of a track's contents and
are too obtrusive - ie, they don't work.
(See for example the use of tooltips in Reaper)
Post by James Crook
I'd enjoy conversations about how multiple targets could be disambiguated
in 2.2.1.
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
(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.
Post by Paul Licameli
Post by Paul Licameli
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.
+1. More intuitive than Tab cycling.
That sounds like it could be good. I'd like to see that.
That sounds like it could be the basis of a good solution.
Peter.
But James rejected it before in his commit comments e.g. on the grounds
of awkwardness if many split lines were close together. I don't think it is the
best solution.


Gale
Post by Peter Sampson
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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.
Post by Paul Licameli
PRL
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-07-15 16:18:55 UTC
Permalink
Post by James Crook
On Sat, Jul 15, 2017 at 2:40 PM, Steve the Fiddle <
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
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
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
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
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
squashy/stretchy clips/silence from clips/silence that is not
squashy/stretchy. We will need to revisit the sync-lock concept
too.
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
A status message for Tab does not make Tab discoverable, but it
really
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
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,
+ 1, there should be a delay.
Post by James Crook
and they don't work in the larger areas.
The tooltips in the trackpanel cover up too much of a track's contents and
are too obtrusive - ie, they don't work.
(See for example the use of tooltips in Reaper)
Post by James Crook
I'd enjoy conversations about how multiple targets could be disambiguated
in 2.2.1.
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit
aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
Post by Paul Licameli
(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
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
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
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
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.
Post by Paul Licameli
Post by Paul Licameli
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.
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
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.
+1. More intuitive than Tab cycling.
That sounds like it could be good. I'd like to see that.
That sounds like it could be the basis of a good solution.
Peter.
But James rejected it before in his commit comments e.g. on the grounds
of awkwardness if many split lines were close together. I don't think it is the
best solution.
Surely the same problem exists with the existing left-click delete/join
clip when
there are many split lines close together.

And a similar problem exists when there are many labels close together.

In those situations the user needs to zoom in for accurate choice of clip
or label.
My workflows mean I do this quite a lot for labels.

Peter.
Post by James Crook
Gale
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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.
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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/dc1193a0af83f1d
43de5a30aea6b6b09087eea58>
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
Post by Paul Licameli
to
load more of these needed internal changes in to get more benefit
from
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
-
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
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.
Post by Paul Licameli
PRL
------------------------------------------------------------
------------------
Post by Steve the Fiddle
------------------------------------------------------------
------------------
Post by Steve the Fiddle
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
James Crook
2017-07-15 16:34:33 UTC
Permalink
Post by Gale Andrews
Post by Peter Sampson
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
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.
+1. More intuitive than Tab cycling.
That sounds like it could be good. I'd like to see that.
That sounds like it could be the basis of a good solution.
Peter.
But James rejected it before in his commit comments e.g. on the grounds
of awkwardness if many split lines were close together. I don't think it is the
best solution.
No Gale. I didn't do it because I didn't have time to do that approach
properly fro 2.2.0. The split-split-line (now reverted) was easier to code.

If split lines are that close together, you can zoom in, or it may not
matter as odds are you want to collapse several at once.
If the icon is 5 pixels wide, and grows on hover, it is not that much
more of a problem than the wide split lines already are.

It's a good solution, but not for 2.2.0.

--James.
Paul Licameli
2017-07-15 16:58:02 UTC
Permalink
Post by James Crook
Post by Gale Andrews
On Sat, Jul 15, 2017 at 2:40 PM, Steve the Fiddle <
Post by Steve the Fiddle
Post by David Bailes
Post by James Crook
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.
+1. More intuitive than Tab cycling.
That sounds like it could be good. I'd like to see that.
That sounds like it could be the basis of a good solution.
Peter.
But James rejected it before in his commit comments e.g. on the grounds
of awkwardness if many split lines were close together. I don't think it is the
best solution.
No Gale. I didn't do it because I didn't have time to do that approach
properly fro 2.2.0. The split-split-line (now reverted) was easier to code.
If split lines are that close together, you can zoom in, or it may not
matter as odds are you want to collapse several at once.
If the icon is 5 pixels wide, and grows on hover, it is not that much more
of a problem than the wide split lines already are.
It's a good solution, but not for 2.2.0.
Again, I say the TAB key convention would have solved this problem too.
It's not implemented yet, but it would not be difficult to have multiple
distinct hit targets of the same kind (clip boundary), in the rotation of
targets; as now, you can have a rotation among different kinds of target
(clip boundary, snap position).

PRL
Post by James Crook
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-07-15 16:39:20 UTC
Permalink
On Sat, Jul 15, 2017 at 11:29 AM, Peter Sampson <
On Sat, Jul 15, 2017 at 2:40 PM, Steve the Fiddle <
Post by James Crook
Post by David Bailes
Post by James Crook
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.
Post by David Bailes
Post by James Crook
The bit that will interest me is where and how we will make grab
handles for
Post by David Bailes
Post by James Crook
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
Post by David Bailes
Post by James Crook
flicker in them is just one problem. I think tooltips should be for
buttons
Post by David Bailes
Post by James Crook
and sliders only, show only after a delay,
+ 1, there should be a delay.
Post by James Crook
and they don't work in the larger areas.
The tooltips in the trackpanel cover up too much of a track's contents
and
Post by David Bailes
are too obtrusive - ie, they don't work.
(See for example the use of tooltips in Reaper)
Post by James Crook
I'd enjoy conversations about how multiple targets could be
disambiguated
Post by David Bailes
Post by James Crook
in 2.2.1.
Post by Paul Licameli
Post by Paul Licameli
Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf09
7b2ed37de9
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
(the finger cursor) was a hasty solution that shouldn't stand, and
even
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
1px
wide, which is not consistent with true cursor. My code is also,
kind
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
quickly, and Gale felt that the cursor change and status message
change
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
were essential.
(What I don't understand about your comments. Commit aa8be0c was
about,
Post by David Bailes
Post by James Crook
Post by Paul Licameli
simply, a cursor. Explain "virtual.")
It is just a way of looking at it Paul. In my view there isn't an
actual
Post by David Bailes
Post by James Crook
cursor at the split line, but it as if there is one constructed
temporarily
Post by David Bailes
Post by James Crook
when you hover over it. It becomes real, if you drag out from it.
Post by Paul Licameli
Post by Paul Licameli
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'
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
should therefore be postponed, and live with the P2, suitably
updated,
Post by David Bailes
Post by James Crook
Post by Paul Licameli
Post by Paul Licameli
for
2.2.0.
There is one important thing to find agreement on soon: whether to
keep
Post by David Bailes
Post by James Crook
Post by Paul Licameli
the appearance change in split lines, which affects Peter's work. I
am
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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,
Post by David Bailes
Post by James Crook
would have been to put a symbol that you have to click on to join the
clips.
Post by David Bailes
+1. More intuitive than Tab cycling.
That sounds like it could be good. I'd like to see that.
That sounds like it could be the basis of a good solution.
Peter.
I am holding out for TAB or some other key for cycling hit test targets, in
this or another release. It seems so very obvious to me that this is very
valuable, maybe because it was an obvious problem needing solution in the
3d CAD programs I once worked on, but no less here when several things are
overlain in a small space to convey information and they are interactive
too.

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

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

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

I do not like solutions that resort to special modifier key combinations
that are hard to remember and also lengthen the complete status bar
message. I would rather reserve shift- or control-click for a few things,
such as distinguishing new selection from adjustment, analogously with most
text editors.

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

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

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

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

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

PRL
Post by James Crook
Steve
Post by David Bailes
Post by James Crook
Post by Paul Licameli
The change is from the earlier of James' two commits at issue,
dc1193a,
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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,
Post by David Bailes
Post by James Crook
Post by Paul Licameli
for more reasons than just this bug.
So I want to fix 800 by better, general, means, or just not fix it
now.
Post by David Bailes
Post by James Crook
Post by Paul Licameli
But I have also worked on the "other means" -- the Tab key, the
changes
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
valuable.
But besides this, if the visible feature is not in, what will
certainly
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
state of things at https://github.com/audacity/audacity/commit/
<https://github.com/audacity/audacity/commit/dc1193a0af83f1d
43de5a30aea6b6b09087eea58>
Post by David Bailes
Post by James Crook
Post by Paul Licameli
6eac877de6453542dc278b2439eb0f9c983cee89 was a halfway state that
wasn't
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
Post by Paul Licameli
work is accomplished.
I was thinking that when we go for a beta testing period, then I want
to
Post by David Bailes
Post by James Crook
Post by Paul Licameli
load more of these needed internal changes in to get more benefit
from that
Post by David Bailes
Post by James Crook
Post by Paul Licameli
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
Post by David Bailes
Post by James Crook
early in release cycle, and incremental tweaks and local changes in
towards
Post by David Bailes
Post by James Crook
the end of a release cycle. Big changes can happen late in release
cycle
Post by David Bailes
Post by James Crook
too, and I am +1 for the expat upgrade for 2.2.0, but the RM needs to
be
Post by David Bailes
Post by James Crook
very ready to deal with the risks if they do make big changes late.
--James.
Post by Paul Licameli
PRL
------------------------------------------------------------
------------------
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...