Preview snap lines; revisiting Bug 800

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

Re: Preview snap lines; revisiting Bug 800

Peter Sampson-2


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

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

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

I think we would be creating a new bug that "Split lines are not visible
enough"

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


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

 
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.

 

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.
 

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

Me too.

 


Gale


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

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


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

Re: Preview snap lines; revisiting Bug 800

Peter Sampson-2
In reply to this post by Gale


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

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

+1

I find the new tri-partite line far too indiscernable - too easy to miss/overlook.
not significant enough for it's purpose.
 

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.
 


Gale

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

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


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

Re: Preview snap lines; revisiting Bug 800

Peter Sampson-2
In reply to this post by James Crook


On Fri, Jul 14, 2017 at 9:48 PM, James Crook <[hidden email]> wrote:
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

 

- I am fine with my fixes to bug 800 being reverted.

Glad to head that ;-)
 
- 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

 

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
 

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
 
The tooltips are horrid, in their current form, and need a rethink.  The flicker in them is just one problem.  I think tooltips should be for buttons and sliders only, show only after a delay, and they don't work in the larger areas.

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



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

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

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

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

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

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


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


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

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


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

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

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

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

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

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

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

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

--James.




PRL


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


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

Re: Preview snap lines; revisiting Bug 800

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


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

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

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.

 

And I dislike the appearance change.

Therefore, I call that I will revert it.

Good call, I think ...
 

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.
 


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

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

I want to hear more opinions about #3.

PRL


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

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

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

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

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



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

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

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

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

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

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


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


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

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


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

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

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

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

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

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

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

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

--James.




PRL


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


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



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

Re: Preview snap lines; revisiting Bug 800

Peter Sampson-2


On Sat, Jul 15, 2017 at 9:25 AM, Peter Sampson <[hidden email]> wrote:


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

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

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.

 

And I dislike the appearance change.

Therefore, I call that I will revert it.

Good call, I think ...
 

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.

 

Tooltips are good GUI because thay operate wher the user's visual attention is already focusssed.
 


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

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

I want to hear more opinions about #3.

PRL


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

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

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

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

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



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

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

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

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

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

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


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


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

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


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

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

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

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

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

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

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

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

--James.




PRL


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


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




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

Re: Preview snap lines; revisiting Bug 800

David Bailes-3
In reply to this post by James Crook
On Fri, Jul 14, 2017 at 9:48 PM, James Crook <[hidden email]> wrote:
This thread elsewhere is getting a bit heated!

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

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

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

+ 1, there should be a delay.
 
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) 
 

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



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

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

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

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

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

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


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


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

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

+1. More intuitive than Tab cycling. 


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

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

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

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

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

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

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

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

--James.




PRL


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


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

Re: Preview snap lines; revisiting Bug 800

Stevethefiddle
On 15 July 2017 at 13:47, David Bailes <[hidden email]> wrote:

> On Fri, Jul 14, 2017 at 9:48 PM, James Crook <[hidden email]> wrote:
>>
>> This thread elsewhere is getting a bit heated!
>>
>> - I am fine with my fixes to bug 800 being reverted.
>> - There is no necessity to fix the bug 800 problem at all for 2.2.0.
>>
>> I am very glad that groundwork has/is being put in place to abolish the
>> ToolsToolbar, which has always had a 'stuck in a mode' feel to it for me.
>> The bit that will interest me is where and how we will make grab handles for
>> clips - and the possibility that we will need to visually differentiate
>> squashy/stretchy clips/silence from clips/silence that is not
>> squashy/stretchy.   We will need to revisit the sync-lock concept too.
>>
>> A status message for Tab does not make Tab discoverable, but it really
>> doesn't matter!
>> Tab doesn't need to be discoverable in 2.2.0.
>>
>> The tooltips are horrid, in their current form, and need a rethink.  The
>> flicker in them is just one problem.  I think tooltips should be for buttons
>> and sliders only, show only after a delay,
>
>
> + 1, there should be a delay.
>
>>
>> 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)
>
>>
>>
>> I'd enjoy conversations about how multiple targets could be disambiguated
>> in 2.2.1.
>>
>>
>>
>> On 7/14/2017 7:42 PM, Paul Licameli wrote:
>>>
>>> On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
>>>
>>>> On 7/13/2017 10:10 PM, Paul Licameli wrote:
>>>>
>>>> Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>>>>
>>>>> (the finger cursor) was a hasty solution that shouldn't stand, and even
>>>>> James seemed to agree about that.
>>>>>
>>>> Split SplitLines, as in https://github.com/audacity/au
>>>> dacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
>>>> seem to me a workable/acceptable way of allowing selection and also
>>>> split
>>>> line removal at the exact same x coordinate.
>>>>
>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>>>> fd03e0b85bdf097b2ed37de9 is kind of 'virtual cursors', where every split
>>>> line is a virtual cursor.  Virtual cursors aren't a bad idea, but do
>>>> need
>>>> more thought.  For example it could make sense for every clip
>>>> boundary/snap-line to be a virtual cursor.    My implementation is only
>>>> 1px
>>>> wide, which is not consistent with true cursor.  My code is also, kind
>>>> of,
>>>> minimum effort to get the result, and I totally accept less hacky
>>>> implementation is possible.
>>>>
>>>> I think virtual cursors are unnecessary, but I did want to close Bug 800
>>>> quickly, and Gale felt that the cursor change and status message change
>>>> were essential.
>>>>
>>>>
>>> (What I don't understand about your comments.  Commit aa8be0c was about,
>>> simply, a cursor.  Explain "virtual.")
>>
>> It is just a way of looking at it Paul.  In my view there isn't an actual
>> cursor at the split line, but it as if there is one constructed temporarily
>> when you hover over it.  It becomes real, if you drag out from it.
>>
>>>
>>>> Gale gave Bug 800 a P2.  That makes it an RM decides.
>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>>>> fd03e0b85bdf097b2ed37de9 probably makes it possible to close Bug 800.
>>>> But it is also totally OK for RM to decide that
>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>>>> fd03e0b85bdf097b2ed37de9 is bad for the code, and that 'virtual cursors'
>>>> should therefore be postponed, and live with the P2, suitably updated,
>>>> for
>>>> 2.2.0.
>>>
>>>
>>> There is one important thing to find agreement on soon:  whether to keep
>>> the appearance change in split lines, which affects Peter's work.  I am
>>> not
>>> yet dictating it but will vote, -1.
>>
>> It does not need a vote.  You are RM, and I am just fine with you
>> reverting the appearance change.
>> In any case the appearance change I would have done, had I had more time,
>> would have been to put a symbol that you have to click on to join the clips.
>
>
> +1. More intuitive than Tab cycling.

That sounds like it could be good. I'd like to see that.

Steve

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

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

Re: Preview snap lines; revisiting Bug 800

Peter Sampson-2


On Sat, Jul 15, 2017 at 2:40 PM, Steve the Fiddle <[hidden email]> wrote:
On 15 July 2017 at 13:47, David Bailes <[hidden email]> wrote:
> On Fri, Jul 14, 2017 at 9:48 PM, James Crook <[hidden email]> wrote:
>>
>> This thread elsewhere is getting a bit heated!
>>
>> - I am fine with my fixes to bug 800 being reverted.
>> - There is no necessity to fix the bug 800 problem at all for 2.2.0.
>>
>> I am very glad that groundwork has/is being put in place to abolish the
>> ToolsToolbar, which has always had a 'stuck in a mode' feel to it for me.
>> The bit that will interest me is where and how we will make grab handles for
>> clips - and the possibility that we will need to visually differentiate
>> squashy/stretchy clips/silence from clips/silence that is not
>> squashy/stretchy.   We will need to revisit the sync-lock concept too.
>>
>> A status message for Tab does not make Tab discoverable, but it really
>> doesn't matter!
>> Tab doesn't need to be discoverable in 2.2.0.
>>
>> The tooltips are horrid, in their current form, and need a rethink.  The
>> flicker in them is just one problem.  I think tooltips should be for buttons
>> and sliders only, show only after a delay,
>
>
> + 1, there should be a delay.
>
>>
>> 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)
>
>>
>>
>> I'd enjoy conversations about how multiple targets could be disambiguated
>> in 2.2.1.
>>
>>
>>
>> On 7/14/2017 7:42 PM, Paul Licameli wrote:
>>>
>>> On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
>>>
>>>> On 7/13/2017 10:10 PM, Paul Licameli wrote:
>>>>
>>>> Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>>>>
>>>>> (the finger cursor) was a hasty solution that shouldn't stand, and even
>>>>> James seemed to agree about that.
>>>>>
>>>> Split SplitLines, as in https://github.com/audacity/au
>>>> dacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
>>>> seem to me a workable/acceptable way of allowing selection and also
>>>> split
>>>> line removal at the exact same x coordinate.
>>>>
>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>>>> fd03e0b85bdf097b2ed37de9 is kind of 'virtual cursors', where every split
>>>> line is a virtual cursor.  Virtual cursors aren't a bad idea, but do
>>>> need
>>>> more thought.  For example it could make sense for every clip
>>>> boundary/snap-line to be a virtual cursor.    My implementation is only
>>>> 1px
>>>> wide, which is not consistent with true cursor.  My code is also, kind
>>>> of,
>>>> minimum effort to get the result, and I totally accept less hacky
>>>> implementation is possible.
>>>>
>>>> I think virtual cursors are unnecessary, but I did want to close Bug 800
>>>> quickly, and Gale felt that the cursor change and status message change
>>>> were essential.
>>>>
>>>>
>>> (What I don't understand about your comments.  Commit aa8be0c was about,
>>> simply, a cursor.  Explain "virtual.")
>>
>> It is just a way of looking at it Paul.  In my view there isn't an actual
>> cursor at the split line, but it as if there is one constructed temporarily
>> when you hover over it.  It becomes real, if you drag out from it.
>>
>>>
>>>> Gale gave Bug 800 a P2.  That makes it an RM decides.
>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>>>> fd03e0b85bdf097b2ed37de9 probably makes it possible to close Bug 800.
>>>> But it is also totally OK for RM to decide that
>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>>>> fd03e0b85bdf097b2ed37de9 is bad for the code, and that 'virtual cursors'
>>>> should therefore be postponed, and live with the P2, suitably updated,
>>>> for
>>>> 2.2.0.
>>>
>>>
>>> There is one important thing to find agreement on soon:  whether to keep
>>> the appearance change in split lines, which affects Peter's work.  I am
>>> not
>>> yet dictating it but will vote, -1.
>>
>> It does not need a vote.  You are RM, and I am just fine with you
>> reverting the appearance change.
>> In any case the appearance change I would have done, had I had more time,
>> would have been to put a symbol that you have to click on to join the clips.
>
>
> +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.

 

Steve

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

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


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

Re: Preview snap lines; revisiting Bug 800

Gale
Administrator
In reply to this post by Stevethefiddle
On 14 July 2017 at 20:27, Steve the Fiddle <[hidden email]> wrote:

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

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


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

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

Re: Preview snap lines; revisiting Bug 800

Stevethefiddle
On 15 July 2017 at 16:32, Gale Andrews <[hidden email]> wrote:

> On 14 July 2017 at 20:27, Steve the Fiddle <[hidden email]> wrote:
>> On 14 July 2017 at 19:50, Gale Andrews <[hidden email]> wrote:
>>> On 14 July 2017 at 13:58, Steve the Fiddle <[hidden email]> wrote:
>>>> The thing that is bugging me is that we are having a protracted
>>>> discussion about a minor enhancement (as far as I'm aware there has
>>>> only ever been one person out of millions that considered bug 800 to
>>>> be more than a minor issue)
>>>
>>> This is nonsense/exaggeration. But it is P2 not P1 and RM sees it as
>>> worth pursuing. I am not convinced the positional solution with thicker
>>> centre is good so RM could decide to let this P2 through till 2.2.1.
>>
>> Perhaps you would like to comment on my main point Gale - the 52 P1
>> and P2 bugs, 24 days before the scheduled release date.
>
> 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.

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

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

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

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

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

Re: Preview snap lines; revisiting Bug 800

Peter Sampson-2
In reply to this post by Gale


On Sat, Jul 15, 2017 at 4:32 PM, Gale Andrews <[hidden email]> wrote:
On 14 July 2017 at 20:27, Steve the Fiddle <[hidden email]> wrote:
> On 14 July 2017 at 19:50, Gale Andrews <[hidden email]> wrote:
>> On 14 July 2017 at 13:58, Steve the Fiddle <[hidden email]> wrote:
>>> The thing that is bugging me is that we are having a protracted
>>> discussion about a minor enhancement (as far as I'm aware there has
>>> only ever been one person out of millions that considered bug 800 to
>>> be more than a minor issue)
>>
>> This is nonsense/exaggeration. But it is P2 not P1 and RM sees it as
>> worth pursuing. I am not convinced the positional solution with thicker
>> centre is good so RM could decide to let this P2 through till 2.2.1.
>
> Perhaps you would like to comment on my main point Gale - the 52 P1
> and P2 bugs, 24 days before the scheduled release date.

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

 

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.

 

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.

 
(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

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



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


 


Gale


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

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


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

Re: Preview snap lines; revisiting Bug 800

Gale
Administrator
In reply to this post by Peter Sampson-2
On 15 July 2017 at 16:29, Peter Sampson <[hidden email]> wrote:

>
>
> On Sat, Jul 15, 2017 at 2:40 PM, Steve the Fiddle <[hidden email]>
> wrote:
>>
>> On 15 July 2017 at 13:47, David Bailes <[hidden email]> wrote:
>> > On Fri, Jul 14, 2017 at 9:48 PM, James Crook <[hidden email]> wrote:
>> >>
>> >> This thread elsewhere is getting a bit heated!
>> >>
>> >> - I am fine with my fixes to bug 800 being reverted.
>> >> - There is no necessity to fix the bug 800 problem at all for 2.2.0.
>> >>
>> >> I am very glad that groundwork has/is being put in place to abolish the
>> >> ToolsToolbar, which has always had a 'stuck in a mode' feel to it for
>> >> me.
>> >> The bit that will interest me is where and how we will make grab
>> >> handles for
>> >> clips - and the possibility that we will need to visually differentiate
>> >> squashy/stretchy clips/silence from clips/silence that is not
>> >> squashy/stretchy.   We will need to revisit the sync-lock concept too.
>> >>
>> >> A status message for Tab does not make Tab discoverable, but it really
>> >> doesn't matter!
>> >> Tab doesn't need to be discoverable in 2.2.0.
>> >>
>> >> The tooltips are horrid, in their current form, and need a rethink.
>> >> The
>> >> flicker in them is just one problem.  I think tooltips should be for
>> >> buttons
>> >> and sliders only, show only after a delay,
>> >
>> >
>> > + 1, there should be a delay.
>> >
>> >>
>> >> 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)
>>
>> >
>> >>
>> >>
>> >> I'd enjoy conversations about how multiple targets could be
>> >> disambiguated
>> >> in 2.2.1.
>> >>
>> >>
>> >>
>> >> On 7/14/2017 7:42 PM, Paul Licameli wrote:
>> >>>
>> >>> On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
>> >>>
>> >>>> On 7/13/2017 10:10 PM, Paul Licameli wrote:
>> >>>>
>> >>>> Whereas I did think that commit
>> >>>> aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>> >>>>>
>> >>>>> (the finger cursor) was a hasty solution that shouldn't stand, and
>> >>>>> even
>> >>>>> James seemed to agree about that.
>> >>>>>
>> >>>> Split SplitLines, as in https://github.com/audacity/au
>> >>>> dacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
>> >>>> seem to me a workable/acceptable way of allowing selection and also
>> >>>> split
>> >>>> line removal at the exact same x coordinate.
>> >>>>
>> >>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>> >>>> fd03e0b85bdf097b2ed37de9 is kind of 'virtual cursors', where every
>> >>>> split
>> >>>> line is a virtual cursor.  Virtual cursors aren't a bad idea, but do
>> >>>> need
>> >>>> more thought.  For example it could make sense for every clip
>> >>>> boundary/snap-line to be a virtual cursor.    My implementation is
>> >>>> only
>> >>>> 1px
>> >>>> wide, which is not consistent with true cursor.  My code is also,
>> >>>> kind
>> >>>> of,
>> >>>> minimum effort to get the result, and I totally accept less hacky
>> >>>> implementation is possible.
>> >>>>
>> >>>> I think virtual cursors are unnecessary, but I did want to close Bug
>> >>>> 800
>> >>>> quickly, and Gale felt that the cursor change and status message
>> >>>> change
>> >>>> were essential.
>> >>>>
>> >>>>
>> >>> (What I don't understand about your comments.  Commit aa8be0c was
>> >>> about,
>> >>> simply, a cursor.  Explain "virtual.")
>> >>
>> >> It is just a way of looking at it Paul.  In my view there isn't an
>> >> actual
>> >> cursor at the split line, but it as if there is one constructed
>> >> temporarily
>> >> when you hover over it.  It becomes real, if you drag out from it.
>> >>
>> >>>
>> >>>> Gale gave Bug 800 a P2.  That makes it an RM decides.
>> >>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>> >>>> fd03e0b85bdf097b2ed37de9 probably makes it possible to close Bug 800.
>> >>>> But it is also totally OK for RM to decide that
>> >>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>> >>>> fd03e0b85bdf097b2ed37de9 is bad for the code, and that 'virtual
>> >>>> cursors'
>> >>>> should therefore be postponed, and live with the P2, suitably
>> >>>> updated,
>> >>>> for
>> >>>> 2.2.0.
>> >>>
>> >>>
>> >>> There is one important thing to find agreement on soon:  whether to
>> >>> keep
>> >>> the appearance change in split lines, which affects Peter's work.  I
>> >>> am
>> >>> not
>> >>> yet dictating it but will vote, -1.
>> >>
>> >> It does not need a vote.  You are RM, and I am just fine with you
>> >> reverting the appearance change.
>> >> In any case the appearance change I would have done, had I had more
>> >> time,
>> >> would have been to put a symbol that you have to click on to join the
>> >> clips.
>> >
>> >
>> > +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

>> >>> The change is from the earlier of James' two commits at issue,
>> >>> dc1193a,
>> >>> not
>> >>> part of the theming project.
>> >>>
>> >>> I dislike it, not as strongly as the later aa8be0c which changed the
>> >>> cursor, but I do dislike it too.  Gale has said he dislikes it, making
>> >>> the
>> >>> split line "too thin" for visibility -- I think this means the more
>> >>> prominent top and bottom are too thin.
>> >>>
>> >>> And at bottom I got the sense of a hasty and too special-case fix of
>> >>> what
>> >>> is really a more general problem -- what to do when there is more than
>> >>> one
>> >>> thing you may want to interact with near the pointer.  And that is
>> >>> something I have been thinking about, and preparing much groundwork
>> >>> for,
>> >>> for more reasons than just this bug.
>> >>>
>> >>> So I want to fix 800 by better, general, means, or just not fix it
>> >>> now.
>> >>> But I have also worked on the "other means" -- the Tab key, the
>> >>> changes
>> >>> in
>> >>> selection snapping, and the tooltips that aid in discovering these.
>> >>> (These
>> >>> three things are separable.  You can give me opinions about then
>> >>> separately.)  I will lobby hard for the features or something like
>> >>> them
>> >>> in
>> >>> 2.2.1, if they are not in sooner.
>> >>>
>> >>> I would like them sooner.  So please, try them, and give me opinions.
>> >>>
>> >>> I think they are the right direction to go.  Tab key can lead to
>> >>> abolishing
>> >>> the Tools toolbar, and also let us add interactive things to
>> >>> TrackPanel
>> >>> without needing to make more toolbar buttons.  Tab key can also escape
>> >>> snapping selection when you don't want it.  I think all of this is
>> >>> very
>> >>> valuable.
>> >>>
>> >>> But besides this, if the visible feature is not in, what will
>> >>> certainly
>> >>> be
>> >>> in, for the sake of future development, is a lot of the difficult
>> >>> internals
>> >>> work that make the feature easy to add.  Getting this work right is a
>> >>> major
>> >>> reason why the schedule slipped a bit, and I am not apologizing for
>> >>> insisting on making it right for 2.2.0.  I had come to realize that
>> >>> the
>> >>> state of things at https://github.com/audacity/audacity/commit/
>> >>>
>> >>>
>> >>> <https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58>
>> >>> 6eac877de6453542dc278b2439eb0f9c983cee89 was a halfway state that
>> >>> wasn't
>> >>> good enough, that the sort of problem James fixed at
>> >>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1677 needed more
>> >>> comprehensive work to be sure there were not others like it, and now
>> >>> that
>> >>> work is accomplished.
>> >>
>> >>
>> >>> I was thinking that when we go for a beta testing period, then I want
>> >>> to
>> >>> load more of these needed internal changes in to get more benefit from
>> >>> that
>> >>> period and lessen the motivation to do a beta period
>> >>> again in the next release.
>> >>
>> >> I'm not really buying into that logic,
>> >>
>> >> though I don't think it matters much.  I do buy in to the logic of
>> >> (generally) putting sweeping changes - restructuring and lib updates -
>> >> in
>> >> early in release cycle, and incremental tweaks and local changes in
>> >> towards
>> >> the end of a release cycle.  Big changes can happen late in release
>> >> cycle
>> >> too, and I am +1 for the expat upgrade for 2.2.0, but the RM needs to
>> >> be
>> >> very ready to deal with the risks if they do make big changes late.
>> >>
>> >> --James.
>> >>
>> >>
>> >>
>> >>>
>> >>> PRL
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

Re: Preview snap lines; revisiting Bug 800

Peter Sampson-2


On Sat, Jul 15, 2017 at 5:02 PM, Gale Andrews <[hidden email]> wrote:
On 15 July 2017 at 16:29, Peter Sampson <[hidden email]> wrote:
>
>
> On Sat, Jul 15, 2017 at 2:40 PM, Steve the Fiddle <[hidden email]>
> wrote:
>>
>> On 15 July 2017 at 13:47, David Bailes <[hidden email]> wrote:
>> > On Fri, Jul 14, 2017 at 9:48 PM, James Crook <[hidden email]> wrote:
>> >>
>> >> This thread elsewhere is getting a bit heated!
>> >>
>> >> - I am fine with my fixes to bug 800 being reverted.
>> >> - There is no necessity to fix the bug 800 problem at all for 2.2.0.
>> >>
>> >> I am very glad that groundwork has/is being put in place to abolish the
>> >> ToolsToolbar, which has always had a 'stuck in a mode' feel to it for
>> >> me.
>> >> The bit that will interest me is where and how we will make grab
>> >> handles for
>> >> clips - and the possibility that we will need to visually differentiate
>> >> squashy/stretchy clips/silence from clips/silence that is not
>> >> squashy/stretchy.   We will need to revisit the sync-lock concept too.
>> >>
>> >> A status message for Tab does not make Tab discoverable, but it really
>> >> doesn't matter!
>> >> Tab doesn't need to be discoverable in 2.2.0.
>> >>
>> >> The tooltips are horrid, in their current form, and need a rethink.
>> >> The
>> >> flicker in them is just one problem.  I think tooltips should be for
>> >> buttons
>> >> and sliders only, show only after a delay,
>> >
>> >
>> > + 1, there should be a delay.
>> >
>> >>
>> >> 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)
>>
>> >
>> >>
>> >>
>> >> I'd enjoy conversations about how multiple targets could be
>> >> disambiguated
>> >> in 2.2.1.
>> >>
>> >>
>> >>
>> >> On 7/14/2017 7:42 PM, Paul Licameli wrote:
>> >>>
>> >>> On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
>> >>>
>> >>>> On 7/13/2017 10:10 PM, Paul Licameli wrote:
>> >>>>
>> >>>> Whereas I did think that commit
>> >>>> aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>> >>>>>
>> >>>>> (the finger cursor) was a hasty solution that shouldn't stand, and
>> >>>>> even
>> >>>>> James seemed to agree about that.
>> >>>>>
>> >>>> Split SplitLines, as in https://github.com/audacity/au
>> >>>> dacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
>> >>>> seem to me a workable/acceptable way of allowing selection and also
>> >>>> split
>> >>>> line removal at the exact same x coordinate.
>> >>>>
>> >>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>> >>>> fd03e0b85bdf097b2ed37de9 is kind of 'virtual cursors', where every
>> >>>> split
>> >>>> line is a virtual cursor.  Virtual cursors aren't a bad idea, but do
>> >>>> need
>> >>>> more thought.  For example it could make sense for every clip
>> >>>> boundary/snap-line to be a virtual cursor.    My implementation is
>> >>>> only
>> >>>> 1px
>> >>>> wide, which is not consistent with true cursor.  My code is also,
>> >>>> kind
>> >>>> of,
>> >>>> minimum effort to get the result, and I totally accept less hacky
>> >>>> implementation is possible.
>> >>>>
>> >>>> I think virtual cursors are unnecessary, but I did want to close Bug
>> >>>> 800
>> >>>> quickly, and Gale felt that the cursor change and status message
>> >>>> change
>> >>>> were essential.
>> >>>>
>> >>>>
>> >>> (What I don't understand about your comments.  Commit aa8be0c was
>> >>> about,
>> >>> simply, a cursor.  Explain "virtual.")
>> >>
>> >> It is just a way of looking at it Paul.  In my view there isn't an
>> >> actual
>> >> cursor at the split line, but it as if there is one constructed
>> >> temporarily
>> >> when you hover over it.  It becomes real, if you drag out from it.
>> >>
>> >>>
>> >>>> Gale gave Bug 800 a P2.  That makes it an RM decides.
>> >>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>> >>>> fd03e0b85bdf097b2ed37de9 probably makes it possible to close Bug 800.
>> >>>> But it is also totally OK for RM to decide that
>> >>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>> >>>> fd03e0b85bdf097b2ed37de9 is bad for the code, and that 'virtual
>> >>>> cursors'
>> >>>> should therefore be postponed, and live with the P2, suitably
>> >>>> updated,
>> >>>> for
>> >>>> 2.2.0.
>> >>>
>> >>>
>> >>> There is one important thing to find agreement on soon:  whether to
>> >>> keep
>> >>> the appearance change in split lines, which affects Peter's work.  I
>> >>> am
>> >>> not
>> >>> yet dictating it but will vote, -1.
>> >>
>> >> It does not need a vote.  You are RM, and I am just fine with you
>> >> reverting the appearance change.
>> >> In any case the appearance change I would have done, had I had more
>> >> time,
>> >> would have been to put a symbol that you have to click on to join the
>> >> clips.
>> >
>> >
>> > +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.


 


Gale

>> >>> The change is from the earlier of James' two commits at issue,
>> >>> dc1193a,
>> >>> not
>> >>> part of the theming project.
>> >>>
>> >>> I dislike it, not as strongly as the later aa8be0c which changed the
>> >>> cursor, but I do dislike it too.  Gale has said he dislikes it, making
>> >>> the
>> >>> split line "too thin" for visibility -- I think this means the more
>> >>> prominent top and bottom are too thin.
>> >>>
>> >>> And at bottom I got the sense of a hasty and too special-case fix of
>> >>> what
>> >>> is really a more general problem -- what to do when there is more than
>> >>> one
>> >>> thing you may want to interact with near the pointer.  And that is
>> >>> something I have been thinking about, and preparing much groundwork
>> >>> for,
>> >>> for more reasons than just this bug.
>> >>>
>> >>> So I want to fix 800 by better, general, means, or just not fix it
>> >>> now.
>> >>> But I have also worked on the "other means" -- the Tab key, the
>> >>> changes
>> >>> in
>> >>> selection snapping, and the tooltips that aid in discovering these.
>> >>> (These
>> >>> three things are separable.  You can give me opinions about then
>> >>> separately.)  I will lobby hard for the features or something like
>> >>> them
>> >>> in
>> >>> 2.2.1, if they are not in sooner.
>> >>>
>> >>> I would like them sooner.  So please, try them, and give me opinions.
>> >>>
>> >>> I think they are the right direction to go.  Tab key can lead to
>> >>> abolishing
>> >>> the Tools toolbar, and also let us add interactive things to
>> >>> TrackPanel
>> >>> without needing to make more toolbar buttons.  Tab key can also escape
>> >>> snapping selection when you don't want it.  I think all of this is
>> >>> very
>> >>> valuable.
>> >>>
>> >>> But besides this, if the visible feature is not in, what will
>> >>> certainly
>> >>> be
>> >>> in, for the sake of future development, is a lot of the difficult
>> >>> internals
>> >>> work that make the feature easy to add.  Getting this work right is a
>> >>> major
>> >>> reason why the schedule slipped a bit, and I am not apologizing for
>> >>> insisting on making it right for 2.2.0.  I had come to realize that
>> >>> the
>> >>> state of things at https://github.com/audacity/audacity/commit/
>> >>>
>> >>>
>> >>> <https://github.com/audacity/audacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58>
>> >>> 6eac877de6453542dc278b2439eb0f9c983cee89 was a halfway state that
>> >>> wasn't
>> >>> good enough, that the sort of problem James fixed at
>> >>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1677 needed more
>> >>> comprehensive work to be sure there were not others like it, and now
>> >>> that
>> >>> work is accomplished.
>> >>
>> >>
>> >>> I was thinking that when we go for a beta testing period, then I want
>> >>> to
>> >>> load more of these needed internal changes in to get more benefit from
>> >>> that
>> >>> period and lessen the motivation to do a beta period
>> >>> again in the next release.
>> >>
>> >> I'm not really buying into that logic,
>> >>
>> >> though I don't think it matters much.  I do buy in to the logic of
>> >> (generally) putting sweeping changes - restructuring and lib updates -
>> >> in
>> >> early in release cycle, and incremental tweaks and local changes in
>> >> towards
>> >> the end of a release cycle.  Big changes can happen late in release
>> >> cycle
>> >> too, and I am +1 for the expat upgrade for 2.2.0, but the RM needs to
>> >> be
>> >> very ready to deal with the risks if they do make big changes late.
>> >>
>> >> --James.
>> >>
>> >>
>> >>
>> >>>
>> >>> PRL
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>


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

Re: Preview snap lines; revisiting Bug 800

James Crook
In reply to this post by Gale
On 7/15/2017 5:02 PM, Gale Andrews wrote:

> On 15 July 2017 at 16:29, Peter Sampson <[hidden email]> wrote:
>>
>> On Sat, Jul 15, 2017 at 2:40 PM, Steve the Fiddle <[hidden email]>
>> wrote:
>>> On 15 July 2017 at 13:47, David Bailes <[hidden email]> wrote:
>>>> On Fri, Jul 14, 2017 at 9:48 PM, James Crook <[hidden email]> wrote:
>>>>> 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.



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

Re: Preview snap lines; revisiting Bug 800

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


On Sat, Jul 15, 2017 at 11:29 AM, Peter Sampson <[hidden email]> wrote:


On Sat, Jul 15, 2017 at 2:40 PM, Steve the Fiddle <[hidden email]> wrote:
On 15 July 2017 at 13:47, David Bailes <[hidden email]> wrote:
> On Fri, Jul 14, 2017 at 9:48 PM, James Crook <[hidden email]> wrote:
>>
>> This thread elsewhere is getting a bit heated!
>>
>> - I am fine with my fixes to bug 800 being reverted.
>> - There is no necessity to fix the bug 800 problem at all for 2.2.0.
>>
>> I am very glad that groundwork has/is being put in place to abolish the
>> ToolsToolbar, which has always had a 'stuck in a mode' feel to it for me.
>> The bit that will interest me is where and how we will make grab handles for
>> clips - and the possibility that we will need to visually differentiate
>> squashy/stretchy clips/silence from clips/silence that is not
>> squashy/stretchy.   We will need to revisit the sync-lock concept too.
>>
>> A status message for Tab does not make Tab discoverable, but it really
>> doesn't matter!
>> Tab doesn't need to be discoverable in 2.2.0.
>>
>> The tooltips are horrid, in their current form, and need a rethink.  The
>> flicker in them is just one problem.  I think tooltips should be for buttons
>> and sliders only, show only after a delay,
>
>
> + 1, there should be a delay.
>
>>
>> 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)
>
>>
>>
>> I'd enjoy conversations about how multiple targets could be disambiguated
>> in 2.2.1.
>>
>>
>>
>> On 7/14/2017 7:42 PM, Paul Licameli wrote:
>>>
>>> On Fri, Jul 14, 2017 at 5:07 AM, James Crook <[hidden email]> wrote:
>>>
>>>> On 7/13/2017 10:10 PM, Paul Licameli wrote:
>>>>
>>>> Whereas I did think that commit aa8be0c413d107e3fd03e0b85bdf097b2ed37de9
>>>>>
>>>>> (the finger cursor) was a hasty solution that shouldn't stand, and even
>>>>> James seemed to agree about that.
>>>>>
>>>> Split SplitLines, as in https://github.com/audacity/au
>>>> dacity/commit/dc1193a0af83f1d43de5a30aea6b6b09087eea58
>>>> seem to me a workable/acceptable way of allowing selection and also
>>>> split
>>>> line removal at the exact same x coordinate.
>>>>
>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>>>> fd03e0b85bdf097b2ed37de9 is kind of 'virtual cursors', where every split
>>>> line is a virtual cursor.  Virtual cursors aren't a bad idea, but do
>>>> need
>>>> more thought.  For example it could make sense for every clip
>>>> boundary/snap-line to be a virtual cursor.    My implementation is only
>>>> 1px
>>>> wide, which is not consistent with true cursor.  My code is also, kind
>>>> of,
>>>> minimum effort to get the result, and I totally accept less hacky
>>>> implementation is possible.
>>>>
>>>> I think virtual cursors are unnecessary, but I did want to close Bug 800
>>>> quickly, and Gale felt that the cursor change and status message change
>>>> were essential.
>>>>
>>>>
>>> (What I don't understand about your comments.  Commit aa8be0c was about,
>>> simply, a cursor.  Explain "virtual.")
>>
>> It is just a way of looking at it Paul.  In my view there isn't an actual
>> cursor at the split line, but it as if there is one constructed temporarily
>> when you hover over it.  It becomes real, if you drag out from it.
>>
>>>
>>>> Gale gave Bug 800 a P2.  That makes it an RM decides.
>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>>>> fd03e0b85bdf097b2ed37de9 probably makes it possible to close Bug 800.
>>>> But it is also totally OK for RM to decide that
>>>> https://github.com/audacity/audacity/commit/aa8be0c413d107e3
>>>> fd03e0b85bdf097b2ed37de9 is bad for the code, and that 'virtual cursors'
>>>> should therefore be postponed, and live with the P2, suitably updated,
>>>> for
>>>> 2.2.0.
>>>
>>>
>>> There is one important thing to find agreement on soon:  whether to keep
>>> the appearance change in split lines, which affects Peter's work.  I am
>>> not
>>> yet dictating it but will vote, -1.
>>
>> It does not need a vote.  You are RM, and I am just fine with you
>> reverting the appearance change.
>> In any case the appearance change I would have done, had I had more time,
>> would have been to put a symbol that you have to click on to join the clips.
>
>
> +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

 

 

Steve

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

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


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



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

Re: Preview snap lines; revisiting Bug 800

Paul Licameli
In reply to this post by James Crook


On Sat, Jul 15, 2017 at 12:34 PM, James Crook <[hidden email]> wrote:
On 7/15/2017 5:02 PM, Gale Andrews wrote:
On 15 July 2017 at 16:29, Peter Sampson <[hidden email]> wrote:

On Sat, Jul 15, 2017 at 2:40 PM, Steve the Fiddle <[hidden email]>
wrote:
On 15 July 2017 at 13:47, David Bailes <[hidden email]> wrote:
On Fri, Jul 14, 2017 at 9:48 PM, James Crook <[hidden email]> wrote:
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




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


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

Re: Preview snap lines; revisiting Bug 800

Gale
Administrator
In reply to this post by Peter Sampson-2
On 15 July 2017 at 16:58, Peter Sampson <[hidden email]> wrote:

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

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

Re: Preview snap lines; revisiting Bug 800

Peter Sampson-2


On Mon, Jul 17, 2017 at 6:20 PM, Gale Andrews <[hidden email]> wrote:
On 15 July 2017 at 16:58, Peter Sampson <[hidden email]> wrote:
>
>
> On Sat, Jul 15, 2017 at 4:32 PM, Gale Andrews <[hidden email]> wrote:
>>
>> On 14 July 2017 at 20:27, Steve the Fiddle <[hidden email]>
>> wrote:
>> > On 14 July 2017 at 19:50, Gale Andrews <[hidden email]> wrote:
>> >> On 14 July 2017 at 13:58, Steve the Fiddle <[hidden email]>
>> >> wrote:
>> >>> The thing that is bugging me is that we are having a protracted
>> >>> discussion about a minor enhancement (as far as I'm aware there has
>> >>> only ever been one person out of millions that considered bug 800 to
>> >>> be more than a minor issue)
>> >>
>> >> This is nonsense/exaggeration. But it is P2 not P1 and RM sees it as
>> >> worth pursuing. I am not convinced the positional solution with thicker
>> >> centre is good so RM could decide to let this P2 through till 2.2.1.
>> >
>> > Perhaps you would like to comment on my main point Gale - the 52 P1
>> > and P2 bugs, 24 days before the scheduled release date.
>>
>> 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
>
>
>>
>>
>> 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.

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

 

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

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


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

Re: Preview snap lines; revisiting Bug 800

Paul Licameli


On Mon, Jul 17, 2017 at 1:35 PM, Peter Sampson <[hidden email]> wrote:


On Mon, Jul 17, 2017 at 6:20 PM, Gale Andrews <[hidden email]> wrote:
On 15 July 2017 at 16:58, Peter Sampson <[hidden email]> wrote:
>
>
> On Sat, Jul 15, 2017 at 4:32 PM, Gale Andrews <[hidden email]> wrote:
>>
>> On 14 July 2017 at 20:27, Steve the Fiddle <[hidden email]>
>> wrote:
>> > On 14 July 2017 at 19:50, Gale Andrews <[hidden email]> wrote:
>> >> On 14 July 2017 at 13:58, Steve the Fiddle <[hidden email]>
>> >> wrote:
>> >>> The thing that is bugging me is that we are having a protracted
>> >>> discussion about a minor enhancement (as far as I'm aware there has
>> >>> only ever been one person out of millions that considered bug 800 to
>> >>> be more than a minor issue)
>> >>
>> >> This is nonsense/exaggeration. But it is P2 not P1 and RM sees it as
>> >> worth pursuing. I am not convinced the positional solution with thicker
>> >> centre is good so RM could decide to let this P2 through till 2.2.1.
>> >
>> > Perhaps you would like to comment on my main point Gale - the 52 P1
>> > and P2 bugs, 24 days before the scheduled release date.
>>
>> 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
>
>
>>
>>
>> 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.

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.
 

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

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.


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

 

 

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

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


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



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