Discussion:
[Audacity-devel] Lighting more things up for mouse-over
Paul Licameli
2017-06-21 20:58:36 UTC
Permalink
As I have mentioned, I want to achieve more mouse-over highlighting in
TrackPanel, which might be a welcome complement to the theming work. I
hope to push in the next day or two, and then call a halt to my own new
development projects, and concentrate on bugs and other RM duties.

In general, whenever there is a thing on the screen that can interact with
the mouse, I think there ought to be either a cursor change or a change of
appearance of the thing, or both, with a few exceptions.

Here is an exhaustive list of the things you can interact with in
TrackPanel, divided in two. Tell me if you agree with my opinions about
what should and should not highlight.

Do highlight:

- Drag handles of labels. In fact this has already been done for a long
time. The turning-off of the highlight was lately broken, by me, but will
soon be fixed.
- Label text boxes.
- Buttons (close, menu, mute, solo, minimize). Because we do it for
toolbar buttons too.
- Channel buttons in Note tracks.
- The sample to be dragged in draw tool, and perhaps all other samples
too, less prominently.
- The point to be dragged on the envelope, perhaps previewing a point
not yet placed, and perhaps the rest of the curve, less prominently.
- Cutlines.
- Boundaries between clips.
- The time-shift grips at left and right in multi tool.
- Boundaries of the clips to be time-shifted, including those that would
be affected by sync lock; also labels (and note tracks?); and this is also
influenced by the Shift key.

The last item may be omitted as too much effort for right now.

Do not highlight:

- Click on the background to de-select tracks. (No special cursor
either, but so what.)
- Resizer areas under tracks and between channels.
- Vertical rulers (wave and note tracks).
- Select tool.
- Zoom tool.
- Note track stretch tool.
- Click on TCP to select or rearrange. (But should the cursor change to
a hand before you click?)

Finally:

- Sliders (velocity, pan, gain). Do or don't?

Making sliders highlight is not a problem proper to TrackPanel rewriting.
Rather it would change how class ASlider redraws itself, and would also
affect sliders in the toolbars, which do not yet highlight, and the sliders
in Mixer board, and in the double-click dialogs for pan and gain.

PRL
Gale Andrews
2017-06-21 23:01:00 UTC
Permalink
Post by Paul Licameli
As I have mentioned, I want to achieve more mouse-over highlighting in
TrackPanel, which might be a welcome complement to the theming work. I hope
to push in the next day or two, and then call a halt to my own new
development projects, and concentrate on bugs and other RM duties.
In general, whenever there is a thing on the screen that can interact with
the mouse, I think there ought to be either a cursor change or a change of
appearance of the thing, or both, with a few exceptions.
Here is an exhaustive list of the things you can interact with in
TrackPanel, divided in two. Tell me if you agree with my opinions about
what should and should not highlight.
Drag handles of labels. In fact this has already been done for a long time.
The turning-off of the highlight was lately broken, by me, but will soon be
fixed.
Label text boxes.
Buttons (close, menu, mute, solo, minimize). Because we do it for toolbar
buttons too.
Channel buttons in Note tracks.
The sample to be dragged in draw tool, and perhaps all other samples too,
less prominently.
The point to be dragged on the envelope, perhaps previewing a point not yet
placed, and perhaps the rest of the curve, less prominently.
Cutlines.
Boundaries between clips.
The time-shift grips at left and right in multi tool.
Boundaries of the clips to be time-shifted, including those that would be
affected by sync lock; also labels (and note tracks?); and this is also
influenced by the Shift key.
The last item may be omitted as too much effort for right now.
Click on the background to de-select tracks. (No special cursor either, but
so what.)
Resizer areas under tracks and between channels.
I feel very strongly the resizer should be highlighted. I can't see it
properly when it changes otherwise.


Gale
Post by Paul Licameli
Vertical rulers (wave and note tracks).
Select tool.
Zoom tool.
Note track stretch tool.
Click on TCP to select or rearrange. (But should the cursor change to a
hand before you click?)
Sliders (velocity, pan, gain). Do or don't?
Making sliders highlight is not a problem proper to TrackPanel rewriting.
Rather it would change how class ASlider redraws itself, and would also
affect sliders in the toolbars, which do not yet highlight, and the sliders
in Mixer board, and in the double-click dialogs for pan and gain.
PRL
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-06-22 09:35:32 UTC
Permalink
Post by Paul Licameli
As I have mentioned, I want to achieve more mouse-over highlighting in
TrackPanel, which might be a welcome complement to the theming work. I
hope to push in the next day or two, and then call a halt to my own new
development projects, and concentrate on bugs and other RM duties.
In general, whenever there is a thing on the screen that can interact with
the mouse, I think there ought to be either a cursor change or a change of
appearance of the thing, or both, with a few exceptions.
Here is an exhaustive list of the things you can interact with in
TrackPanel, divided in two. Tell me if you agree with my opinions about
what should and should not highlight.
- Drag handles of labels. In fact this has already been done for a
long time. The turning-off of the highlight was lately broken, by me, but
will soon be fixed.
This does not appera to be broken to me - testing on all 4 themes on
latest Windows
nightly on W10 audacity-win-r1c03eee-2.2.0-alpha-22-jun-17

In fact I use labels a lot and I'm bold enoughj to use the alphas as my
production syetems
and I have never notice label drag-handles not highlighting on mouseover
Post by Paul Licameli
- Label text boxes.
- Buttons (close, menu, mute, solo, minimize). Because we do it for
toolbar buttons too.
- Channel buttons in Note tracks.
- The sample to be dragged in draw tool, and perhaps all other samples
too, less prominently.
- The point to be dragged on the envelope, perhaps previewing a point
not yet placed, and perhaps the rest of the curve, less prominently.
- Cutlines.
- Boundaries between clips.
- The time-shift grips at left and right in multi tool.
- Boundaries of the clips to be time-shifted, including those that
would be affected by sync lock; also labels (and note tracks?); and this is
also influenced by the Shift key.
I don't recall any user requests for such highlightin in any Forum posts
of feature requests
over the years.

This does not mean that some of those would not be "nice to have" -
particularly the TCP ones,
I'm thinking that highlightiing the tools in the TCP could perhaps make
users more aware that
there is stuff that they can do with the TCP.

But it does mean that they should not be given a high priority for this
immediate release IMO.

However since you, Paul, are working on the TCP right now - I can see that
it might make sense
For you to make some mouseover highlights there.

Just be aware that the more you change, the more we have to test. And
changes like this now really
need testing on all four themes for completenes.

The other items in the list perhaps need more discussion - and that would
take place better in a
formal proposal or proposals in the Wiki rather than on hard-to-track
email.


The last item may be omitted as too much effort for right now.
Post by Paul Licameli
- Click on the background to de-select tracks. (No special cursor
either, but so what.)
- Resizer areas under tracks and between channels.
- Vertical rulers (wave and note tracks).
I can see an argument for highlighting Vertical Scale. We get many folk
accidentally clicking
there and then puzzling over why their waveform (vertical zoom level) has
changed,
So highlighting on mouseover could make them more aware tha "stuff might
happen".
Post by Paul Licameli
- Select tool.
Already hiighlighed on mouseover - why would you want to remove it?
- Zoom tool.
Already hiighlighed on mouseover - why would you want to remove it?
- Note track stretch tool.
- Click on TCP to select or rearrange. (But should the cursor change
to a hand before you click?)
No. It's fine I think that it changes to a hand (to indicate draggablity)
after you click.
But yes - no need for TCP to highlight on mouseover.
Post by Paul Licameli
- Sliders (velocity, pan, gain). Do or don't?
I can see an argument certainly for highlighlinf pan and gain sliders in
the TCP.
We know that folk accidentally nudge these from time to time (I've be burnt
by this)
so highlighting them on mouseover may make folk more aware of them

And this comes under my comments about TCP changes above (you're working
there now - so it would seem to be opportune.


*BTW I would have thought that such GUI design considerations belong better
on the *
*-quality list rather than the -devel list.*

Cheers,
Peter.
Post by Paul Licameli
Making sliders highlight is not a problem proper to TrackPanel rewriting.
Rather it would change how class ASlider redraws itself, and would also
affect sliders in the toolbars, which do not yet highlight, and the sliders
in Mixer board, and in the double-click dialogs for pan and gain.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-06-22 10:40:16 UTC
Permalink
All right, let's move this discussion to -quality.
Post by Peter Sampson
Post by Paul Licameli
As I have mentioned, I want to achieve more mouse-over highlighting in
TrackPanel, which might be a welcome complement to the theming work. I
hope to push in the next day or two, and then call a halt to my own new
development projects, and concentrate on bugs and other RM duties.
In general, whenever there is a thing on the screen that can interact
with the mouse, I think there ought to be either a cursor change or a
change of appearance of the thing, or both, with a few exceptions.
Here is an exhaustive list of the things you can interact with in
TrackPanel, divided in two. Tell me if you agree with my opinions about
what should and should not highlight.
- Drag handles of labels. In fact this has already been done for a
long time. The turning-off of the highlight was lately broken, by me, but
will soon be fixed.
This does not appera to be broken to me - testing on all 4 themes on
latest Windows
nightly on W10 audacity-win-r1c03eee-2.2.0-alpha-22-jun-17
In fact I use labels a lot and I'm bold enoughj to use the alphas as my
production syetems
and I have never notice label drag-handles not highlighting on mouseover
I must have misremembered. There was a failure to turn the highlights off
properly in one of my builds. But I agree this is not happening now in
head.
Post by Peter Sampson
Post by Paul Licameli
- Label text boxes.
- Buttons (close, menu, mute, solo, minimize). Because we do it for
toolbar buttons too.
- Channel buttons in Note tracks.
- The sample to be dragged in draw tool, and perhaps all other
samples too, less prominently.
- The point to be dragged on the envelope, perhaps previewing a point
not yet placed, and perhaps the rest of the curve, less prominently.
- Cutlines.
- Boundaries between clips.
- The time-shift grips at left and right in multi tool.
- Boundaries of the clips to be time-shifted, including those that
would be affected by sync lock; also labels (and note tracks?); and this is
also influenced by the Shift key.
I don't recall any user requests for such highlightin in any Forum posts
of feature requests
over the years.
This does not mean that some of those would not be "nice to have" -
particularly the TCP ones,
I'm thinking that highlightiing the tools in the TCP could perhaps make
users more aware that
there is stuff that they can do with the TCP.
But it does mean that they should not be given a high priority for this
immediate release IMO.
However since you, Paul, are working on the TCP right now - I can see that
it might make sense
For you to make some mouseover highlights there.
I need to tidy up some of the reorganized code, and while I work on it, I
want to make it possible and easy to write such highlighting if we want
it. My intention is to make an Experimental, and seek James' opinion about
which parts of it work well with the theming.

I would at least like to see the buttons light up, consistently with what
toolbar buttons do.
Post by Peter Sampson
Just be aware that the more you change, the more we have to test. And
changes like this now really
need testing on all four themes for completenes.
The other items in the list perhaps need more discussion - and that would
take place better in a
formal proposal or proposals in the Wiki rather than on hard-to-track
email.
The last item may be omitted as too much effort for right now.
Post by Paul Licameli
- Click on the background to de-select tracks. (No special cursor
either, but so what.)
- Resizer areas under tracks and between channels.
- Vertical rulers (wave and note tracks).
I can see an argument for highlighting Vertical Scale. We get many folk
accidentally clicking
there and then puzzling over why their waveform (vertical zoom level) has
changed,
So highlighting on mouseover could make them more aware tha "stuff might
happen".
Changing the cursor to magnifier isn't enough?
Post by Peter Sampson
Post by Paul Licameli
- Select tool.
Already hiighlighed on mouseover - why would you want to remove it?
I do not know what you refer to. There are cursor changes if you move the
pointer over an existing selection, including several for spectral
selection. By a highlight I mean something else. I mean something drawn
in the track panel changes appearance merely in response to mouse motion
without any mouse buttons down. This does not describe anything that
happens in the selection tool.
Post by Peter Sampson
Post by Paul Licameli
- Zoom tool.
Already hiighlighed on mouseover - why would you want to remove it?
Again, I do not know what you refer to. The cursor does change but nothing
highlights.
Post by Peter Sampson
Post by Paul Licameli
- Note track stretch tool.
- Click on TCP to select or rearrange. (But should the cursor change
to a hand before you click?)
No. It's fine I think that it changes to a hand (to indicate draggablity)
after you click.
But yes - no need for TCP to highlight on mouseover.
Post by Paul Licameli
- Sliders (velocity, pan, gain). Do or don't?
I can see an argument certainly for highlighlinf pan and gain sliders in
the TCP.
We know that folk accidentally nudge these from time to time (I've be
burnt by this)
so highlighting them on mouseover may make folk more aware of them
One reason for the "burn" may have been the other problem, now solved, that
when the track is resized short enough that one of the sliders disappears
near the bottom, the invisible slider was responding to mouse clicks. So,
honestly, one less argument there in favor of this.

PRL
Post by Peter Sampson
And this comes under my comments about TCP changes above (you're working
there now - so it would seem to be opportune.
*BTW I would have thought that such GUI design considerations belong
better on the *
*-quality list rather than the -devel list.*
Cheers,
Peter.
Post by Paul Licameli
Making sliders highlight is not a problem proper to TrackPanel
rewriting. Rather it would change how class ASlider redraws itself, and
would also affect sliders in the toolbars, which do not yet highlight, and
the sliders in Mixer board, and in the double-click dialogs for pan and
gain.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-06-22 11:34:28 UTC
Permalink
Post by Paul Licameli
All right, let's move this discussion to -quality.
On Thu, Jun 22, 2017 at 5:35 AM, Peter Sampson <
Post by Peter Sampson
Post by Paul Licameli
As I have mentioned, I want to achieve more mouse-over highlighting in
TrackPanel, which might be a welcome complement to the theming work. I
hope to push in the next day or two, and then call a halt to my own new
development projects, and concentrate on bugs and other RM duties.
In general, whenever there is a thing on the screen that can interact
with the mouse, I think there ought to be either a cursor change or a
change of appearance of the thing, or both, with a few exceptions.
Here is an exhaustive list of the things you can interact with in
TrackPanel, divided in two. Tell me if you agree with my opinions about
what should and should not highlight.
- Drag handles of labels. In fact this has already been done for a
long time. The turning-off of the highlight was lately broken, by me, but
will soon be fixed.
This does not appera to be broken to me - testing on all 4 themes on
latest Windows
nightly on W10 audacity-win-r1c03eee-2.2.0-alpha-22-jun-17
In fact I use labels a lot and I'm bold enoughj to use the alphas as my
production syetems
and I have never notice label drag-handles not highlighting on mouseover
I must have misremembered. There was a failure to turn the highlights off
properly in one of my builds. But I agree this is not happening now in
head.
Post by Peter Sampson
Post by Paul Licameli
- Label text boxes.
- Buttons (close, menu, mute, solo, minimize). Because we do it for
toolbar buttons too.
- Channel buttons in Note tracks.
- The sample to be dragged in draw tool, and perhaps all other
samples too, less prominently.
- The point to be dragged on the envelope, perhaps previewing a
point not yet placed, and perhaps the rest of the curve, less prominently.
- Cutlines.
- Boundaries between clips.
- The time-shift grips at left and right in multi tool.
- Boundaries of the clips to be time-shifted, including those that
would be affected by sync lock; also labels (and note tracks?); and this is
also influenced by the Shift key.
I don't recall any user requests for such highlightin in any Forum posts
of feature requests
over the years.
This does not mean that some of those would not be "nice to have" -
particularly the TCP ones,
I'm thinking that highlightiing the tools in the TCP could perhaps make
users more aware that
there is stuff that they can do with the TCP.
But it does mean that they should not be given a high priority for this
immediate release IMO.
However since you, Paul, are working on the TCP right now - I can see
that it might make sense
For you to make some mouseover highlights there.
I need to tidy up some of the reorganized code, and while I work on it, I
want to make it possible and easy to write such highlighting if we want
it. My intention is to make an Experimental, and seek James' opinion about
which parts of it work well with the theming.
I would at least like to see the buttons light up, consistently with what
toolbar buttons do.
Post by Peter Sampson
Just be aware that the more you change, the more we have to test. And
changes like this now really
need testing on all four themes for completenes.
The other items in the list perhaps need more discussion - and that would
take place better in a
formal proposal or proposals in the Wiki rather than on hard-to-track
email.
The last item may be omitted as too much effort for right now.
Post by Paul Licameli
- Click on the background to de-select tracks. (No special cursor
either, but so what.)
- Resizer areas under tracks and between channels.
- Vertical rulers (wave and note tracks).
I can see an argument for highlighting Vertical Scale. We get many folk
accidentally clicking
there and then puzzling over why their waveform (vertical zoom level) has
changed,
So highlighting on mouseover could make them more aware tha "stuff might
happen".
Changing the cursor to magnifier isn't enough?
It's a fairly subtle viual cue which I suspect many folk don;t notice ;-)
Post by Paul Licameli
Post by Peter Sampson
Post by Paul Licameli
- Select tool.
Already hiighlighed on mouseover - why would you want to remove it?
I do not know what you refer to. There are cursor changes if you move the
pointer over an existing selection, including several for spectral
selection. By a highlight I mean something else. I mean something drawn
in the track panel changes appearance merely in response to mouse motion
without any mouse buttons down. This does not describe anything that
happens in the selection tool.
I'm referring to the Tool is the Tools Toolbar wch highlight on mouseover.

Noe I'm confused about what you mean :-//
Post by Paul Licameli
Post by Peter Sampson
Post by Paul Licameli
- Zoom tool.
Already hiighlighed on mouseover - why would you want to remove it?
Again, I do not know what you refer to. The cursor does change but
nothing highlights.
Post by Peter Sampson
Post by Paul Licameli
- Note track stretch tool.
- Click on TCP to select or rearrange. (But should the cursor
change to a hand before you click?)
No. It's fine I think that it changes to a hand (to indicate draggablity)
after you click.
But yes - no need for TCP to highlight on mouseover.
Post by Paul Licameli
- Sliders (velocity, pan, gain). Do or don't?
I can see an argument certainly for highlighlinf pan and gain sliders in
the TCP.
We know that folk accidentally nudge these from time to time (I've be
burnt by this)
so highlighting them on mouseover may make folk more aware of them
One reason for the "burn" may have been the other problem, now solved,
that when the track is resized short enough that one of the sliders
disappears near the bottom, the invisible slider was responding to mouse
clicks. So, honestly, one less argument there in favor of this.
Not in my particualr case(s) I never shrink my tracks - I don't do
mult-track work.
Other users, maybe so ...
Post by Paul Licameli
PRL
Post by Peter Sampson
And this comes under my comments about TCP changes above (you're working
there now - so it would seem to be opportune.
*BTW I would have thought that such GUI design considerations belong
better on the *
*-quality list rather than the -devel list.*
Cheers,
Peter.
Post by Paul Licameli
Making sliders highlight is not a problem proper to TrackPanel
rewriting. Rather it would change how class ASlider redraws itself, and
would also affect sliders in the toolbars, which do not yet highlight, and
the sliders in Mixer board, and in the double-click dialogs for pan and
gain.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Loading...