Discussion:
The big TrackPanel refactor is pushed. It is only a beginning...
(too old to reply)
Paul Licameli
2017-06-15 13:37:50 UTC
Permalink
This is mostly an internal project, and a big one that has waited two years
to go in and had to have many conflicts resolved with later developments.

There are only a few (intended) consequences for user interface, most
notably that the ESC key before button-up can now abort all
click-drag-relase actions. I think these have no effect on documentation.
Please see the comments in commit 6eac877de6453542dc278b2439eb0f9c983cee89

There is some risk of disruptiveness. I think I have been thorough in
testing it first. Every possible mouse interaction with the track panel
(buttons, motion, scroll wheel [in tracks and in vertical rulers]) and
keystroke interactions that are not command shortcuts (ESC, and keystrokes
in label tracks) needed to be re-exercised.

..........

A lot of untangling of TrackPanel.cpp has been accomplished so that
dispatch of mouse and keystroke events are handled in a more
object-oriented way. Thousands of lines of code cut out of TrackPanel.cpp
and pasted into many other, new, smaller source code files, under certain
new virtual function interfaces.

This project is important to the future of Audacity development. It does
not yet define a complete "plug-in" protocol that would allow separately
compiled added controls that could even be added in dynamically loaded
libraries. But it is an advancement toward that.

(My opinion about the ill-defined notion of "plug-ins" has long been that
before we think of adding new features, we must first figure out how to
subtract existing features, so that they, first, become optional plug-ins
that prove the concept. Hence, this effort toward decoupling the code we
have.)

Still not yet done is to refactor the code that draws all details of
TrackPanel in a similar fashion. But that may prove a comparatively easy
thing and reasonable too as a goal for 2.2.0.

One question is whether certain other possible fruits of this project
should be pursued for 2.2.0. I am thinking of extending the protocol to
make it easier to code more mouse-over highlighting of interactive things
in the track panel, in a less ad-hoc fashion. One existing example of this
is the highlighting of the move and stretch handles of labels. I think it
would be nice to have more things like that -- like lighting up the TCP
buttons or the various hit targets in multi-tool. I think that could be a
good addition to the "face-lift" that has been the main focus of 2.2.0
development.

PRL
Paul Licameli
2017-06-15 15:06:24 UTC
Permalink
And I forgot to mention, track menu item code is moved too. And I just
discovered and fixed some errors in those.

PRL
Post by Paul Licameli
This is mostly an internal project, and a big one that has waited two
years to go in and had to have many conflicts resolved with later
developments.
There are only a few (intended) consequences for user interface, most
notably that the ESC key before button-up can now abort all
click-drag-relase actions. I think these have no effect on documentation.
Please see the comments in commit 6eac877de6453542dc278b2439eb0f9c983cee89
There is some risk of disruptiveness. I think I have been thorough in
testing it first. Every possible mouse interaction with the track panel
(buttons, motion, scroll wheel [in tracks and in vertical rulers]) and
keystroke interactions that are not command shortcuts (ESC, and keystrokes
in label tracks) needed to be re-exercised.
..........
A lot of untangling of TrackPanel.cpp has been accomplished so that
dispatch of mouse and keystroke events are handled in a more
object-oriented way. Thousands of lines of code cut out of TrackPanel.cpp
and pasted into many other, new, smaller source code files, under certain
new virtual function interfaces.
This project is important to the future of Audacity development. It does
not yet define a complete "plug-in" protocol that would allow separately
compiled added controls that could even be added in dynamically loaded
libraries. But it is an advancement toward that.
(My opinion about the ill-defined notion of "plug-ins" has long been that
before we think of adding new features, we must first figure out how to
subtract existing features, so that they, first, become optional plug-ins
that prove the concept. Hence, this effort toward decoupling the code we
have.)
Still not yet done is to refactor the code that draws all details of
TrackPanel in a similar fashion. But that may prove a comparatively easy
thing and reasonable too as a goal for 2.2.0.
One question is whether certain other possible fruits of this project
should be pursued for 2.2.0. I am thinking of extending the protocol to
make it easier to code more mouse-over highlighting of interactive things
in the track panel, in a less ad-hoc fashion. One existing example of this
is the highlighting of the move and stretch handles of labels. I think it
would be nice to have more things like that -- like lighting up the TCP
buttons or the various hit targets in multi-tool. I think that could be a
good addition to the "face-lift" that has been the main focus of 2.2.0
development.
PRL
Gale Andrews
2017-06-15 16:20:53 UTC
Permalink
Paul,

On Mac at 6eac87 (your refactor commit) I see at least three
problems:

1. Shift + M does not open the Track Dropdown Menu. Does your
subsequent anti-collision commit help there?
2 Pressing and releasing Command or Shift leaves the modified
icons still showing in Transport Toolbar. Clicking in the track
reverts the icons.
3 Showstopper: Up arrow from the focused label track bounces
focus back into the label track instead of staying in the audio track.

I do not see these issues on Windows at 6eac87 or on Mac a couple
of days ago (1620fe).



Gale
Post by Paul Licameli
And I forgot to mention, track menu item code is moved too. And I just
discovered and fixed some errors in those.
PRL
Post by Paul Licameli
This is mostly an internal project, and a big one that has waited two
years to go in and had to have many conflicts resolved with later
developments.
There are only a few (intended) consequences for user interface, most
notably that the ESC key before button-up can now abort all
click-drag-relase actions. I think these have no effect on documentation.
Please see the comments in commit 6eac877de6453542dc278b2439eb0f9c983cee89
There is some risk of disruptiveness. I think I have been thorough in
testing it first. Every possible mouse interaction with the track panel
(buttons, motion, scroll wheel [in tracks and in vertical rulers]) and
keystroke interactions that are not command shortcuts (ESC, and keystrokes
in label tracks) needed to be re-exercised.
..........
A lot of untangling of TrackPanel.cpp has been accomplished so that
dispatch of mouse and keystroke events are handled in a more object-oriented
way. Thousands of lines of code cut out of TrackPanel.cpp and pasted into
many other, new, smaller source code files, under certain new virtual
function interfaces.
This project is important to the future of Audacity development. It does
not yet define a complete "plug-in" protocol that would allow separately
compiled added controls that could even be added in dynamically loaded
libraries. But it is an advancement toward that.
(My opinion about the ill-defined notion of "plug-ins" has long been that
before we think of adding new features, we must first figure out how to
subtract existing features, so that they, first, become optional plug-ins
that prove the concept. Hence, this effort toward decoupling the code we
have.)
Still not yet done is to refactor the code that draws all details of
TrackPanel in a similar fashion. But that may prove a comparatively easy
thing and reasonable too as a goal for 2.2.0.
One question is whether certain other possible fruits of this project
should be pursued for 2.2.0. I am thinking of extending the protocol to
make it easier to code more mouse-over highlighting of interactive things in
the track panel, in a less ad-hoc fashion. One existing example of this is
the highlighting of the move and stretch handles of labels. I think it
would be nice to have more things like that -- like lighting up the TCP
buttons or the various hit targets in multi-tool. I think that could be a
good addition to the "face-lift" that has been the main focus of 2.2.0
development.
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-16 02:09:57 UTC
Permalink
Post by Gale Andrews
Paul,
On Mac at 6eac87 (your refactor commit) I see at least three
1. Shift + M does not open the Track Dropdown Menu. Does your
subsequent anti-collision commit help there?
2 Pressing and releasing Command or Shift leaves the modified
icons still showing in Transport Toolbar. Clicking in the track
reverts the icons.
3 Showstopper: Up arrow from the focused label track bounces
focus back into the label track instead of staying in the audio track.
I do not see these issues on Windows at 6eac87 or on Mac a couple
of days ago (1620fe).
Gale, thanks for testing. Find the fix at 8629363
PRL
Post by Gale Andrews
Gale
Post by Paul Licameli
And I forgot to mention, track menu item code is moved too. And I just
discovered and fixed some errors in those.
PRL
Post by Paul Licameli
This is mostly an internal project, and a big one that has waited two
years to go in and had to have many conflicts resolved with later
developments.
There are only a few (intended) consequences for user interface, most
notably that the ESC key before button-up can now abort all
click-drag-relase actions. I think these have no effect on
documentation.
Post by Paul Licameli
Post by Paul Licameli
Please see the comments in commit 6eac877de6453542dc278b2439eb0f
9c983cee89
Post by Paul Licameli
Post by Paul Licameli
There is some risk of disruptiveness. I think I have been thorough in
testing it first. Every possible mouse interaction with the track panel
(buttons, motion, scroll wheel [in tracks and in vertical rulers]) and
keystroke interactions that are not command shortcuts (ESC, and
keystrokes
Post by Paul Licameli
Post by Paul Licameli
in label tracks) needed to be re-exercised.
..........
A lot of untangling of TrackPanel.cpp has been accomplished so that
dispatch of mouse and keystroke events are handled in a more
object-oriented
Post by Paul Licameli
Post by Paul Licameli
way. Thousands of lines of code cut out of TrackPanel.cpp and pasted
into
Post by Paul Licameli
Post by Paul Licameli
many other, new, smaller source code files, under certain new virtual
function interfaces.
This project is important to the future of Audacity development. It
does
Post by Paul Licameli
Post by Paul Licameli
not yet define a complete "plug-in" protocol that would allow separately
compiled added controls that could even be added in dynamically loaded
libraries. But it is an advancement toward that.
(My opinion about the ill-defined notion of "plug-ins" has long been
that
Post by Paul Licameli
Post by Paul Licameli
before we think of adding new features, we must first figure out how to
subtract existing features, so that they, first, become optional
plug-ins
Post by Paul Licameli
Post by Paul Licameli
that prove the concept. Hence, this effort toward decoupling the code
we
Post by Paul Licameli
Post by Paul Licameli
have.)
Still not yet done is to refactor the code that draws all details of
TrackPanel in a similar fashion. But that may prove a comparatively
easy
Post by Paul Licameli
Post by Paul Licameli
thing and reasonable too as a goal for 2.2.0.
One question is whether certain other possible fruits of this project
should be pursued for 2.2.0. I am thinking of extending the protocol to
make it easier to code more mouse-over highlighting of interactive
things in
Post by Paul Licameli
Post by Paul Licameli
the track panel, in a less ad-hoc fashion. One existing example of
this is
Post by Paul Licameli
Post by Paul Licameli
the highlighting of the move and stretch handles of labels. I think it
would be nice to have more things like that -- like lighting up the TCP
buttons or the various hit targets in multi-tool. I think that could
be a
Post by Paul Licameli
Post by Paul Licameli
good addition to the "face-lift" that has been the main focus of 2.2.0
development.
PRL
------------------------------------------------------------
------------------
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Robert Hänggi
2017-06-16 07:49:44 UTC
Permalink
Hi

Error 1 error LNK2001: unresolved external symbol "public: static
struct HitTestResult __cdecl VelocitySliderHandle::HitTest(class
wxMouseEvent const &,class wxRect const &,class AudacityProject const
*,class Track *)"
(?***@VelocitySliderHandle@@SA?AUHitTestResult@@ABVwxMouseEvent@@ABVwxRect@@PBVAudacityProject@@PAVTrack@@@Z) C:\audacity\win\Projects\Audacity\NoteTrackControls.obj Audacity
On release build, I get the errors

Error 1 error LNK2001: unresolved external symbol "public: static
struct HitTestResult __cdecl VelocitySliderHandle::HitTest(class
wxMouseEvent const &,class wxRect const &,class AudacityProject const
*,class Track *)"
(?***@VelocitySliderHandle@@SA?AUHitTestResult@@ABVwxMouseEvent@@ABVwxRect@@PBVAudacityProject@@PAVTrack@@@Z) C:\audacity\win\Projects\Audacity\NoteTrackControls.obj Audacity

Error 2 error LNK1120: 1 unresolved
externals C:\audacity\win\Release\Audacity.exe 1 1 Audacity

Robert
Post by Paul Licameli
Post by Gale Andrews
Paul,
On Mac at 6eac87 (your refactor commit) I see at least three
1. Shift + M does not open the Track Dropdown Menu. Does your
subsequent anti-collision commit help there?
2 Pressing and releasing Command or Shift leaves the modified
icons still showing in Transport Toolbar. Clicking in the track
reverts the icons.
3 Showstopper: Up arrow from the focused label track bounces
focus back into the label track instead of staying in the audio track.
I do not see these issues on Windows at 6eac87 or on Mac a couple
of days ago (1620fe).
Gale, thanks for testing. Find the fix at 8629363
PRL
Post by Gale Andrews
Gale
Post by Paul Licameli
And I forgot to mention, track menu item code is moved too. And I just
discovered and fixed some errors in those.
PRL
On Thu, Jun 15, 2017 at 9:37 AM, Paul Licameli
Post by Paul Licameli
This is mostly an internal project, and a big one that has waited two
years to go in and had to have many conflicts resolved with later
developments.
There are only a few (intended) consequences for user interface, most
notably that the ESC key before button-up can now abort all
click-drag-relase actions. I think these have no effect on
documentation.
Post by Paul Licameli
Post by Paul Licameli
Please see the comments in commit 6eac877de6453542dc278b2439eb0f
9c983cee89
Post by Paul Licameli
Post by Paul Licameli
There is some risk of disruptiveness. I think I have been thorough in
testing it first. Every possible mouse interaction with the track panel
(buttons, motion, scroll wheel [in tracks and in vertical rulers]) and
keystroke interactions that are not command shortcuts (ESC, and
keystrokes
Post by Paul Licameli
Post by Paul Licameli
in label tracks) needed to be re-exercised.
..........
A lot of untangling of TrackPanel.cpp has been accomplished so that
dispatch of mouse and keystroke events are handled in a more
object-oriented
Post by Paul Licameli
Post by Paul Licameli
way. Thousands of lines of code cut out of TrackPanel.cpp and pasted
into
Post by Paul Licameli
Post by Paul Licameli
many other, new, smaller source code files, under certain new virtual
function interfaces.
This project is important to the future of Audacity development. It
does
Post by Paul Licameli
Post by Paul Licameli
not yet define a complete "plug-in" protocol that would allow separately
compiled added controls that could even be added in dynamically loaded
libraries. But it is an advancement toward that.
(My opinion about the ill-defined notion of "plug-ins" has long been
that
Post by Paul Licameli
Post by Paul Licameli
before we think of adding new features, we must first figure out how to
subtract existing features, so that they, first, become optional
plug-ins
Post by Paul Licameli
Post by Paul Licameli
that prove the concept. Hence, this effort toward decoupling the code
we
Post by Paul Licameli
Post by Paul Licameli
have.)
Still not yet done is to refactor the code that draws all details of
TrackPanel in a similar fashion. But that may prove a comparatively
easy
Post by Paul Licameli
Post by Paul Licameli
thing and reasonable too as a goal for 2.2.0.
One question is whether certain other possible fruits of this project
should be pursued for 2.2.0. I am thinking of extending the protocol to
make it easier to code more mouse-over highlighting of interactive
things in
Post by Paul Licameli
Post by Paul Licameli
the track panel, in a less ad-hoc fashion. One existing example of
this is
Post by Paul Licameli
Post by Paul Licameli
the highlighting of the move and stretch handles of labels. I think it
would be nice to have more things like that -- like lighting up the TCP
buttons or the various hit targets in multi-tool. I think that could
be a
Post by Paul Licameli
Post by Paul Licameli
good addition to the "face-lift" that has been the main focus of 2.2.0
development.
PRL
------------------------------------------------------------
------------------
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Henric Jungheim
2017-06-16 08:35:36 UTC
Permalink
Audacity.vcxproj is missing NoteTrackSliderHandles.*

https://github.com/henricj/audacity/commit/25f32f32bd3678eb0152cca8c4be99b4d9b45e9c
Post by Robert Hänggi
Hi
Error 1 error LNK2001: unresolved external symbol "public: static
struct HitTestResult __cdecl VelocitySliderHandle::HitTest(class
wxMouseEvent const &,class wxRect const &,class AudacityProject const
*,class Track *)"
On release build, I get the errors
Error 1 error LNK2001: unresolved external symbol "public: static
struct HitTestResult __cdecl VelocitySliderHandle::HitTest(class
wxMouseEvent const &,class wxRect const &,class AudacityProject const
*,class Track *)"
Error 2 error LNK1120: 1 unresolved
externals C:\audacity\win\Release\Audacity.exe 1 1 Audacity
Robert
Post by Paul Licameli
Post by Gale Andrews
Paul,
On Mac at 6eac87 (your refactor commit) I see at least three
1. Shift + M does not open the Track Dropdown Menu. Does your
subsequent anti-collision commit help there?
2 Pressing and releasing Command or Shift leaves the modified
icons still showing in Transport Toolbar. Clicking in the track
reverts the icons.
3 Showstopper: Up arrow from the focused label track bounces
focus back into the label track instead of staying in the audio track.
I do not see these issues on Windows at 6eac87 or on Mac a couple
of days ago (1620fe).
Gale, thanks for testing. Find the fix at 8629363
PRL
Post by Gale Andrews
Gale
Post by Paul Licameli
And I forgot to mention, track menu item code is moved too. And I just
discovered and fixed some errors in those.
PRL
On Thu, Jun 15, 2017 at 9:37 AM, Paul Licameli
Post by Paul Licameli
This is mostly an internal project, and a big one that has waited two
years to go in and had to have many conflicts resolved with later
developments.
There are only a few (intended) consequences for user interface, most
notably that the ESC key before button-up can now abort all
click-drag-relase actions. I think these have no effect on
documentation.
Post by Paul Licameli
Post by Paul Licameli
Please see the comments in commit 6eac877de6453542dc278b2439eb0f
9c983cee89
Post by Paul Licameli
Post by Paul Licameli
There is some risk of disruptiveness. I think I have been thorough in
testing it first. Every possible mouse interaction with the track panel
(buttons, motion, scroll wheel [in tracks and in vertical rulers]) and
keystroke interactions that are not command shortcuts (ESC, and
keystrokes
Post by Paul Licameli
Post by Paul Licameli
in label tracks) needed to be re-exercised.
..........
A lot of untangling of TrackPanel.cpp has been accomplished so that
dispatch of mouse and keystroke events are handled in a more
object-oriented
Post by Paul Licameli
Post by Paul Licameli
way. Thousands of lines of code cut out of TrackPanel.cpp and pasted
into
Post by Paul Licameli
Post by Paul Licameli
many other, new, smaller source code files, under certain new virtual
function interfaces.
This project is important to the future of Audacity development. It
does
Post by Paul Licameli
Post by Paul Licameli
not yet define a complete "plug-in" protocol that would allow separately
compiled added controls that could even be added in dynamically loaded
libraries. But it is an advancement toward that.
(My opinion about the ill-defined notion of "plug-ins" has long been
that
Post by Paul Licameli
Post by Paul Licameli
before we think of adding new features, we must first figure out how to
subtract existing features, so that they, first, become optional
plug-ins
Post by Paul Licameli
Post by Paul Licameli
that prove the concept. Hence, this effort toward decoupling the code
we
Post by Paul Licameli
Post by Paul Licameli
have.)
Still not yet done is to refactor the code that draws all details of
TrackPanel in a similar fashion. But that may prove a comparatively
easy
Post by Paul Licameli
Post by Paul Licameli
thing and reasonable too as a goal for 2.2.0.
One question is whether certain other possible fruits of this project
should be pursued for 2.2.0. I am thinking of extending the protocol to
make it easier to code more mouse-over highlighting of interactive
things in
Post by Paul Licameli
Post by Paul Licameli
the track panel, in a less ad-hoc fashion. One existing example of
this is
Post by Paul Licameli
Post by Paul Licameli
the highlighting of the move and stretch handles of labels. I think it
would be nice to have more things like that -- like lighting up the TCP
buttons or the various hit targets in multi-tool. I think that could
be a
Post by Paul Licameli
Post by Paul Licameli
good addition to the "face-lift" that has been the main focus of 2.2.0
development.
PRL
------------------------------------------------------------
------------------
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-06-17 04:55:19 UTC
Permalink
Post by Henric Jungheim
Audacity.vcxproj is missing NoteTrackSliderHandles.*
https://github.com/henricj/audacity/commit/25f32f32bd3678eb0152cca8c4be99
b4d9b45e9c
Thank you for catching my omission.

PRL
Post by Henric Jungheim
Hi
Error 1 error LNK2001: unresolved external symbol "public: static
struct HitTestResult __cdecl VelocitySliderHandle::HitTest(class
wxMouseEvent const &,class wxRect const &,class AudacityProject const
*,class Track *)"
@ABVwxRect@@PBVAudacityProject@@PAVTrack@@@Z)
C:\audacity\win\Projects\Audacity\NoteTrackControls.obj Audacity
On release build, I get the errors
Error 1 error LNK2001: unresolved external symbol "public: static
struct HitTestResult __cdecl VelocitySliderHandle::HitTest(class
wxMouseEvent const &,class wxRect const &,class AudacityProject const
*,class Track *)"
@ABVwxRect@@PBVAudacityProject@@PAVTrack@@@Z)
C:\audacity\win\Projects\Audacity\NoteTrackControls.obj Audacity
Error 2 error LNK1120: 1 unresolved
externals C:\audacity\win\Release\Audacity.exe 1 1
Audacity
Robert
Post by Paul Licameli
Post by Gale Andrews
Paul,
On Mac at 6eac87 (your refactor commit) I see at least three
1. Shift + M does not open the Track Dropdown Menu. Does your
subsequent anti-collision commit help there?
2 Pressing and releasing Command or Shift leaves the modified
icons still showing in Transport Toolbar. Clicking in the track
reverts the icons.
3 Showstopper: Up arrow from the focused label track bounces
focus back into the label track instead of staying in the audio track.
I do not see these issues on Windows at 6eac87 or on Mac a couple
of days ago (1620fe).
Gale, thanks for testing. Find the fix at 8629363
PRL
Post by Gale Andrews
Gale
Post by Paul Licameli
And I forgot to mention, track menu item code is moved too. And I
just
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
discovered and fixed some errors in those.
PRL
On Thu, Jun 15, 2017 at 9:37 AM, Paul Licameli
Post by Paul Licameli
This is mostly an internal project, and a big one that has waited
two
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
years to go in and had to have many conflicts resolved with later
developments.
There are only a few (intended) consequences for user interface,
most
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
notably that the ESC key before button-up can now abort all
click-drag-relase actions. I think these have no effect on
documentation.
Post by Paul Licameli
Post by Paul Licameli
Please see the comments in commit 6eac877de6453542dc278b2439eb0f
9c983cee89
Post by Paul Licameli
Post by Paul Licameli
There is some risk of disruptiveness. I think I have been
thorough in
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
testing it first. Every possible mouse interaction with the track panel
(buttons, motion, scroll wheel [in tracks and in vertical rulers])
and
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
keystroke interactions that are not command shortcuts (ESC, and
keystrokes
Post by Paul Licameli
Post by Paul Licameli
in label tracks) needed to be re-exercised.
..........
A lot of untangling of TrackPanel.cpp has been accomplished so that
dispatch of mouse and keystroke events are handled in a more
object-oriented
Post by Paul Licameli
Post by Paul Licameli
way. Thousands of lines of code cut out of TrackPanel.cpp and
pasted
Post by Paul Licameli
Post by Gale Andrews
into
Post by Paul Licameli
Post by Paul Licameli
many other, new, smaller source code files, under certain new
virtual
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
function interfaces.
This project is important to the future of Audacity development.
It
Post by Paul Licameli
Post by Gale Andrews
does
Post by Paul Licameli
Post by Paul Licameli
not yet define a complete "plug-in" protocol that would allow separately
compiled added controls that could even be added in dynamically
loaded
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
libraries. But it is an advancement toward that.
(My opinion about the ill-defined notion of "plug-ins" has long
been
Post by Paul Licameli
Post by Gale Andrews
that
Post by Paul Licameli
Post by Paul Licameli
before we think of adding new features, we must first figure out
how
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
to
subtract existing features, so that they, first, become optional
plug-ins
Post by Paul Licameli
Post by Paul Licameli
that prove the concept. Hence, this effort toward decoupling the
code
Post by Paul Licameli
Post by Gale Andrews
we
Post by Paul Licameli
Post by Paul Licameli
have.)
Still not yet done is to refactor the code that draws all details
of
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
TrackPanel in a similar fashion. But that may prove a
comparatively
Post by Paul Licameli
Post by Gale Andrews
easy
Post by Paul Licameli
Post by Paul Licameli
thing and reasonable too as a goal for 2.2.0.
One question is whether certain other possible fruits of this
project
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
should be pursued for 2.2.0. I am thinking of extending the
protocol
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
to
make it easier to code more mouse-over highlighting of interactive
things in
Post by Paul Licameli
Post by Paul Licameli
the track panel, in a less ad-hoc fashion. One existing example of
this is
Post by Paul Licameli
Post by Paul Licameli
the highlighting of the move and stretch handles of labels. I
think
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
it
would be nice to have more things like that -- like lighting up the TCP
buttons or the various hit targets in multi-tool. I think that
could
Post by Paul Licameli
Post by Gale Andrews
be a
Post by Paul Licameli
Post by Paul Licameli
good addition to the "face-lift" that has been the main focus of
2.2.0
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
development.
PRL
------------------------------------------------------------
------------------
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-06-16 22:00:07 UTC
Permalink
Paul,

Not tested Mac because Windows now has the focus border issue
(d2187b).

1 Create audio track. Play it, Ctrl + M to add a label at playback
position. The label is created. Type the label contents. Nothing is
typed because after label creation, the audio track takes the focus
again.

2 Press Down arrow while focus is in the label track. Focus won't
stay in the label track. Same problem if arrowing down into another
audio track. Focus does not stay.



Gale
Post by Paul Licameli
Post by Gale Andrews
Paul,
On Mac at 6eac87 (your refactor commit) I see at least three
1. Shift + M does not open the Track Dropdown Menu. Does your
subsequent anti-collision commit help there?
2 Pressing and releasing Command or Shift leaves the modified
icons still showing in Transport Toolbar. Clicking in the track
reverts the icons.
3 Showstopper: Up arrow from the focused label track bounces
focus back into the label track instead of staying in the audio track.
I do not see these issues on Windows at 6eac87 or on Mac a couple
of days ago (1620fe).
Gale, thanks for testing. Find the fix at 8629363
PRL
Post by Gale Andrews
Gale
Post by Paul Licameli
And I forgot to mention, track menu item code is moved too. And I just
discovered and fixed some errors in those.
PRL
Post by Paul Licameli
This is mostly an internal project, and a big one that has waited two
years to go in and had to have many conflicts resolved with later
developments.
There are only a few (intended) consequences for user interface, most
notably that the ESC key before button-up can now abort all
click-drag-relase actions. I think these have no effect on documentation.
Please see the comments in commit
6eac877de6453542dc278b2439eb0f9c983cee89
There is some risk of disruptiveness. I think I have been thorough in
testing it first. Every possible mouse interaction with the track panel
(buttons, motion, scroll wheel [in tracks and in vertical rulers]) and
keystroke interactions that are not command shortcuts (ESC, and keystrokes
in label tracks) needed to be re-exercised.
..........
A lot of untangling of TrackPanel.cpp has been accomplished so that
dispatch of mouse and keystroke events are handled in a more object-oriented
way. Thousands of lines of code cut out of TrackPanel.cpp and pasted into
many other, new, smaller source code files, under certain new virtual
function interfaces.
This project is important to the future of Audacity development. It does
not yet define a complete "plug-in" protocol that would allow separately
compiled added controls that could even be added in dynamically loaded
libraries. But it is an advancement toward that.
(My opinion about the ill-defined notion of "plug-ins" has long been that
before we think of adding new features, we must first figure out how to
subtract existing features, so that they, first, become optional plug-ins
that prove the concept. Hence, this effort toward decoupling the code we
have.)
Still not yet done is to refactor the code that draws all details of
TrackPanel in a similar fashion. But that may prove a comparatively easy
thing and reasonable too as a goal for 2.2.0.
One question is whether certain other possible fruits of this project
should be pursued for 2.2.0. I am thinking of extending the protocol to
make it easier to code more mouse-over highlighting of interactive things in
the track panel, in a less ad-hoc fashion. One existing example of this is
the highlighting of the move and stretch handles of labels. I think it
would be nice to have more things like that -- like lighting up the TCP
buttons or the various hit targets in multi-tool. I think that could be a
good addition to the "face-lift" that has been the main focus of 2.2.0
development.
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-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-06-16 22:14:12 UTC
Permalink
Post by Gale Andrews
Paul,
Not tested Mac because Windows now has the focus border issue
(d2187b).
1 Create audio track. Play it, Ctrl + M to add a label at playback
position. The label is created. Type the label contents. Nothing is
typed because after label creation, the audio track takes the focus
again.
2 Press Down arrow while focus is in the label track. Focus won't
stay in the label track. Same problem if arrowing down into another
audio track. Focus does not stay.
Gale, I just tried these things on Mac, at
43d1c774bf5b1e349603f4cb486f60fba9530835, after my latest changes.

I cannot reporoduce 1.

Neither 2, unless I enable ' "Move track focus" cycles repeatedly through
tracks ' in Tracks Behaviors preferences, and then, that is the correct
behavior.

PRL
Post by Gale Andrews
Gale
Post by Paul Licameli
Post by Gale Andrews
Paul,
On Mac at 6eac87 (your refactor commit) I see at least three
1. Shift + M does not open the Track Dropdown Menu. Does your
subsequent anti-collision commit help there?
2 Pressing and releasing Command or Shift leaves the modified
icons still showing in Transport Toolbar. Clicking in the track
reverts the icons.
3 Showstopper: Up arrow from the focused label track bounces
focus back into the label track instead of staying in the audio
track.
Post by Paul Licameli
Post by Gale Andrews
I do not see these issues on Windows at 6eac87 or on Mac a couple
of days ago (1620fe).
Gale, thanks for testing. Find the fix at 8629363
PRL
Post by Gale Andrews
Gale
Post by Paul Licameli
And I forgot to mention, track menu item code is moved too. And I
just
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
discovered and fixed some errors in those.
PRL
On Thu, Jun 15, 2017 at 9:37 AM, Paul Licameli <
Post by Paul Licameli
This is mostly an internal project, and a big one that has waited two
years to go in and had to have many conflicts resolved with later
developments.
There are only a few (intended) consequences for user interface, most
notably that the ESC key before button-up can now abort all
click-drag-relase actions. I think these have no effect on documentation.
Please see the comments in commit
6eac877de6453542dc278b2439eb0f9c983cee89
There is some risk of disruptiveness. I think I have been thorough
in
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
testing it first. Every possible mouse interaction with the track panel
(buttons, motion, scroll wheel [in tracks and in vertical rulers])
and
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
keystroke interactions that are not command shortcuts (ESC, and keystrokes
in label tracks) needed to be re-exercised.
..........
A lot of untangling of TrackPanel.cpp has been accomplished so that
dispatch of mouse and keystroke events are handled in a more object-oriented
way. Thousands of lines of code cut out of TrackPanel.cpp and pasted into
many other, new, smaller source code files, under certain new virtual
function interfaces.
This project is important to the future of Audacity development. It does
not yet define a complete "plug-in" protocol that would allow separately
compiled added controls that could even be added in dynamically
loaded
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
libraries. But it is an advancement toward that.
(My opinion about the ill-defined notion of "plug-ins" has long been that
before we think of adding new features, we must first figure out how
to
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
subtract existing features, so that they, first, become optional plug-ins
that prove the concept. Hence, this effort toward decoupling the
code
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
we
have.)
Still not yet done is to refactor the code that draws all details of
TrackPanel in a similar fashion. But that may prove a comparatively easy
thing and reasonable too as a goal for 2.2.0.
One question is whether certain other possible fruits of this project
should be pursued for 2.2.0. I am thinking of extending the protocol to
make it easier to code more mouse-over highlighting of interactive things in
the track panel, in a less ad-hoc fashion. One existing example of this is
the highlighting of the move and stretch handles of labels. I think
it
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
would be nice to have more things like that -- like lighting up the
TCP
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
buttons or the various hit targets in multi-tool. I think that could be a
good addition to the "face-lift" that has been the main focus of
2.2.0
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Paul Licameli
development.
PRL
------------------------------------------------------------
------------------
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Paul Licameli
Post by Gale Andrews
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Post by Paul Licameli
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-06-17 13:52:22 UTC
Permalink
Post by Paul Licameli
Post by Gale Andrews
Paul,
Not tested Mac because Windows now has the focus border issue
(d2187b).
1 Create audio track. Play it, Ctrl + M to add a label at playback
position. The label is created. Type the label contents. Nothing is
typed because after label creation, the audio track takes the focus
again.
2 Press Down arrow while focus is in the label track. Focus won't
stay in the label track. Same problem if arrowing down into another
audio track. Focus does not stay.
Gale, I just tried these things on Mac, at
43d1c774bf5b1e349603f4cb486f60fba9530835, after my latest changes.
I cannot reporoduce 1.
Neither 2, unless I enable ' "Move track focus" cycles repeatedly through
tracks ' in Tracks Behaviors preferences, and then, that is the correct
behavior.
PRL
Hi Paul,

I was referring to Windows, not Mac. Windows behaved exactly as I
described at d2187b. Those problems do seem to have resolved
themselves now though at current HEAD.

" "Move track focus" cycles repeatedly through tracks" does not cause the
focus to jump back up if you only press Down arrow once as I was doing.
In any case I did not have that option enabled.

I found a crash in HEAD as it now is (d7a9c1, Windows 10).

1 Generate a tone.
2 Duplicate the tone.
3 In the Track Dropdown Menu of the lower track, choose "Move Track Up".


Gale
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Gale Andrews
Paul,
On Mac at 6eac87 (your refactor commit) I see at least three
1. Shift + M does not open the Track Dropdown Menu. Does your
subsequent anti-collision commit help there?
2 Pressing and releasing Command or Shift leaves the modified
icons still showing in Transport Toolbar. Clicking in the track
reverts the icons.
3 Showstopper: Up arrow from the focused label track bounces
focus back into the label track instead of staying in the audio track.
I do not see these issues on Windows at 6eac87 or on Mac a couple
of days ago (1620fe).
Gale, thanks for testing. Find the fix at 8629363
PRL
Post by Gale Andrews
Gale
Post by Paul Licameli
And I forgot to mention, track menu item code is moved too. And I just
discovered and fixed some errors in those.
PRL
On Thu, Jun 15, 2017 at 9:37 AM, Paul Licameli
Post by Paul Licameli
This is mostly an internal project, and a big one that has waited two
years to go in and had to have many conflicts resolved with later
developments.
There are only a few (intended) consequences for user interface, most
notably that the ESC key before button-up can now abort all
click-drag-relase actions. I think these have no effect on documentation.
Please see the comments in commit
6eac877de6453542dc278b2439eb0f9c983cee89
There is some risk of disruptiveness. I think I have been thorough in
testing it first. Every possible mouse interaction with the track panel
(buttons, motion, scroll wheel [in tracks and in vertical rulers]) and
keystroke interactions that are not command shortcuts (ESC, and keystrokes
in label tracks) needed to be re-exercised.
..........
A lot of untangling of TrackPanel.cpp has been accomplished so that
dispatch of mouse and keystroke events are handled in a more object-oriented
way. Thousands of lines of code cut out of TrackPanel.cpp and pasted
into
many other, new, smaller source code files, under certain new virtual
function interfaces.
This project is important to the future of Audacity development. It does
not yet define a complete "plug-in" protocol that would allow separately
compiled added controls that could even be added in dynamically loaded
libraries. But it is an advancement toward that.
(My opinion about the ill-defined notion of "plug-ins" has long been that
before we think of adding new features, we must first figure out how to
subtract existing features, so that they, first, become optional plug-ins
that prove the concept. Hence, this effort toward decoupling the code
we
have.)
Still not yet done is to refactor the code that draws all details of
TrackPanel in a similar fashion. But that may prove a comparatively easy
thing and reasonable too as a goal for 2.2.0.
One question is whether certain other possible fruits of this project
should be pursued for 2.2.0. I am thinking of extending the
protocol
to
make it easier to code more mouse-over highlighting of interactive things in
the track panel, in a less ad-hoc fashion. One existing example of this is
the highlighting of the move and stretch handles of labels. I think it
would be nice to have more things like that -- like lighting up the TCP
buttons or the various hit targets in multi-tool. I think that could
be a
good addition to the "face-lift" that has been the main focus of 2.2.0
development.
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-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...