[Audacity-devel] Linux build broken

Multiple commit revisions broken on Linux. See Travis results for details.

Steve

Paul Licameli

2017-07-09 18:11:08 UTC

Yes, sorry, an intended Windows build fix is a Linux build breaker.

These compiler differences are annoying.

PRL

Post by Steve the Fiddle
Multiple commit revisions broken on Linux. See Travis results for details.
Steve
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2017-07-09 18:25:26 UTC

cd9d37f fixes it.

PRL

Post by Paul Licameli
Yes, sorry, an intended Windows build fix is a Linux build breaker.
These compiler differences are annoying.
PRL

James Crook

2017-07-09 18:47:02 UTC

Still broken.

Even after fixing
#include "TrackPanelDrawingContext.h"
to
#include "../TrackPanelDrawingContext.h"

Which allows it to build, the build crashes when viewing a wavetrack and
hover over TCP. Problem with IncRef following a bad pointer,

From WaveTrackControls::HitTest
results.push_back(result);

Audacity.exe!std::_Ref_count_base::_Incref() Line 106 C++
Audacity.exe!std::_Ptr_base<UIHandle>::_Reset(UIHandle *
_Other_ptr, std::_Ref_count_base * _Other_rep) Line 404 C++
Audacity.exe!std::_Ptr_base<UIHandle>::_Reset<UIHandle>(const
std::_Ptr_base<UIHandle> & _Other) Line 355 C++
Audacity.exe!std::shared_ptr<UIHandle>::shared_ptr<UIHandle>(const
std::shared_ptr<UIHandle> & _Other) Line 526 C++
Audacity.exe!std::allocator<std::shared_ptr<UIHandle>

::construct(std::shared_ptr<UIHandle> * _Ptr, const

std::shared_ptr<UIHandle> & _Val) Line 593 C++
Audacity.exe!std::allocator_traits<std::allocator<std::shared_ptr<UIHandle>

::construct<std::shared_ptr<UIHandle>,std::shared_ptr<UIHandle>

const &>(std::allocator<std::shared_ptr<UIHandle> > & _Al,
std::shared_ptr<UIHandle> * _Ptr, const std::shared_ptr<UIHandle> &
<_Args_0>) Line 724 C++
Audacity.exe!std::_Wrap_alloc<std::allocator<std::shared_ptr<UIHandle> >

::construct<std::shared_ptr<UIHandle>,std::shared_ptr<UIHandle> const

&>(std::shared_ptr<UIHandle> * _Ptr, const std::shared_ptr<UIHandle> &
<_Args_0>) Line 872 C++
Audacity.exe!std::vector<std::shared_ptr<UIHandle>,std::allocator<std::shared_ptr<UIHandle>

::push_back(const std::shared_ptr<UIHandle> & _Val) Line 1261 C++

Audacity.exe!WaveTrackControls::HitTest(const TrackPanelMouseState

& st, const AudacityProject * pProject) Line 86 C++
Audacity.exe!TrackPanel::HandleMotion(const TrackPanelMouseState &
tpmState) Line 907 C++

--James.

cd9d37f fixes it.
PRL

Yes, sorry, an intended Windows build fix is a Linux build breaker.
These compiler differences are annoying.
PRL

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

Paul Licameli

2017-07-09 23:56:11 UTC

Post by James Crook
Still broken.
Even after fixing
#include "TrackPanelDrawingContext.h"
to
#include "../TrackPanelDrawingContext.h"

In which file?

Post by James Crook
Which allows it to build, the build crashes when viewing a wavetrack and
hover over TCP. Problem with IncRef following a bad pointer,
From WaveTrackControls::HitTest
results.push_back(result);

Did you do anything special?

I have discovered that I can cause crashes if I hit the Undo shorcut key
during motion.

PRL

Post by James Crook
Audacity.exe!std::_Ref_count_base::_Incref() Line 106 C++
Audacity.exe!std::_Ptr_base<UIHandle>::_Reset(UIHandle * _Other_ptr,
std::_Ref_count_base * _Other_rep) Line 404 C++
Audacity.exe!std::_Ptr_base<UIHandle>::_Reset<UIHandle>(const
std::_Ptr_base<UIHandle> & _Other) Line 355 C++
Audacity.exe!std::shared_ptr<UIHandle>::shared_ptr<UIHandle>(const
std::shared_ptr<UIHandle> & _Other) Line 526 C++
Audacity.exe!std::allocator<std::shared_ptr<UIHandle>

::construct(std::shared_ptr<UIHandle> * _Ptr, const

std::shared_ptr<UIHandle> & _Val) Line 593 C++
Audacity.exe!std::allocator_traits<std::allocator<std::shared_ptr<UIHandle>

::construct<std::shared_ptr<UIHandle>,std::shared_ptr<UIHandle> const

&>(std::allocator<std::shared_ptr<UIHandle> > & _Al,
std::shared_ptr<UIHandle> * _Ptr, const std::shared_ptr<UIHandle> &
<_Args_0>) Line 724 C++
Audacity.exe!std::_Wrap_alloc<std::allocator<std::shared_ptr<UIHandle>

::construct<std::shared_ptr<UIHandle>,std::shared_ptr<UIHandle> const

&>(std::shared_ptr<UIHandle> * _Ptr, const std::shared_ptr<UIHandle> &
<_Args_0>) Line 872 C++
allocator<std::shared_ptr<UIHandle> > >::push_back(const
std::shared_ptr<UIHandle> & _Val) Line 1261 C++

Audacity.exe!WaveTrackControls::HitTest(const TrackPanelMouseState &

st, const AudacityProject * pProject) Line 86 C++
Audacity.exe!TrackPanel::HandleMotion(const TrackPanelMouseState &
tpmState) Line 907 C++
--James.
cd9d37f fixes it.
PRL
Yes, sorry, an intended Windows build fix is a Linux build breaker.
These compiler differences are annoying.
PRL
Multiple commit revisions broken on Linux. See Travis results for details.
Steve
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------
------------------
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-07-10 02:49:01 UTC

https://ci.appveyor.com/project/henricj/audacity-n5suy/build/2.2.0-alpha-63

..\..\..\src\effects\Equalization.cpp(2874): fatal error
C1083: Cannot open include file:
'TrackPanelDrawingContext.h': No such file or directory
[C:\projects\audacity-n5suy\win\Projects\Audacity\Audacity.vcxproj]

I think the way the builds are run means that MSVC doesn't
include the src directory in the #include search path when
compiling files from sudirectories of src whereas the Xcode
and gcc builds do. One might consider adding "..\..\..\src"
to the <AdditionalIncludeDirectories> in
win\Projects\Audacity\Audacity.vcxproj. That way the
include search paths for Windows builds would be more like
the other platforms.

Post by James Crook
Still broken.
Even after fixing
#include "TrackPanelDrawingContext.h"
to
#include "../TrackPanelDrawingContext.h"

In which file?

Did you do anything special?
I have discovered that I can cause crashes if I hit the Undo shorcut key
during motion.
PRL

::construct(std::shared_ptr<UIHandle> * _Ptr, const

std::shared_ptr<UIHandle> & _Val) Line 593 C++
Audacity.exe!std::allocator_traits<std::allocator<std::shared_ptr<UIHandle>

::construct<std::shared_ptr<UIHandle>,std::shared_ptr<UIHandle> const

&>(std::shared_ptr<UIHandle> * _Ptr, const std::shared_ptr<UIHandle> &
<_Args_0>) Line 872 C++
allocator<std::shared_ptr<UIHandle> > >::push_back(const
std::shared_ptr<UIHandle> & _Val) Line 1261 C++

Audacity.exe!WaveTrackControls::HitTest(const TrackPanelMouseState &

James Crook

2017-07-10 07:53:29 UTC

Post by James Crook
Still broken.
Even after fixing
#include "TrackPanelDrawingContext.h"
to
#include "../TrackPanelDrawingContext.h"

In which file?

Equalization.cpp

Did you do anything special?

No.
Moving cursor from waveform to hover over the TCP was enough, and
immediate - not moonphasey at all. The cursor stayed in the 'vertical
scale magnify' state. Then the crash dump shown with a bad address of
CCCCCCCD or some such.

Post by Paul Licameli
I have discovered that I can cause crashes if I hit the Undo shorcut key
during motion.
PRL

::construct(std::shared_ptr<UIHandle> * _Ptr, const

std::shared_ptr<UIHandle> & _Val) Line 593 C++
Audacity.exe!std::allocator_traits<std::allocator<std::shared_ptr<UIHandle>

::construct<std::shared_ptr<UIHandle>,std::shared_ptr<UIHandle> const

&>(std::shared_ptr<UIHandle> * _Ptr, const std::shared_ptr<UIHandle> &
<_Args_0>) Line 872 C++
allocator<std::shared_ptr<UIHandle> > >::push_back(const
std::shared_ptr<UIHandle> & _Val) Line 1261 C++

Audacity.exe!WaveTrackControls::HitTest(const TrackPanelMouseState &

Henric Jungheim

2017-07-10 08:10:55 UTC

Post by James Crook
hover over TCP. Problem with IncRef following a bad pointer,
From WaveTrackControls::HitTest
results.push_back(result);

Did you do anything special?

All (or mostly all--0xcccccccc + 1 == 0xcccccccd) "CC"s
suggest unitialized stack on a debug build. "CD" or "DD"
would suggest uninitalized or freed heap, respectively.

https://msdn.microsoft.com/en-us/library/974tc9t1(v=vs.120).aspx
https://stackoverflow.com/a/370362
https://en.wikipedia.org/wiki/Magic_number_(programming)#Magic_debug_values

Post by Paul Licameli
I have discovered that I can cause crashes if I hit the Undo shorcut key
during motion.
PRL

_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2017-07-10 15:48:09 UTC

Post by James Crook
Still broken.
Even after fixing
#include "TrackPanelDrawingContext.h"
to
#include "../TrackPanelDrawingContext.h"
In which file?
Equalization.cpp
Which allows it to build, the build crashes when viewing a wavetrack and
hover over TCP. Problem with IncRef following a bad pointer,
From WaveTrackControls::HitTest
results.push_back(result);
Did you do anything special?
No.
Moving cursor from waveform to hover over the TCP was enough, and
immediate - not moonphasey at all. The cursor stayed in the 'vertical
scale magnify' state. Then the crash dump shown with a bad address of
CCCCCCCD or some such.

Try it again at 16645f6

PRL

Post by James Crook
I have discovered that I can cause crashes if I hit the Undo shorcut key
during motion.
PRL
Audacity.exe!std::_Ref_count_base::_Incref() Line 106 C++
Audacity.exe!std::_Ptr_base<UIHandle>::_Reset(UIHandle * _Other_ptr,
std::_Ref_count_base * _Other_rep) Line 404 C++
Audacity.exe!std::_Ptr_base<UIHandle>::_Reset<UIHandle>(const
std::_Ptr_base<UIHandle> & _Other) Line 355 C++
Audacity.exe!std::shared_ptr<UIHandle>::shared_ptr<UIHandle>(const
std::shared_ptr<UIHandle> & _Other) Line 526 C++
Audacity.exe!std::allocator<std::shared_ptr<UIHandle>
::construct(std::shared_ptr<UIHandle> * _Ptr, const
std::shared_ptr<UIHandle> & _Val) Line 593 C++
Audacity.exe!std::allocator_traits<std::allocator<std::shared_ptr<UIHandle>
::construct<std::shared_ptr<UIHandle>,std::shared_ptr<UIHandle> const
&>(std::allocator<std::shared_ptr<UIHandle> > & _Al,
std::shared_ptr<UIHandle> * _Ptr, const std::shared_ptr<UIHandle> &
<_Args_0>) Line 724 C++
Audacity.exe!std::_Wrap_alloc<std::allocator<std::shared_ptr<UIHandle>
::construct<std::shared_ptr<UIHandle>,std::shared_ptr<UIHandle> const
&>(std::shared_ptr<UIHandle> * _Ptr, const std::shared_ptr<UIHandle> &
<_Args_0>) Line 872 C++
allocator<std::shared_ptr<UIHandle> > >::push_back(const
std::shared_ptr<UIHandle> & _Val) Line 1261 C++
Audacity.exe!WaveTrackControls::HitTest(const TrackPanelMouseState &
st, const AudacityProject * pProject) Line 86 C++
HandleMotion(const TrackPanelMouseState &
tpmState) Line 907 C++
--James.
cd9d37f fixes it.
PRL
Yes, sorry, an intended Windows build fix is a Linux build breaker.
These compiler differences are annoying.
PRL
Multiple commit revisions broken on Linux. See Travis results for details.
Steve
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2017-07-10 16:47:49 UTC

Try it again at 16645f6

Builds OK, but exactly the same crash problem as before.
Entry to the TCP triggers it. It does not matter what part of TCP I am
over, it seems.

--James.

Post by Paul Licameli
PRL

Paul Licameli

2017-07-10 16:56:16 UTC

Builds OK, but exactly the same crash problem as before.
Entry to the TCP triggers it. It does not matter what part of TCP I am
over, it seems.
--James.

Try bca09f4 ?

PRL

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

James Crook

2017-07-10 17:00:23 UTC

Builds OK, but exactly the same crash problem as before.
Entry to the TCP triggers it. It does not matter what part of TCP I am
over, it seems.
--James.

Try bca09f4 ?

Same problem.

Post by Paul Licameli
PRL

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

James Crook

2017-07-11 14:13:51 UTC

Tried with
https://github.com/audacity/audacity/commit/71a75fc28dc9f07a5fda90028f4ffa4b31e770b1

and that is working fine, not crashing, with hover-over-TCP. Like the
new highlighting TCP feature which I can see now. Thanks for fixing, Paul.

--James.

Post by James Crook
Still broken.
Even after fixing
#include "TrackPanelDrawingContext.h"
to
#include "../TrackPanelDrawingContext.h"
In which file?
Equalization.cpp
Which allows it to build, the build crashes when viewing a
wavetrack and
hover over TCP. Problem with IncRef following a bad pointer,
From WaveTrackControls::HitTest
results.push_back(result);
Did you do anything special?
No.
Moving cursor from waveform to hover over the TCP was enough, and
immediate - not moonphasey at all. The cursor stayed in the 'vertical
scale magnify' state. Then the crash dump shown with a bad address of
CCCCCCCD or some such.
Try it again at 16645f6

Builds OK, but exactly the same crash problem as before.
Entry to the TCP triggers it. It does not matter what part of TCP I am
over, it seems.
--James.

Try bca09f4 ?

Same problem.

Post by Paul Licameli
PRL

PRL

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

Paul Licameli

2017-07-11 18:09:14 UTC

Tried with https://github.com/audacity/audacity/commit/
71a75fc28dc9f07a5fda90028f4ffa4b31e770b1
and that is working fine, not crashing, with hover-over-TCP. Like the new
highlighting TCP feature which I can see now. Thanks for fixing, Paul.
--James.

I am glad you like it. I leave you to judge whether it is harmonious with
your theming and should be in the release.

I remind you that at commit 2180397624269122650f07b633079c65def06fa5 in my
branch highlight-sliders, I defined highlighted thumbs for the other themes
than Classic, but you didn't like the color choices.

Also that the highlighted button background as it is now in Classic is
probably wrong -- it draws an oval such as for Dark theme.

Finally, I have just pushed another offering, guarded by a disabled
EXPERIMENTAL flag, at cfb67e2f18ffaf27e5821ce0ba7d37d42b954ea9, which I do
not insist on for 2.2.0, but it preserves some of my work. You can see the
history of individual commits before that. It highlights several other
things inside the TrackPanel.

The main thing is that the decision whether to highlight or not is now
communicated to the drawing code in the way I like and don't consider hacky
(such as the one previously existing highlight, that of the label drag and
stretch handles, used to be hacky -- adding special state to the Track
object for that purpose). You can take my examples and change the drawing
details if you wish in 2.2.1, defining pens and brushes for those purposes
as part of the themes.

PRL

Still broken.
Even after fixing
#include "TrackPanelDrawingContext.h"
to
#include "../TrackPanelDrawingContext.h"
In which file?
Equalization.cpp
Which allows it to build, the build crashes when viewing a wavetrack and
hover over TCP. Problem with IncRef following a bad pointer,
From WaveTrackControls::HitTest
results.push_back(result);
Did you do anything special?
No.
Moving cursor from waveform to hover over the TCP was enough, and
immediate - not moonphasey at all. The cursor stayed in the 'vertical
scale magnify' state. Then the crash dump shown with a bad address of
CCCCCCCD or some such.
Try it again at 16645f6
Builds OK, but exactly the same crash problem as before.
Entry to the TCP triggers it. It does not matter what part of TCP I am
over, it seems.
--James.
Try bca09f4 ?
Same problem.
PRL
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
_______________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2017-07-11 18:19:04 UTC

Tried with https://github.com/audacity/audacity/commit/71a75fc28dc9f07a
5fda90028f4ffa4b31e770b1
and that is working fine, not crashing, with hover-over-TCP. Like the
new highlighting TCP feature which I can see now. Thanks for fixing, Paul.
--James.

Oops, make that f1d0d884aaf3acf07c74be18a6df9c172dcbb75e
PRL

Post by Paul Licameli
which I do not insist on for 2.2.0, but it preserves some of my work. You
can see the history of individual commits before that. It highlights
several other things inside the TrackPanel.
The main thing is that the decision whether to highlight or not is now
communicated to the drawing code in the way I like and don't consider hacky
(such as the one previously existing highlight, that of the label drag and
stretch handles, used to be hacky -- adding special state to the Track
object for that purpose). You can take my examples and change the drawing
details if you wish in 2.2.1, defining pens and brushes for those purposes
as part of the themes.
PRL

James Crook

2017-07-11 21:30:36 UTC

Tried with https://github.com/audacity/audacity/commit/
71a75fc28dc9f07a5fda90028f4ffa4b31e770b1
and that is working fine, not crashing, with hover-over-TCP. Like the new
highlighting TCP feature which I can see now. Thanks for fixing, Paul.
--James.

I am glad you like it. I leave you to judge whether it is harmonious with
your theming and should be in the release.

It's not really harmonious, in classic, in fact in both classic and
light the highlight makes the button darker, when it should be
lighter. The feature of having highlighting is good, so I'd vote to
have it in 2.2.0, even if we don't modify the classic/light theme to
improve the highlights. (and we might anyway find we do have time to
modify the highlights).

The problem with theme is there is so much to review and tweak to get it
better and consistent. So I think as long as we are taking steps
forward, it is enough. The TCP highlighting draws attention to:
- Arguably we need down-highlighting as well as up-highlighting.
- No highlighting of 'Click to start monitoring'.
- No highlighting of a label when you hover over.
- Button highlights in classic are very subtle and could do with being
more 'in your face'.
- The slider-thumb images are small. Larger ones would allow the thumb
to grow on hover, which could be a better effect than them appearing to
fade a little on hover.

I don't think we HAVE to 'fix' any of these for 2.2.0.

Post by Paul Licameli
I remind you that at commit 2180397624269122650f07b633079c65def06fa5 in my
branch highlight-sliders, I defined highlighted thumbs for the other themes
than Classic, but you didn't like the color choices.

As currently designed they just seem to fade away, rather then becoming
more visible.

Post by Paul Licameli
Also that the highlighted button background as it is now in Classic is
probably wrong -- it draws an oval such as for Dark theme.

+1. I guess if it were a P2 we would either have to 'fix' it or
postpone the highlighting to 2.2.1.

Post by Paul Licameli
Finally, I have just pushed another offering, guarded by a disabled
EXPERIMENTAL flag, at cfb67e2f18ffaf27e5821ce0ba7d37d42b954ea9, which I do
not insist on for 2.2.0, but it preserves some of my work. You can see the
history of individual commits before that. It highlights several other
things inside the TrackPanel.

<opinion> I think there is too much work on those additional changes
still to do for them to go live in 2.2.0.
The envelope hover highlights the central section, and it probably
should only highlight the boundary between central and outer section, as
it is that which can be dragged. The drag points don't highlight
individually. The VRuler is highlighted by outline, but I think it is
button like and should change background too. The label and label line
highlight on hover, and probably it should just be the label as only the
text is editable.</opinion>

Post by Paul Licameli
The main thing is that the decision whether to highlight or not is now
communicated to the drawing code in the way I like and don't consider hacky
(such as the one previously existing highlight, that of the label drag and
stretch handles, used to be hacky -- adding special state to the Track
object for that purpose). You can take my examples and change the drawing
details if you wish in 2.2.1, defining pens and brushes for those purposes
as part of the themes.
PRL

Paul Licameli

2017-07-11 23:07:04 UTC

Tried with https://github.com/audacity/audacity/commit/

Post by James Crook
71a75fc28dc9f07a5fda90028f4ffa4b31e770b1
and that is working fine, not crashing, with hover-over-TCP. Like the new
highlighting TCP feature which I can see now. Thanks for fixing, Paul.
--James.
I am glad you like it. I leave you to judge whether it is harmonious

with
your theming and should be in the release.

See below, as you have seen: we know the highlighted button background is
wrong in Classic

But that just comes down to fixing images for button backgrounds and slider
thumbs, which is a low-risk thing that could be done even after a
kick-the-tires build.

So I think we (two, at least) are agreed to leave the button and slider
higlighting in.

The problem with theme is there is so much to review and tweak to get it
better and consistent. So I think as long as we are taking steps forward,
- Arguably we need down-highlighting as well as up-highlighting.

A bit more work, that, to define another theme resource.

Except MIDI channel button highlights. In present head, there is in fact a
highlight whether the button is up or down. Though up-highlight may not
contrast with down-highlight, still highlight contrasts well with either up
or down, un-highlighted.

- No highlighting of 'Click to start monitoring'.
- No highlighting of a label when you hover over.

If you mean highlighting of the text boxes, then that is accomplished in my
EXPERIMENTAL branch, though with the intentionally "ugly" colors.

- Button highlights in classic are very subtle and could do with being
more 'in your face'.

You mean the other buttons, in toolbars? Those are too subtle while the
TCP highlights are too bold?

- The slider-thumb images are small. Larger ones would allow the thumb to
grow on hover, which could be a better effect than them appearing to fade a
little on hover.

Again, just images.

I don't think we HAVE to 'fix' any of these for 2.2.0.
I remind you that at commit 2180397624269122650f07b633079c65def06fa5 in my

branch highlight-sliders, I defined highlighted thumbs for the other themes
than Classic, but you didn't like the color choices.

As currently designed they just seem to fade away, rather then becoming
more visible.
Also that the highlighted button background as it is now in Classic is

probably wrong -- it draws an oval such as for Dark theme.

+1. I guess if it were a P2 we would either have to 'fix' it or postpone
the highlighting to 2.2.1.
Finally, I have just pushed another offering, guarded by a disabled

EXPERIMENTAL flag, at cfb67e2f18ffaf27e5821ce0ba7d37d42b954ea9, which I do
not insist on for 2.2.0, but it preserves some of my work. You can see the
history of individual commits before that. It highlights several other
things inside the TrackPanel.

<opinion> I think there is too much work on those additional changes still
to do for them to go live in 2.2.0.
The envelope hover highlights the central section, and it probably should
only highlight the boundary between central and outer section, as it is
that which can be dragged. The drag points don't highlight individually.
The VRuler is highlighted by outline, but I think it is button like and
should change background too. The label and label line highlight on hover,
and probably it should just be the label as only the text is
editable.</opinion>

In few, I think you are saying, do none of that addtional highlighting,
beyond buttons and sliders, for 2.2.0, and I don't object. But I lay
groundwork for some motivated person to prepare tweaks the details of
drawing in the lull between versions.

PRL

The main thing is that the decision whether to highlight or not is now

communicated to the drawing code in the way I like and don't consider hacky
(such as the one previously existing highlight, that of the label drag and
stretch handles, used to be hacky -- adding special state to the Track
object for that purpose). You can take my examples and change the drawing
details if you wish in 2.2.1, defining pens and brushes for those purposes
as part of the themes.
PRL

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

Gale Andrews

2017-07-11 23:34:12 UTC

Tried with https://github.com/audacity/audacity/commit/
71a75fc28dc9f07a5fda90028f4ffa4b31e770b1
and that is working fine, not crashing, with hover-over-TCP. Like the new
highlighting TCP feature which I can see now. Thanks for fixing, Paul.
--James.

I am glad you like it. I leave you to judge whether it is harmonious with
your theming and should be in the release.

It's not really harmonious, in classic, in fact in both classic and light
the highlight makes the button darker, when it should be lighter.

I would go farther that the "dark highlighting" is unreadable and unacceptable.

But no longer my concern now.

Gale

The feature of having highlighting is good, so I'd vote to have it in 2.2.0,
even if we don't modify the classic/light theme to improve the highlights.
(and we might anyway find we do have time to modify the highlights).
The problem with theme is there is so much to review and tweak to get it
better and consistent. So I think as long as we are taking steps forward,
- Arguably we need down-highlighting as well as up-highlighting.
- No highlighting of 'Click to start monitoring'.
- No highlighting of a label when you hover over.
- Button highlights in classic are very subtle and could do with being more
'in your face'.
- The slider-thumb images are small. Larger ones would allow the thumb to
grow on hover, which could be a better effect than them appearing to fade a
little on hover.
I don't think we HAVE to 'fix' any of these for 2.2.0.

As currently designed they just seem to fade away, rather then becoming more
visible.

Post by Paul Licameli
Also that the highlighted button background as it is now in Classic is
probably wrong -- it draws an oval such as for Dark theme.

+1. I guess if it were a P2 we would either have to 'fix' it or postpone
the highlighting to 2.2.1.

<opinion> I think there is too much work on those additional changes still
to do for them to go live in 2.2.0.
The envelope hover highlights the central section, and it probably should
only highlight the boundary between central and outer section, as it is that
which can be dragged. The drag points don't highlight individually. The
VRuler is highlighted by outline, but I think it is button like and should
change background too. The label and label line highlight on hover, and
probably it should just be the label as only the text is editable.</opinion>

David Bailes

2017-07-12 08:25:55 UTC

Post by Gale Andrews

Tried with https://github.com/audacity/audacity/commit/
71a75fc28dc9f07a5fda90028f4ffa4b31e770b1
and that is working fine, not crashing, with hover-over-TCP. Like the new
highlighting TCP feature which I can see now. Thanks for fixing, Paul.
--James.

I am glad you like it. I leave you to judge whether it is harmonious

with

Post by Paul Licameli
your theming and should be in the release.

It's not really harmonious, in classic, in fact in both classic and light
the highlight makes the button darker, when it should be lighter.

I would go farther that the "dark highlighting" is unreadable and unacceptable.

Yes, using the classic theme, the text on the buttons on the TCP is
unreadable. In addition, on both the classic and light themes, the
highlighting looks more like pressing a button, than highlighting.

Post by Gale Andrews
But no longer my concern now.

What do you mean by this?

David.

Post by Gale Andrews
Gale

The feature of having highlighting is good, so I'd vote to have it in

2.2.0,

even if we don't modify the classic/light theme to improve the

highlights.

(and we might anyway find we do have time to modify the highlights).
The problem with theme is there is so much to review and tweak to get it
better and consistent. So I think as long as we are taking steps

forward,

- Arguably we need down-highlighting as well as up-highlighting.
- No highlighting of 'Click to start monitoring'.
- No highlighting of a label when you hover over.
- Button highlights in classic are very subtle and could do with being

'in your face'.
- The slider-thumb images are small. Larger ones would allow the thumb

grow on hover, which could be a better effect than them appearing to

fade a

little on hover.
I don't think we HAVE to 'fix' any of these for 2.2.0.

Post by Paul Licameli
I remind you that at commit 2180397624269122650f07b633079c65def06fa5

in my

Post by Paul Licameli
branch highlight-sliders, I defined highlighted thumbs for the other themes
than Classic, but you didn't like the color choices.

As currently designed they just seem to fade away, rather then becoming

visible.

Post by Paul Licameli
Also that the highlighted button background as it is now in Classic is
probably wrong -- it draws an oval such as for Dark theme.

+1. I guess if it were a P2 we would either have to 'fix' it or postpone
the highlighting to 2.2.1.

Post by Paul Licameli
Finally, I have just pushed another offering, guarded by a disabled
EXPERIMENTAL flag, at cfb67e2f18ffaf27e5821ce0ba7d37d42b954ea9, which

I do

Post by Paul Licameli
not insist on for 2.2.0, but it preserves some of my work. You can see the
history of individual commits before that. It highlights several other
things inside the TrackPanel.

<opinion> I think there is too much work on those additional changes

still

to do for them to go live in 2.2.0.
The envelope hover highlights the central section, and it probably should
only highlight the boundary between central and outer section, as it is

that

which can be dragged. The drag points don't highlight individually. The
VRuler is highlighted by outline, but I think it is button like and

should

change background too. The label and label line highlight on hover, and
probably it should just be the label as only the text is

editable.</opinion>

and

Post by Paul Licameli
stretch handles, used to be hacky -- adding special state to the Track
object for that purpose). You can take my examples and change the

drawing

Post by Paul Licameli
details if you wish in 2.2.1, defining pens and brushes for those

purposes

Post by Paul Licameli
as part of the themes.
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

David Bailes

2017-07-12 08:27:19 UTC