Linux build broken

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Linux build broken

Stevethefiddle
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linux build broken

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

These compiler differences are annoying.

PRL


On Sun, Jul 9, 2017 at 1:42 PM, Steve the Fiddle <[hidden email]> wrote:
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


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

Re: Linux build broken

Paul Licameli
cd9d37f fixes it.

PRL


On Sun, Jul 9, 2017 at 2:11 PM, Paul Licameli <[hidden email]> wrote:
Yes, sorry, an intended Windows build fix is a Linux build breaker.

These compiler differences are annoying.

PRL


On Sun, Jul 9, 2017 at 1:42 PM, Steve the Fiddle <[hidden email]> wrote:
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



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

Re: Linux build broken

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




On 7/9/2017 7:25 PM, Paul Licameli wrote:
cd9d37f fixes it.

PRL


On Sun, Jul 9, 2017 at 2:11 PM, Paul Licameli [hidden email]
wrote:

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

These compiler differences are annoying.

PRL


On Sun, Jul 9, 2017 at 1:42 PM, Steve the Fiddle <[hidden email]
wrote:

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



      

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



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

Re: Linux build broken

Paul Licameli


On Sun, Jul 9, 2017 at 2:47 PM, James Crook <[hidden email]> wrote:
Still broken.

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

In which file?
 

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

 



     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.





On 7/9/2017 7:25 PM, Paul Licameli wrote:
cd9d37f fixes it.

PRL


On Sun, Jul 9, 2017 at 2:11 PM, Paul Licameli [hidden email]
wrote:

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

These compiler differences are annoying.

PRL


On Sun, Jul 9, 2017 at 1:42 PM, Steve the Fiddle <[hidden email]
wrote:

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


      

      

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



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



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

Re: Linux build broken

Henric Jungheim


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.

On Sun, Jul 09, 2017 at 07:56:11PM -0400, Paul Licameli wrote:

> On Sun, Jul 9, 2017 at 2:47 PM, James Crook <[hidden email]> wrote:
>
> > Still broken.
> >
> > Even after fixing
> > #include "TrackPanelDrawingContext.h"
> > to
> > #include "../TrackPanelDrawingContext.h"
> >
>
> In which file?
>
>
> >
> > 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
>
>
>
> >
> >
> >
> >      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.
> >
> >
> >
> >
> >
> > On 7/9/2017 7:25 PM, Paul Licameli wrote:
> >
> > cd9d37f fixes it.
> >
> > PRL
> >
> >
> > On Sun, Jul 9, 2017 at 2:11 PM, Paul Licameli <[hidden email]> <[hidden email]>
> > wrote:
> >
> >
> > Yes, sorry, an intended Windows build fix is a Linux build breaker.
> >
> > These compiler differences are annoying.
> >
> > PRL
> >
> >
> > On Sun, Jul 9, 2017 at 1:42 PM, Steve the Fiddle <[hidden email]
> >
> > wrote:
> >
> > 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 [hidden email]://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 [hidden email]://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
> >
> >
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
> >

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel


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

Re: Linux build broken

James Crook
In reply to this post by Paul Licameli
On 7/10/2017 12:56 AM, Paul Licameli wrote:
On Sun, Jul 9, 2017 at 2:47 PM, James Crook [hidden email] wrote:

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.



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





On 7/9/2017 7:25 PM, Paul Licameli wrote:

cd9d37f fixes it.

PRL


On Sun, Jul 9, 2017 at 2:11 PM, Paul Licameli [hidden email] [hidden email]
wrote:


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

These compiler differences are annoying.

PRL


On Sun, Jul 9, 2017 at 1:42 PM, Steve the Fiddle <[hidden email]

wrote:

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 [hidden email]



------------------------------------------------------------------------------
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 [hidden email]



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



      

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



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

Re: Linux build broken

Henric Jungheim
On Mon, Jul 10, 2017 at 08:53:29AM +0100, James Crook wrote:

> On 7/10/2017 12:56 AM, Paul Licameli wrote:
> > On Sun, Jul 9, 2017 at 2:47 PM, James Crook <[hidden email]> wrote:
> >
> >> 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.

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

>
>
> >
> > I have discovered that I can cause crashes if I hit the Undo shorcut key
> > during motion.
> >
> > PRL
> >
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel


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

Re: Linux build broken

Paul Licameli
In reply to this post by James Crook


On Mon, Jul 10, 2017 at 3:53 AM, James Crook <[hidden email]> wrote:
On 7/10/2017 12:56 AM, Paul Licameli wrote:
On Sun, Jul 9, 2017 at 2:47 PM, James Crook [hidden email] wrote:

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

 


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++
     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. On 7/9/2017 7:25 PM, Paul Licameli wrote: cd9d37f fixes it. PRL On Sun, Jul 9, 2017 at 2:11 PM, Paul Licameli [hidden email] [hidden email] wrote: Yes, sorry, an intended Windows build fix is a Linux build breaker. These compiler differences are annoying. PRL On Sun, Jul 9, 2017 at 1:42 PM, Steve the Fiddle <[hidden email] wrote: 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 [hidden email] ------------------------------------------------------------------------------ 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 [hidden email] ------------------------------------------------------------ ------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel

      

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



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



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

Build broken on MSVC2013.

James Crook
On 7/10/2017 4:48 PM, Paul Licameli wrote:

> On Mon, Jul 10, 2017 at 3:53 AM, James Crook <[hidden email]> wrote:
>
>> On 7/10/2017 12:56 AM, Paul Licameli wrote:
>>
>> On Sun, Jul 9, 2017 at 2:47 PM, James Crook <[hidden email]> <[hidden email]> wrote:
>>
>>
>> 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.


>
> PRL
>
>


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

Re: Build broken on MSVC2013.

Paul Licameli


On Mon, Jul 10, 2017 at 12:47 PM, James Crook <[hidden email]> wrote:
On 7/10/2017 4:48 PM, Paul Licameli wrote:
On Mon, Jul 10, 2017 at 3:53 AM, James Crook <[hidden email]> wrote:

On 7/10/2017 12:56 AM, Paul Licameli wrote:

On Sun, Jul 9, 2017 at 2:47 PM, James Crook <[hidden email]> <[hidden email]> wrote:


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 ?

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


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

Re: Build broken on MSVC2013.

James Crook
On 7/10/2017 5:56 PM, Paul Licameli wrote:
On Mon, Jul 10, 2017 at 12:47 PM, James Crook [hidden email] wrote:

On 7/10/2017 4:48 PM, Paul Licameli wrote:

On Mon, Jul 10, 2017 at 3:53 AM, James Crook [hidden email] wrote:

On 7/10/2017 12:56 AM, Paul Licameli wrote:
On Sun, Jul 9, 2017 at 2:47 PM, James Crook [hidden email] <
[hidden email]> wrote:


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


      

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



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

Re: Build broken on MSVC2013.

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

On 7/10/2017 6:00 PM, James Crook wrote:
On 7/10/2017 5:56 PM, Paul Licameli wrote:
On Mon, Jul 10, 2017 at 12:47 PM, James Crook [hidden email] wrote:

On 7/10/2017 4:48 PM, Paul Licameli wrote:

On Mon, Jul 10, 2017 at 3:53 AM, James Crook [hidden email] wrote:

On 7/10/2017 12:56 AM, Paul Licameli wrote:
On Sun, Jul 9, 2017 at 2:47 PM, James Crook [hidden email] <
[hidden email]> wrote:


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



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



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

Re: Build broken on MSVC2013.

Paul Licameli


On Tue, Jul 11, 2017 at 10:13 AM, James Crook <[hidden email]> wrote:
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
 


On 7/10/2017 6:00 PM, James Crook wrote:
On 7/10/2017 5:56 PM, Paul Licameli wrote:
On Mon, Jul 10, 2017 at 12:47 PM, James Crook [hidden email] wrote:

On 7/10/2017 4:48 PM, Paul Licameli wrote:

On Mon, Jul 10, 2017 at 3:53 AM, James Crook [hidden email] wrote:

On 7/10/2017 12:56 AM, Paul Licameli wrote:
On Sun, Jul 9, 2017 at 2:47 PM, James Crook [hidden email] <
[hidden email]> wrote:


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



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



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



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

Re: Build broken on MSVC2013.

Paul Licameli


On Tue, Jul 11, 2017 at 2:09 PM, Paul Licameli <[hidden email]> wrote:


On Tue, Jul 11, 2017 at 10:13 AM, James Crook <[hidden email]> wrote:
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,

Oops, make that f1d0d884aaf3acf07c74be18a6df9c172dcbb75e
PRL
 
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
 


On 7/10/2017 6:00 PM, James Crook wrote:
On 7/10/2017 5:56 PM, Paul Licameli wrote:
On Mon, Jul 10, 2017 at 12:47 PM, James Crook [hidden email] wrote:

On 7/10/2017 4:48 PM, Paul Licameli wrote:

On Mon, Jul 10, 2017 at 3:53 AM, James Crook [hidden email] wrote:

On 7/10/2017 12:56 AM, Paul Licameli wrote:
On Sun, Jul 9, 2017 at 2:47 PM, James Crook [hidden email] <
[hidden email]> wrote:


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



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



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




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

Re: Build broken on MSVC2013.

James Crook
In reply to this post by Paul Licameli
On 7/11/2017 7:09 PM, Paul Licameli wrote:

> On Tue, Jul 11, 2017 at 10:13 AM, James Crook <[hidden email]> wrote:
>
>> 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.


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


> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Build broken on MSVC2013.

Paul Licameli


On Tue, Jul 11, 2017 at 5:30 PM, James Crook <[hidden email]> wrote:
On 7/11/2017 7:09 PM, Paul Licameli wrote:
On Tue, Jul 11, 2017 at 10:13 AM, James Crook <[hidden email]> wrote:

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

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, it is enough.   The TCP highlighting draws attention to:
- 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


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

Re: Build broken on MSVC2013.

Gale
Administrator
In reply to this post by James Crook
On 11 July 2017 at 22:30, James Crook <[hidden email]> wrote:

> On 7/11/2017 7:09 PM, Paul Licameli wrote:
>>
>> On Tue, Jul 11, 2017 at 10:13 AM, James Crook <[hidden email]> wrote:
>>
>>> 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,
> 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.
>
>
>> 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>
>
>
>> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

Re: Build broken on MSVC2013.

David Bailes-3
On Wed, Jul 12, 2017 at 12:34 AM, Gale Andrews <[hidden email]> wrote:
On 11 July 2017 at 22:30, James Crook <[hidden email]> wrote:
> On 7/11/2017 7:09 PM, Paul Licameli wrote:
>>
>> On Tue, Jul 11, 2017 at 10:13 AM, James Crook <[hidden email]> wrote:
>>
>>> 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.

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. 

But no longer my concern now.

What do you mean by this?

David.
 


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

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


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

Re: Build broken on MSVC2013.

David Bailes-3
In reply to this post by James Crook
On Tue, Jul 11, 2017 at 10:30 PM, James Crook <[hidden email]> wrote:
On 7/11/2017 7:09 PM, Paul Licameli wrote:
On Tue, Jul 11, 2017 at 10:13 AM, James Crook <[hidden email]> wrote:

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.

It does look very inconsistent.

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


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>


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


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