Paul Licameli
2017-06-15 13:37:50 UTC
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
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