Reconciling Dark Audacity and MIDI play changes to TCP layout

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Reconciling Dark Audacity and MIDI play changes to TCP layout

Paul Licameli
See commit ca62891

I think the changes James and Pokechu22 made were slightly at cross purposes. James made buttons in the Track Control Panels (TCP) slightly taller which caused the MIDI channel controls to be slightly overlapped.  I have moved them and the Velocity slider down a little.

Also the status text in WaveTracks was overlapped at top by one pixel.  I have moved the text down three pixels, leaving all else unmoved.

Also (an old problem), sliders and buttons that are hidden when you lessen the track height still remained responsive to mouse clicks!  That is fixed.

Also I rewrote much code in what I think is a better way that eliminates several "magic numbers" and puts more layout details into a declarative, tabular form rather than procedural.

PRL


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

Re: Reconciling Dark Audacity and MIDI play changes to TCP layout

James Crook
Looks a bit tidier.

I think the long term goal (not for 2.2.0) should be to go for a sizer
like mechanism, so we avoid all these per-button functions for different
positions.  It is hardly worth it for the TCP alone, but if the tracks
and toolbars also are in a sizer then it starts to be worthwhile.  Of
course we'd need functionality that does not yet exist in sizers to
support everything the TCP, Track Panel and docks do with sizing and
positioning.  I'd say our own sizer (re)implementation, rather than
extending the one in wxWidgets. Something to think about for the future.

--James.


On 6/6/2017 2:57 AM, Paul Licameli wrote:

> See commit ca62891
>
> I think the changes James and Pokechu22 made were slightly at cross
> purposes. James made buttons in the Track Control Panels (TCP) slightly
> taller which caused the MIDI channel controls to be slightly overlapped.  I
> have moved them and the Velocity slider down a little.
>
> Also the status text in WaveTracks was overlapped at top by one pixel.  I
> have moved the text down three pixels, leaving all else unmoved.
>
> Also (an old problem), sliders and buttons that are hidden when you lessen
> the track height still remained responsive to mouse clicks!  That is fixed.
>
> Also I rewrote much code in what I think is a better way that eliminates
> several "magic numbers" and puts more layout details into a declarative,
> tabular form rather than procedural.
>
> PRL
>


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

Re: Reconciling Dark Audacity and MIDI play changes to TCP layout

Paul Licameli
I should mention what I did here will change the screen shots of Wave tracks that include the controls, and this has implications for manual update.

Does this make much more work for documentation?

But I think the placement of the wave track status text, before my changes, was rather obviously unacceptable.  Did nobody else raise this issue?

As for reinventing sizers, this is beyond the scope of what I mean for 2.2.0.  Really this recent thing is another small obstacle to the real track panel refactor which is still pending.  An obstacle I needed to take on.

PRL


On Tue, Jun 6, 2017 at 3:37 AM, James Crook <[hidden email]> wrote:
Looks a bit tidier.

I think the long term goal (not for 2.2.0) should be to go for a sizer like mechanism, so we avoid all these per-button functions for different positions.  It is hardly worth it for the TCP alone, but if the tracks and toolbars also are in a sizer then it starts to be worthwhile.  Of course we'd need functionality that does not yet exist in sizers to support everything the TCP, Track Panel and docks do with sizing and positioning.  I'd say our own sizer (re)implementation, rather than extending the one in wxWidgets. Something to think about for the future.

--James.



On 6/6/2017 2:57 AM, Paul Licameli wrote:
See commit ca62891

I think the changes James and Pokechu22 made were slightly at cross
purposes. James made buttons in the Track Control Panels (TCP) slightly
taller which caused the MIDI channel controls to be slightly overlapped.  I
have moved them and the Velocity slider down a little.

Also the status text in WaveTracks was overlapped at top by one pixel.  I
have moved the text down three pixels, leaving all else unmoved.

Also (an old problem), sliders and buttons that are hidden when you lessen
the track height still remained responsive to mouse clicks!  That is fixed.

Also I rewrote much code in what I think is a better way that eliminates
several "magic numbers" and puts more layout details into a declarative,
tabular form rather than procedural.

PRL



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


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

Re: Reconciling Dark Audacity and MIDI play changes to TCP layout

Peter Sampson-2


On Tue, Jun 6, 2017 at 3:10 PM, Paul Licameli <[hidden email]> wrote:
I should mention what I did here will change the screen shots of Wave tracks that include the controls, and this has implications for manual update.

Does this make much more work for documentation?

It would/could do - but I can't see any visual differences comparing W10 audacity-win-r63c89e1-2.2.0-alpha-06-jun-17
and images of audio tracks in the alpha Manual :-??

Peter.
 

But I think the placement of the wave track status text, before my changes, was rather obviously unacceptable.  Did nobody else raise this issue?

As for reinventing sizers, this is beyond the scope of what I mean for 2.2.0.  Really this recent thing is another small obstacle to the real track panel refactor which is still pending.  An obstacle I needed to take on.

PRL


On Tue, Jun 6, 2017 at 3:37 AM, James Crook <[hidden email]> wrote:
Looks a bit tidier.

I think the long term goal (not for 2.2.0) should be to go for a sizer like mechanism, so we avoid all these per-button functions for different positions.  It is hardly worth it for the TCP alone, but if the tracks and toolbars also are in a sizer then it starts to be worthwhile.  Of course we'd need functionality that does not yet exist in sizers to support everything the TCP, Track Panel and docks do with sizing and positioning.  I'd say our own sizer (re)implementation, rather than extending the one in wxWidgets. Something to think about for the future.

--James.



On 6/6/2017 2:57 AM, Paul Licameli wrote:
See commit ca62891

I think the changes James and Pokechu22 made were slightly at cross
purposes. James made buttons in the Track Control Panels (TCP) slightly
taller which caused the MIDI channel controls to be slightly overlapped.  I
have moved them and the Velocity slider down a little.

Also the status text in WaveTracks was overlapped at top by one pixel.  I
have moved the text down three pixels, leaving all else unmoved.

Also (an old problem), sliders and buttons that are hidden when you lessen
the track height still remained responsive to mouse clicks!  That is fixed.

Also I rewrote much code in what I think is a better way that eliminates
several "magic numbers" and puts more layout details into a declarative,
tabular form rather than procedural.

PRL



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


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



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

Re: Reconciling Dark Audacity and MIDI play changes to TCP layout

Paul Licameli


On Tue, Jun 6, 2017 at 11:52 AM, Peter Sampson <[hidden email]> wrote:


On Tue, Jun 6, 2017 at 3:10 PM, Paul Licameli <[hidden email]> wrote:
I should mention what I did here will change the screen shots of Wave tracks that include the controls, and this has implications for manual update.

Does this make much more work for documentation?

It would/could do - but I can't see any visual differences comparing W10 audacity-win-r63c89e1-2.2.0-alpha-06-jun-17
and images of audio tracks in the alpha Manual :-??

Peter.

This few-pixel difference was significant for me on a MacBook.  I didn't check it on my Windows.  But I have reasons to suspect wxWidgets for Mac and Windows treat text slightly differently.  That is what the experience of last summer's scrubbing interface taught me.  Remember how text on buttons that looked good on Mac was drawn illegibly small on Windows?

On MacBook I had been seeing the  menu button overlap the top of the text by one pixel and now I do not.

PRL

 
 

But I think the placement of the wave track status text, before my changes, was rather obviously unacceptable.  Did nobody else raise this issue?

As for reinventing sizers, this is beyond the scope of what I mean for 2.2.0.  Really this recent thing is another small obstacle to the real track panel refactor which is still pending.  An obstacle I needed to take on.

PRL


On Tue, Jun 6, 2017 at 3:37 AM, James Crook <[hidden email]> wrote:
Looks a bit tidier.

I think the long term goal (not for 2.2.0) should be to go for a sizer like mechanism, so we avoid all these per-button functions for different positions.  It is hardly worth it for the TCP alone, but if the tracks and toolbars also are in a sizer then it starts to be worthwhile.  Of course we'd need functionality that does not yet exist in sizers to support everything the TCP, Track Panel and docks do with sizing and positioning.  I'd say our own sizer (re)implementation, rather than extending the one in wxWidgets. Something to think about for the future.

--James.



On 6/6/2017 2:57 AM, Paul Licameli wrote:
See commit ca62891

I think the changes James and Pokechu22 made were slightly at cross
purposes. James made buttons in the Track Control Panels (TCP) slightly
taller which caused the MIDI channel controls to be slightly overlapped.  I
have moved them and the Velocity slider down a little.

Also the status text in WaveTracks was overlapped at top by one pixel.  I
have moved the text down three pixels, leaving all else unmoved.

Also (an old problem), sliders and buttons that are hidden when you lessen
the track height still remained responsive to mouse clicks!  That is fixed.

Also I rewrote much code in what I think is a better way that eliminates
several "magic numbers" and puts more layout details into a declarative,
tabular form rather than procedural.

PRL



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


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



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



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

Re: Reconciling Dark Audacity and MIDI play changes to TCP layout

Gale
Administrator
Thanks Paul. A problem I have on Windows 1280x1024 that
I think is P1, is that the default height of mono tracks now does
not show the Pan slider.  I trust this is not intentional.

And likewise (but not P1 on its own) default height of Note Tracks
now does not show the velocity slider.

And yes, the bottom line of info text is now almost flush with the
top of the Mute/Solo buttons, instead of equidistant between
menu button and Mute/Solo as before. I could live with it.

Many thanks for preventing hidden sliders being clicked on.



Gale


On 6 June 2017 at 17:20, Paul Licameli <[hidden email]> wrote:

>
>
> On Tue, Jun 6, 2017 at 11:52 AM, Peter Sampson
> <[hidden email]> wrote:
>>
>>
>>
>> On Tue, Jun 6, 2017 at 3:10 PM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>> I should mention what I did here will change the screen shots of Wave
>>> tracks that include the controls, and this has implications for manual
>>> update.
>>>
>>> Does this make much more work for documentation?
>>
>>
>> It would/could do - but I can't see any visual differences comparing W10
>> audacity-win-r63c89e1-2.2.0-alpha-06-jun-17
>> and images of audio tracks in the alpha Manual :-??
>>
>> Peter.
>
>
> This few-pixel difference was significant for me on a MacBook.  I didn't
> check it on my Windows.  But I have reasons to suspect wxWidgets for Mac and
> Windows treat text slightly differently.  That is what the experience of
> last summer's scrubbing interface taught me.  Remember how text on buttons
> that looked good on Mac was drawn illegibly small on Windows?
>
> On MacBook I had been seeing the  menu button overlap the top of the text by
> one pixel and now I do not.
>
> PRL
>
>
>>
>>
>>>
>>>
>>> But I think the placement of the wave track status text, before my
>>> changes, was rather obviously unacceptable.  Did nobody else raise this
>>> issue?
>>>
>>> As for reinventing sizers, this is beyond the scope of what I mean for
>>> 2.2.0.  Really this recent thing is another small obstacle to the real track
>>> panel refactor which is still pending.  An obstacle I needed to take on.
>>>
>>> PRL
>>>
>>>
>>> On Tue, Jun 6, 2017 at 3:37 AM, James Crook <[hidden email]> wrote:
>>>>
>>>> Looks a bit tidier.
>>>>
>>>> I think the long term goal (not for 2.2.0) should be to go for a sizer
>>>> like mechanism, so we avoid all these per-button functions for different
>>>> positions.  It is hardly worth it for the TCP alone, but if the tracks and
>>>> toolbars also are in a sizer then it starts to be worthwhile.  Of course
>>>> we'd need functionality that does not yet exist in sizers to support
>>>> everything the TCP, Track Panel and docks do with sizing and positioning.
>>>> I'd say our own sizer (re)implementation, rather than extending the one in
>>>> wxWidgets. Something to think about for the future.
>>>>
>>>> --James.
>>>>
>>>>
>>>>
>>>> On 6/6/2017 2:57 AM, Paul Licameli wrote:
>>>>>
>>>>> See commit ca62891
>>>>>
>>>>> I think the changes James and Pokechu22 made were slightly at cross
>>>>> purposes. James made buttons in the Track Control Panels (TCP) slightly
>>>>> taller which caused the MIDI channel controls to be slightly
>>>>> overlapped.  I
>>>>> have moved them and the Velocity slider down a little.
>>>>>
>>>>> Also the status text in WaveTracks was overlapped at top by one pixel.
>>>>> I
>>>>> have moved the text down three pixels, leaving all else unmoved.
>>>>>
>>>>> Also (an old problem), sliders and buttons that are hidden when you
>>>>> lessen
>>>>> the track height still remained responsive to mouse clicks!  That is
>>>>> fixed.
>>>>>
>>>>> Also I rewrote much code in what I think is a better way that
>>>>> eliminates
>>>>> several "magic numbers" and puts more layout details into a
>>>>> declarative,
>>>>> tabular form rather than procedural.
>>>>>
>>>>> PRL
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

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

Re: Reconciling Dark Audacity and MIDI play changes to TCP layout

James Crook
In reply to this post by Paul Licameli
On 6/6/2017 3:10 PM, Paul Licameli wrote:
> I should mention what I did here will change the screen shots of Wave
> tracks that include the controls, and this has implications for manual
> update.
>
> Does this make much more work for documentation?
My (personal) view is that manual does not have to update all the
screenshots for a small positional change.  The point of  manual is to
explain, and already on Linux/Mac images will be very slightly different.

More significant is the decision on whether to release 2.2.0 with
Classic theme as the default or Light as the default.  That is a
decision for RM.  Even then, manual team might decide not to update the
annotated toolbar images in the manual, just Bill's hyperlinked image on
the front page.


> But I think the placement of the wave track status text, before my changes,
> was rather obviously unacceptable.  Did nobody else raise this issue?
On windows I think the positioning of the status message was better
previously.  On windows it now needs a little more space below the text
for it to look right.


> As for reinventing sizers, this is beyond the scope of what I mean for
> 2.2.0.  Really this recent thing is another small obstacle to the real
> track panel refactor which is still pending.  An obstacle I needed to take
> on.
Yes.  That's what I said too.  Our own sizers are to think about as a
long term goal for the future, not for 2.2.0.  I have actually
implemented simple box sizers for controls that aren't hWnd based (in
AU14), with something very like ShuttleGUI for using them.  Main benefit
(relative to wxWidgets sizers) was no flicker on resizing/dragging.

--James.


>
> PRL
>
>
> On Tue, Jun 6, 2017 at 3:37 AM, James Crook <[hidden email]> wrote:
>
>> Looks a bit tidier.
>>
>> I think the long term goal (not for 2.2.0) should be to go for a sizer
>> like mechanism, so we avoid all these per-button functions for different
>> positions.  It is hardly worth it for the TCP alone, but if the tracks and
>> toolbars also are in a sizer then it starts to be worthwhile.  Of course
>> we'd need functionality that does not yet exist in sizers to support
>> everything the TCP, Track Panel and docks do with sizing and positioning.
>> I'd say our own sizer (re)implementation, rather than extending the one in
>> wxWidgets. Something to think about for the future.
>>
>> --James.
>>
>>
>>
>> On 6/6/2017 2:57 AM, Paul Licameli wrote:
>>
>>> See commit ca62891
>>>
>>> I think the changes James and Pokechu22 made were slightly at cross
>>> purposes. James made buttons in the Track Control Panels (TCP) slightly
>>> taller which caused the MIDI channel controls to be slightly overlapped.
>>> I
>>> have moved them and the Velocity slider down a little.
>>>
>>> Also the status text in WaveTracks was overlapped at top by one pixel.  I
>>> have moved the text down three pixels, leaving all else unmoved.
>>>
>>> Also (an old problem), sliders and buttons that are hidden when you lessen
>>> the track height still remained responsive to mouse clicks!  That is
>>> fixed.
>>>
>>> Also I rewrote much code in what I think is a better way that eliminates
>>> several "magic numbers" and puts more layout details into a declarative,
>>> tabular form rather than procedural.
>>>
>>> PRL
>>>
>>>
>>


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

Re: Reconciling Dark Audacity and MIDI play changes to TCP layout

Paul Licameli
In reply to this post by Gale


On Tue, Jun 6, 2017 at 3:31 PM, Gale Andrews <[hidden email]> wrote:
Thanks Paul. A problem I have on Windows 1280x1024 that
I think is P1, is that the default height of mono tracks now does
not show the Pan slider.  I trust this is not intentional.

Since which commit?  My recent changes or James' earlier merging of DA changes?

The constant kTrackInfoButtonSize in TrackPanel.h was increased from 16 to 18 since 2.1.3.  That means buttons got taller, and that might be crowding out the sliders.  It might be that changing this constant to 16 would fix that symptom.
 

And likewise (but not P1 on its own) default height of Note Tracks
now does not show the velocity slider.

I did shift things down to make the channel buttons show fully without being obscured by the taller menu button.  The default height might need increase then.
 

And yes, the bottom line of info text is now almost flush with the
top of the Mute/Solo buttons, instead of equidistant between
menu button and Mute/Solo as before. I could live with it.

That suggests I did not strike the right compromise between Windows and Mac which treat the text a bit differently.

PRL

 

Many thanks for preventing hidden sliders being clicked on.



Gale


On 6 June 2017 at 17:20, Paul Licameli <[hidden email]> wrote:
>
>
> On Tue, Jun 6, 2017 at 11:52 AM, Peter Sampson
> <[hidden email]> wrote:
>>
>>
>>
>> On Tue, Jun 6, 2017 at 3:10 PM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>> I should mention what I did here will change the screen shots of Wave
>>> tracks that include the controls, and this has implications for manual
>>> update.
>>>
>>> Does this make much more work for documentation?
>>
>>
>> It would/could do - but I can't see any visual differences comparing W10
>> audacity-win-r63c89e1-2.2.0-alpha-06-jun-17
>> and images of audio tracks in the alpha Manual :-??
>>
>> Peter.
>
>
> This few-pixel difference was significant for me on a MacBook.  I didn't
> check it on my Windows.  But I have reasons to suspect wxWidgets for Mac and
> Windows treat text slightly differently.  That is what the experience of
> last summer's scrubbing interface taught me.  Remember how text on buttons
> that looked good on Mac was drawn illegibly small on Windows?
>
> On MacBook I had been seeing the  menu button overlap the top of the text by
> one pixel and now I do not.
>
> PRL
>
>
>>
>>
>>>
>>>
>>> But I think the placement of the wave track status text, before my
>>> changes, was rather obviously unacceptable.  Did nobody else raise this
>>> issue?
>>>
>>> As for reinventing sizers, this is beyond the scope of what I mean for
>>> 2.2.0.  Really this recent thing is another small obstacle to the real track
>>> panel refactor which is still pending.  An obstacle I needed to take on.
>>>
>>> PRL
>>>
>>>
>>> On Tue, Jun 6, 2017 at 3:37 AM, James Crook <[hidden email]> wrote:
>>>>
>>>> Looks a bit tidier.
>>>>
>>>> I think the long term goal (not for 2.2.0) should be to go for a sizer
>>>> like mechanism, so we avoid all these per-button functions for different
>>>> positions.  It is hardly worth it for the TCP alone, but if the tracks and
>>>> toolbars also are in a sizer then it starts to be worthwhile.  Of course
>>>> we'd need functionality that does not yet exist in sizers to support
>>>> everything the TCP, Track Panel and docks do with sizing and positioning.
>>>> I'd say our own sizer (re)implementation, rather than extending the one in
>>>> wxWidgets. Something to think about for the future.
>>>>
>>>> --James.
>>>>
>>>>
>>>>
>>>> On 6/6/2017 2:57 AM, Paul Licameli wrote:
>>>>>
>>>>> See commit ca62891
>>>>>
>>>>> I think the changes James and Pokechu22 made were slightly at cross
>>>>> purposes. James made buttons in the Track Control Panels (TCP) slightly
>>>>> taller which caused the MIDI channel controls to be slightly
>>>>> overlapped.  I
>>>>> have moved them and the Velocity slider down a little.
>>>>>
>>>>> Also the status text in WaveTracks was overlapped at top by one pixel.
>>>>> I
>>>>> have moved the text down three pixels, leaving all else unmoved.
>>>>>
>>>>> Also (an old problem), sliders and buttons that are hidden when you
>>>>> lessen
>>>>> the track height still remained responsive to mouse clicks!  That is
>>>>> fixed.
>>>>>
>>>>> Also I rewrote much code in what I think is a better way that
>>>>> eliminates
>>>>> several "magic numbers" and puts more layout details into a
>>>>> declarative,
>>>>> tabular form rather than procedural.
>>>>>
>>>>> PRL
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

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


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

Re: Reconciling Dark Audacity and MIDI play changes to TCP layout

Gale
Administrator
On 6 June 2017 at 22:56, Paul Licameli <[hidden email]> wrote:

>
>
> On Tue, Jun 6, 2017 at 3:31 PM, Gale Andrews <[hidden email]> wrote:
>>
>> Thanks Paul. A problem I have on Windows 1280x1024 that
>> I think is P1, is that the default height of mono tracks now does
>> not show the Pan slider.  I trust this is not intentional.
>
>
> Since which commit?  My recent changes or James' earlier merging of DA
> changes?

I can't be very exact, Paul. r63c89e1 (06-jun-17) displays the behaviour and
beab669 (03-jun-17) does not.  I have not yet built Audacity today on Ubuntu
- it is inching there now.



Gale


> The constant kTrackInfoButtonSize in TrackPanel.h was increased from 16 to
> 18 since 2.1.3.  That means buttons got taller, and that might be crowding
> out the sliders.  It might be that changing this constant to 16 would fix
> that symptom.
>
>>
>>
>> And likewise (but not P1 on its own) default height of Note Tracks
>> now does not show the velocity slider.
>
>
> I did shift things down to make the channel buttons show fully without being
> obscured by the taller menu button.  The default height might need increase
> then.
>
>>
>>
>> And yes, the bottom line of info text is now almost flush with the
>> top of the Mute/Solo buttons, instead of equidistant between
>> menu button and Mute/Solo as before. I could live with it.
>
>
> That suggests I did not strike the right compromise between Windows and Mac
> which treat the text a bit differently.
>
> PRL
>
>
>>
>>
>> Many thanks for preventing hidden sliders being clicked on.
>>
>>
>>
>> Gale
>>
>>
>> On 6 June 2017 at 17:20, Paul Licameli <[hidden email]> wrote:
>> >
>> >
>> > On Tue, Jun 6, 2017 at 11:52 AM, Peter Sampson
>> > <[hidden email]> wrote:
>> >>
>> >>
>> >>
>> >> On Tue, Jun 6, 2017 at 3:10 PM, Paul Licameli <[hidden email]>
>> >> wrote:
>> >>>
>> >>> I should mention what I did here will change the screen shots of Wave
>> >>> tracks that include the controls, and this has implications for manual
>> >>> update.
>> >>>
>> >>> Does this make much more work for documentation?
>> >>
>> >>
>> >> It would/could do - but I can't see any visual differences comparing
>> >> W10
>> >> audacity-win-r63c89e1-2.2.0-alpha-06-jun-17
>> >> and images of audio tracks in the alpha Manual :-??
>> >>
>> >> Peter.
>> >
>> >
>> > This few-pixel difference was significant for me on a MacBook.  I didn't
>> > check it on my Windows.  But I have reasons to suspect wxWidgets for Mac
>> > and
>> > Windows treat text slightly differently.  That is what the experience of
>> > last summer's scrubbing interface taught me.  Remember how text on
>> > buttons
>> > that looked good on Mac was drawn illegibly small on Windows?
>> >
>> > On MacBook I had been seeing the  menu button overlap the top of the
>> > text by
>> > one pixel and now I do not.
>> >
>> > PRL
>> >
>> >
>> >>
>> >>
>> >>>
>> >>>
>> >>> But I think the placement of the wave track status text, before my
>> >>> changes, was rather obviously unacceptable.  Did nobody else raise
>> >>> this
>> >>> issue?
>> >>>
>> >>> As for reinventing sizers, this is beyond the scope of what I mean for
>> >>> 2.2.0.  Really this recent thing is another small obstacle to the real
>> >>> track
>> >>> panel refactor which is still pending.  An obstacle I needed to take
>> >>> on.
>> >>>
>> >>> PRL
>> >>>
>> >>>
>> >>> On Tue, Jun 6, 2017 at 3:37 AM, James Crook <[hidden email]> wrote:
>> >>>>
>> >>>> Looks a bit tidier.
>> >>>>
>> >>>> I think the long term goal (not for 2.2.0) should be to go for a
>> >>>> sizer
>> >>>> like mechanism, so we avoid all these per-button functions for
>> >>>> different
>> >>>> positions.  It is hardly worth it for the TCP alone, but if the
>> >>>> tracks and
>> >>>> toolbars also are in a sizer then it starts to be worthwhile.  Of
>> >>>> course
>> >>>> we'd need functionality that does not yet exist in sizers to support
>> >>>> everything the TCP, Track Panel and docks do with sizing and
>> >>>> positioning.
>> >>>> I'd say our own sizer (re)implementation, rather than extending the
>> >>>> one in
>> >>>> wxWidgets. Something to think about for the future.
>> >>>>
>> >>>> --James.
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 6/6/2017 2:57 AM, Paul Licameli wrote:
>> >>>>>
>> >>>>> See commit ca62891
>> >>>>>
>> >>>>> I think the changes James and Pokechu22 made were slightly at cross
>> >>>>> purposes. James made buttons in the Track Control Panels (TCP)
>> >>>>> slightly
>> >>>>> taller which caused the MIDI channel controls to be slightly
>> >>>>> overlapped.  I
>> >>>>> have moved them and the Velocity slider down a little.
>> >>>>>
>> >>>>> Also the status text in WaveTracks was overlapped at top by one
>> >>>>> pixel.
>> >>>>> I
>> >>>>> have moved the text down three pixels, leaving all else unmoved.
>> >>>>>
>> >>>>> Also (an old problem), sliders and buttons that are hidden when you
>> >>>>> lessen
>> >>>>> the track height still remained responsive to mouse clicks!  That is
>> >>>>> fixed.
>> >>>>>
>> >>>>> Also I rewrote much code in what I think is a better way that
>> >>>>> eliminates
>> >>>>> several "magic numbers" and puts more layout details into a
>> >>>>> declarative,
>> >>>>> tabular form rather than procedural.
>> >>>>>
>> >>>>> PRL
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>> Check out the vibrant tech community on one of the world's most
>> >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >>>> _______________________________________________
>> >>>> Audacity-quality mailing list
>> >>>> [hidden email]
>> >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Check out the vibrant tech community on one of the world's most
>> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >>> _______________________________________________
>> >>> Audacity-quality mailing list
>> >>> [hidden email]
>> >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> _______________________________________________
>> >> Audacity-quality mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > Audacity-quality mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

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

Re: Reconciling Dark Audacity and MIDI play changes to TCP layout

Paul Licameli


On Tue, Jun 6, 2017 at 8:56 PM, Gale Andrews <[hidden email]> wrote:
On 6 June 2017 at 22:56, Paul Licameli <[hidden email]> wrote:
>
>
> On Tue, Jun 6, 2017 at 3:31 PM, Gale Andrews <[hidden email]> wrote:
>>
>> Thanks Paul. A problem I have on Windows 1280x1024 that
>> I think is P1, is that the default height of mono tracks now does
>> not show the Pan slider.  I trust this is not intentional.
>
>
> Since which commit?  My recent changes or James' earlier merging of DA
> changes?

I can't be very exact, Paul. r63c89e1 (06-jun-17) displays the behaviour and
beab669 (03-jun-17) does not.  I have not yet built Audacity today on Ubuntu
- it is inching there now.

 
Good enough -- likely my fault then.  I'm on it.

PRL
 


Gale


> The constant kTrackInfoButtonSize in TrackPanel.h was increased from 16 to
> 18 since 2.1.3.  That means buttons got taller, and that might be crowding
> out the sliders.  It might be that changing this constant to 16 would fix
> that symptom.
>
>>
>>
>> And likewise (but not P1 on its own) default height of Note Tracks
>> now does not show the velocity slider.
>
>
> I did shift things down to make the channel buttons show fully without being
> obscured by the taller menu button.  The default height might need increase
> then.
>
>>
>>
>> And yes, the bottom line of info text is now almost flush with the
>> top of the Mute/Solo buttons, instead of equidistant between
>> menu button and Mute/Solo as before. I could live with it.
>
>
> That suggests I did not strike the right compromise between Windows and Mac
> which treat the text a bit differently.
>
> PRL
>
>
>>
>>
>> Many thanks for preventing hidden sliders being clicked on.
>>
>>
>>
>> Gale
>>
>>
>> On 6 June 2017 at 17:20, Paul Licameli <[hidden email]> wrote:
>> >
>> >
>> > On Tue, Jun 6, 2017 at 11:52 AM, Peter Sampson
>> > <[hidden email]> wrote:
>> >>
>> >>
>> >>
>> >> On Tue, Jun 6, 2017 at 3:10 PM, Paul Licameli <[hidden email]>
>> >> wrote:
>> >>>
>> >>> I should mention what I did here will change the screen shots of Wave
>> >>> tracks that include the controls, and this has implications for manual
>> >>> update.
>> >>>
>> >>> Does this make much more work for documentation?
>> >>
>> >>
>> >> It would/could do - but I can't see any visual differences comparing
>> >> W10
>> >> audacity-win-r63c89e1-2.2.0-alpha-06-jun-17
>> >> and images of audio tracks in the alpha Manual :-??
>> >>
>> >> Peter.
>> >
>> >
>> > This few-pixel difference was significant for me on a MacBook.  I didn't
>> > check it on my Windows.  But I have reasons to suspect wxWidgets for Mac
>> > and
>> > Windows treat text slightly differently.  That is what the experience of
>> > last summer's scrubbing interface taught me.  Remember how text on
>> > buttons
>> > that looked good on Mac was drawn illegibly small on Windows?
>> >
>> > On MacBook I had been seeing the  menu button overlap the top of the
>> > text by
>> > one pixel and now I do not.
>> >
>> > PRL
>> >
>> >
>> >>
>> >>
>> >>>
>> >>>
>> >>> But I think the placement of the wave track status text, before my
>> >>> changes, was rather obviously unacceptable.  Did nobody else raise
>> >>> this
>> >>> issue?
>> >>>
>> >>> As for reinventing sizers, this is beyond the scope of what I mean for
>> >>> 2.2.0.  Really this recent thing is another small obstacle to the real
>> >>> track
>> >>> panel refactor which is still pending.  An obstacle I needed to take
>> >>> on.
>> >>>
>> >>> PRL
>> >>>
>> >>>
>> >>> On Tue, Jun 6, 2017 at 3:37 AM, James Crook <[hidden email]> wrote:
>> >>>>
>> >>>> Looks a bit tidier.
>> >>>>
>> >>>> I think the long term goal (not for 2.2.0) should be to go for a
>> >>>> sizer
>> >>>> like mechanism, so we avoid all these per-button functions for
>> >>>> different
>> >>>> positions.  It is hardly worth it for the TCP alone, but if the
>> >>>> tracks and
>> >>>> toolbars also are in a sizer then it starts to be worthwhile.  Of
>> >>>> course
>> >>>> we'd need functionality that does not yet exist in sizers to support
>> >>>> everything the TCP, Track Panel and docks do with sizing and
>> >>>> positioning.
>> >>>> I'd say our own sizer (re)implementation, rather than extending the
>> >>>> one in
>> >>>> wxWidgets. Something to think about for the future.
>> >>>>
>> >>>> --James.
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 6/6/2017 2:57 AM, Paul Licameli wrote:
>> >>>>>
>> >>>>> See commit ca62891
>> >>>>>
>> >>>>> I think the changes James and Pokechu22 made were slightly at cross
>> >>>>> purposes. James made buttons in the Track Control Panels (TCP)
>> >>>>> slightly
>> >>>>> taller which caused the MIDI channel controls to be slightly
>> >>>>> overlapped.  I
>> >>>>> have moved them and the Velocity slider down a little.
>> >>>>>
>> >>>>> Also the status text in WaveTracks was overlapped at top by one
>> >>>>> pixel.
>> >>>>> I
>> >>>>> have moved the text down three pixels, leaving all else unmoved.
>> >>>>>
>> >>>>> Also (an old problem), sliders and buttons that are hidden when you
>> >>>>> lessen
>> >>>>> the track height still remained responsive to mouse clicks!  That is
>> >>>>> fixed.
>> >>>>>
>> >>>>> Also I rewrote much code in what I think is a better way that
>> >>>>> eliminates
>> >>>>> several "magic numbers" and puts more layout details into a
>> >>>>> declarative,
>> >>>>> tabular form rather than procedural.
>> >>>>>
>> >>>>> PRL
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>> Check out the vibrant tech community on one of the world's most
>> >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >>>> _______________________________________________
>> >>>> Audacity-quality mailing list
>> >>>> [hidden email]
>> >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Check out the vibrant tech community on one of the world's most
>> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >>> _______________________________________________
>> >>> Audacity-quality mailing list
>> >>> [hidden email]
>> >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> _______________________________________________
>> >> Audacity-quality mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > Audacity-quality mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

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


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

Re: Reconciling Dark Audacity and MIDI play changes to TCP layout

Paul Licameli
In reply to this post by Gale


On Tue, Jun 6, 2017 at 8:56 PM, Gale Andrews <[hidden email]> wrote:
On 6 June 2017 at 22:56, Paul Licameli <[hidden email]> wrote:
>
>
> On Tue, Jun 6, 2017 at 3:31 PM, Gale Andrews <[hidden email]> wrote:
>>
>> Thanks Paul. A problem I have on Windows 1280x1024 that
>> I think is P1, is that the default height of mono tracks now does
>> not show the Pan slider.  I trust this is not intentional.
>
>
> Since which commit?  My recent changes or James' earlier merging of DA
> changes?

I can't be very exact, Paul. r63c89e1 (06-jun-17) displays the behaviour and
beab669 (03-jun-17) does not.  I have not yet built Audacity today on Ubuntu
- it is inching there now.



Gale

Gale, try it again at 2fe5731

Observe both Wave and Note tracks at default height.

Default height of Note tracks is now eight pixels more than for other tracks.

PRL

 


> The constant kTrackInfoButtonSize in TrackPanel.h was increased from 16 to
> 18 since 2.1.3.  That means buttons got taller, and that might be crowding
> out the sliders.  It might be that changing this constant to 16 would fix
> that symptom.
>
>>
>>
>> And likewise (but not P1 on its own) default height of Note Tracks
>> now does not show the velocity slider.
>
>
> I did shift things down to make the channel buttons show fully without being
> obscured by the taller menu button.  The default height might need increase
> then.
>
>>
>>
>> And yes, the bottom line of info text is now almost flush with the
>> top of the Mute/Solo buttons, instead of equidistant between
>> menu button and Mute/Solo as before. I could live with it.
>
>
> That suggests I did not strike the right compromise between Windows and Mac
> which treat the text a bit differently.
>
> PRL
>
>
>>
>>
>> Many thanks for preventing hidden sliders being clicked on.
>>
>>
>>
>> Gale
>>
>>
>> On 6 June 2017 at 17:20, Paul Licameli <[hidden email]> wrote:
>> >
>> >
>> > On Tue, Jun 6, 2017 at 11:52 AM, Peter Sampson
>> > <[hidden email]> wrote:
>> >>
>> >>
>> >>
>> >> On Tue, Jun 6, 2017 at 3:10 PM, Paul Licameli <[hidden email]>
>> >> wrote:
>> >>>
>> >>> I should mention what I did here will change the screen shots of Wave
>> >>> tracks that include the controls, and this has implications for manual
>> >>> update.
>> >>>
>> >>> Does this make much more work for documentation?
>> >>
>> >>
>> >> It would/could do - but I can't see any visual differences comparing
>> >> W10
>> >> audacity-win-r63c89e1-2.2.0-alpha-06-jun-17
>> >> and images of audio tracks in the alpha Manual :-??
>> >>
>> >> Peter.
>> >
>> >
>> > This few-pixel difference was significant for me on a MacBook.  I didn't
>> > check it on my Windows.  But I have reasons to suspect wxWidgets for Mac
>> > and
>> > Windows treat text slightly differently.  That is what the experience of
>> > last summer's scrubbing interface taught me.  Remember how text on
>> > buttons
>> > that looked good on Mac was drawn illegibly small on Windows?
>> >
>> > On MacBook I had been seeing the  menu button overlap the top of the
>> > text by
>> > one pixel and now I do not.
>> >
>> > PRL
>> >
>> >
>> >>
>> >>
>> >>>
>> >>>
>> >>> But I think the placement of the wave track status text, before my
>> >>> changes, was rather obviously unacceptable.  Did nobody else raise
>> >>> this
>> >>> issue?
>> >>>
>> >>> As for reinventing sizers, this is beyond the scope of what I mean for
>> >>> 2.2.0.  Really this recent thing is another small obstacle to the real
>> >>> track
>> >>> panel refactor which is still pending.  An obstacle I needed to take
>> >>> on.
>> >>>
>> >>> PRL
>> >>>
>> >>>
>> >>> On Tue, Jun 6, 2017 at 3:37 AM, James Crook <[hidden email]> wrote:
>> >>>>
>> >>>> Looks a bit tidier.
>> >>>>
>> >>>> I think the long term goal (not for 2.2.0) should be to go for a
>> >>>> sizer
>> >>>> like mechanism, so we avoid all these per-button functions for
>> >>>> different
>> >>>> positions.  It is hardly worth it for the TCP alone, but if the
>> >>>> tracks and
>> >>>> toolbars also are in a sizer then it starts to be worthwhile.  Of
>> >>>> course
>> >>>> we'd need functionality that does not yet exist in sizers to support
>> >>>> everything the TCP, Track Panel and docks do with sizing and
>> >>>> positioning.
>> >>>> I'd say our own sizer (re)implementation, rather than extending the
>> >>>> one in
>> >>>> wxWidgets. Something to think about for the future.
>> >>>>
>> >>>> --James.
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 6/6/2017 2:57 AM, Paul Licameli wrote:
>> >>>>>
>> >>>>> See commit ca62891
>> >>>>>
>> >>>>> I think the changes James and Pokechu22 made were slightly at cross
>> >>>>> purposes. James made buttons in the Track Control Panels (TCP)
>> >>>>> slightly
>> >>>>> taller which caused the MIDI channel controls to be slightly
>> >>>>> overlapped.  I
>> >>>>> have moved them and the Velocity slider down a little.
>> >>>>>
>> >>>>> Also the status text in WaveTracks was overlapped at top by one
>> >>>>> pixel.
>> >>>>> I
>> >>>>> have moved the text down three pixels, leaving all else unmoved.
>> >>>>>
>> >>>>> Also (an old problem), sliders and buttons that are hidden when you
>> >>>>> lessen
>> >>>>> the track height still remained responsive to mouse clicks!  That is
>> >>>>> fixed.
>> >>>>>
>> >>>>> Also I rewrote much code in what I think is a better way that
>> >>>>> eliminates
>> >>>>> several "magic numbers" and puts more layout details into a
>> >>>>> declarative,
>> >>>>> tabular form rather than procedural.
>> >>>>>
>> >>>>> PRL
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>> Check out the vibrant tech community on one of the world's most
>> >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >>>> _______________________________________________
>> >>>> Audacity-quality mailing list
>> >>>> [hidden email]
>> >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Check out the vibrant tech community on one of the world's most
>> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >>> _______________________________________________
>> >>> Audacity-quality mailing list
>> >>> [hidden email]
>> >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> _______________________________________________
>> >> Audacity-quality mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > Audacity-quality mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

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


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

Re: Reconciling Dark Audacity and MIDI play changes to TCP layout

Paul Licameli
In reply to this post by James Crook


On Tue, Jun 6, 2017 at 5:52 PM, James Crook <[hidden email]> wrote:
On 6/6/2017 3:10 PM, Paul Licameli wrote:
I should mention what I did here will change the screen shots of Wave
tracks that include the controls, and this has implications for manual
update.

Does this make much more work for documentation?
My (personal) view is that manual does not have to update all the screenshots for a small positional change.  The point of  manual is to explain, and already on Linux/Mac images will be very slightly different.

I agree with that.
 

More significant is the decision on whether to release 2.2.0 with Classic theme as the default or Light as the default.  That is a decision for RM.  Even then, manual team might decide not to update the annotated toolbar images in the manual, just Bill's hyperlinked image on the front page.

Again, I said we can go with Light.  "Maniual" (Peter) exresses willingness to cooperate.
 



But I think the placement of the wave track status text, before my changes,
was rather obviously unacceptable.  Did nobody else raise this issue?
On windows I think the positioning of the status message was better previously.  On windows it now needs a little more space below the text for it to look right.


I took a harder look at both Windows and Mac.  Result was commit acce480, which leaves things as James coded them, except on Mac.  I think we have to compensate some cross-platform differences in what wxWidgets does with text, to get it good looking on all platforms.

PRL
 

As for reinventing sizers, this is beyond the scope of what I mean for
2.2.0.  Really this recent thing is another small obstacle to the real
track panel refactor which is still pending.  An obstacle I needed to take
on.
Yes.  That's what I said too.  Our own sizers are to think about as a long term goal for the future, not for 2.2.0.  I have actually implemented simple box sizers for controls that aren't hWnd based (in AU14), with something very like ShuttleGUI for using them.  Main benefit (relative to wxWidgets sizers) was no flicker on resizing/dragging.

--James.




PRL


On Tue, Jun 6, 2017 at 3:37 AM, James Crook <[hidden email]> wrote:

Looks a bit tidier.

I think the long term goal (not for 2.2.0) should be to go for a sizer
like mechanism, so we avoid all these per-button functions for different
positions.  It is hardly worth it for the TCP alone, but if the tracks and
toolbars also are in a sizer then it starts to be worthwhile.  Of course
we'd need functionality that does not yet exist in sizers to support
everything the TCP, Track Panel and docks do with sizing and positioning.
I'd say our own sizer (re)implementation, rather than extending the one in
wxWidgets. Something to think about for the future.

--James.



On 6/6/2017 2:57 AM, Paul Licameli wrote:

See commit ca62891

I think the changes James and Pokechu22 made were slightly at cross
purposes. James made buttons in the Track Control Panels (TCP) slightly
taller which caused the MIDI channel controls to be slightly overlapped.
I
have moved them and the Velocity slider down a little.

Also the status text in WaveTracks was overlapped at top by one pixel.  I
have moved the text down three pixels, leaving all else unmoved.

Also (an old problem), sliders and buttons that are hidden when you lessen
the track height still remained responsive to mouse clicks!  That is
fixed.

Also I rewrote much code in what I think is a better way that eliminates
several "magic numbers" and puts more layout details into a declarative,
tabular form rather than procedural.

PRL





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


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

Re: Reconciling Dark Audacity and MIDI play changes to TCP layout

Peter Sampson-2


On Fri, Jun 9, 2017 at 5:26 PM, Paul Licameli <[hidden email]> wrote:


On Tue, Jun 6, 2017 at 5:52 PM, James Crook <[hidden email]> wrote:
On 6/6/2017 3:10 PM, Paul Licameli wrote:
I should mention what I did here will change the screen shots of Wave
tracks that include the controls, and this has implications for manual
update.

Does this make much more work for documentation?
My (personal) view is that manual does not have to update all the screenshots for a small positional change.  The point of  manual is to explain, and already on Linux/Mac images will be very slightly different.

I agree with that.

That was my view too. 
 
 

More significant is the decision on whether to release 2.2.0 with Classic theme as the default or Light as the default.  That is a decision for RM.  Even then, manual team might decide not to update the annotated toolbar images in the manual, just Bill's hyperlinked image on the front page.

Again, I said we can go with Light.  "Maniual" (Peter) exresses willingness to cooperate.

Great - so "Light"  as default it is then - I assume someone will make the necessary reset
in a commit at some stage.

But now the decision for "Light" theme we can get on with sorting the necessary pages in
the Manual.

As James says, critical reference pages like the Front page and the Toolbars will, of course,
be redone with "Light" theme.   And I will consider which others need reworking.
 
 



But I think the placement of the wave track status text, before my changes,
was rather obviously unacceptable.  Did nobody else raise this issue?
On windows I think the positioning of the status message was better previously.  On windows it now needs a little more space below the text for it to look right.


I took a harder look at both Windows and Mac.  Result was commit acce480, which leaves things as James coded them, except on Mac.  I think we have to compensate some cross-platform differences in what wxWidgets does with text, to get it good looking on all platforms.

PRL
 

As for reinventing sizers, this is beyond the scope of what I mean for
2.2.0.  Really this recent thing is another small obstacle to the real
track panel refactor which is still pending.  An obstacle I needed to take
on.
Yes.  That's what I said too.  Our own sizers are to think about as a long term goal for the future, not for 2.2.0.  I have actually implemented simple box sizers for controls that aren't hWnd based (in AU14), with something very like ShuttleGUI for using them.  Main benefit (relative to wxWidgets sizers) was no flicker on resizing/dragging.

--James.




PRL


On Tue, Jun 6, 2017 at 3:37 AM, James Crook <[hidden email]> wrote:

Looks a bit tidier.

I think the long term goal (not for 2.2.0) should be to go for a sizer
like mechanism, so we avoid all these per-button functions for different
positions.  It is hardly worth it for the TCP alone, but if the tracks and
toolbars also are in a sizer then it starts to be worthwhile.  Of course
we'd need functionality that does not yet exist in sizers to support
everything the TCP, Track Panel and docks do with sizing and positioning.
I'd say our own sizer (re)implementation, rather than extending the one in
wxWidgets. Something to think about for the future.

--James.



On 6/6/2017 2:57 AM, Paul Licameli wrote:

See commit ca62891

I think the changes James and Pokechu22 made were slightly at cross
purposes. James made buttons in the Track Control Panels (TCP) slightly
taller which caused the MIDI channel controls to be slightly overlapped.
I
have moved them and the Velocity slider down a little.

Also the status text in WaveTracks was overlapped at top by one pixel.  I
have moved the text down three pixels, leaving all else unmoved.

Also (an old problem), sliders and buttons that are hidden when you lessen
the track height still remained responsive to mouse clicks!  That is
fixed.

Also I rewrote much code in what I think is a better way that eliminates
several "magic numbers" and puts more layout details into a declarative,
tabular form rather than procedural.

PRL





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


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



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

Re: Reconciling Dark Audacity and MIDI play changes to TCP layout

Gale
Administrator
In reply to this post by Paul Licameli
On 7 June 2017 at 04:08, Paul Licameli <[hidden email]> wrote:

>
>
> On Tue, Jun 6, 2017 at 8:56 PM, Gale Andrews <[hidden email]> wrote:
>>
>> On 6 June 2017 at 22:56, Paul Licameli <[hidden email]> wrote:
>> >
>> >
>> > On Tue, Jun 6, 2017 at 3:31 PM, Gale Andrews <[hidden email]>
>> > wrote:
>> >>
>> >> Thanks Paul. A problem I have on Windows 1280x1024 that
>> >> I think is P1, is that the default height of mono tracks now does
>> >> not show the Pan slider.  I trust this is not intentional.
>> >
>> >
>> > Since which commit?  My recent changes or James' earlier merging of DA
>> > changes?
>>
>> I can't be very exact, Paul. r63c89e1 (06-jun-17) displays the behaviour
>> and
>> beab669 (03-jun-17) does not.  I have not yet built Audacity today on
>> Ubuntu
>> - it is inching there now.
>>
>>
>>
>> Gale
>
>
> Gale, try it again at 2fe5731
>
> Observe both Wave and Note tracks at default height.
>
> Default height of Note tracks is now eight pixels more than for other
> tracks.
>
> PRL

Thanks Paul. Yes it seems fine now. I see the Pan slider on Windows
and Linux and the velocity slider on Windows in a default mono track.


Gale

>
>>
>>
>>
>> > The constant kTrackInfoButtonSize in TrackPanel.h was increased from 16
>> > to
>> > 18 since 2.1.3.  That means buttons got taller, and that might be
>> > crowding
>> > out the sliders.  It might be that changing this constant to 16 would
>> > fix
>> > that symptom.
>> >
>> >>
>> >>
>> >> And likewise (but not P1 on its own) default height of Note Tracks
>> >> now does not show the velocity slider.
>> >
>> >
>> > I did shift things down to make the channel buttons show fully without
>> > being
>> > obscured by the taller menu button.  The default height might need
>> > increase
>> > then.
>> >
>> >>
>> >>
>> >> And yes, the bottom line of info text is now almost flush with the
>> >> top of the Mute/Solo buttons, instead of equidistant between
>> >> menu button and Mute/Solo as before. I could live with it.
>> >
>> >
>> > That suggests I did not strike the right compromise between Windows and
>> > Mac
>> > which treat the text a bit differently.
>> >
>> > PRL
>> >
>> >
>> >>
>> >>
>> >> Many thanks for preventing hidden sliders being clicked on.
>> >>
>> >>
>> >>
>> >> Gale
>> >>
>> >>
>> >> On 6 June 2017 at 17:20, Paul Licameli <[hidden email]> wrote:
>> >> >
>> >> >
>> >> > On Tue, Jun 6, 2017 at 11:52 AM, Peter Sampson
>> >> > <[hidden email]> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Tue, Jun 6, 2017 at 3:10 PM, Paul Licameli
>> >> >> <[hidden email]>
>> >> >> wrote:
>> >> >>>
>> >> >>> I should mention what I did here will change the screen shots of
>> >> >>> Wave
>> >> >>> tracks that include the controls, and this has implications for
>> >> >>> manual
>> >> >>> update.
>> >> >>>
>> >> >>> Does this make much more work for documentation?
>> >> >>
>> >> >>
>> >> >> It would/could do - but I can't see any visual differences comparing
>> >> >> W10
>> >> >> audacity-win-r63c89e1-2.2.0-alpha-06-jun-17
>> >> >> and images of audio tracks in the alpha Manual :-??
>> >> >>
>> >> >> Peter.
>> >> >
>> >> >
>> >> > This few-pixel difference was significant for me on a MacBook.  I
>> >> > didn't
>> >> > check it on my Windows.  But I have reasons to suspect wxWidgets for
>> >> > Mac
>> >> > and
>> >> > Windows treat text slightly differently.  That is what the experience
>> >> > of
>> >> > last summer's scrubbing interface taught me.  Remember how text on
>> >> > buttons
>> >> > that looked good on Mac was drawn illegibly small on Windows?
>> >> >
>> >> > On MacBook I had been seeing the  menu button overlap the top of the
>> >> > text by
>> >> > one pixel and now I do not.
>> >> >
>> >> > PRL
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >>>
>> >> >>>
>> >> >>> But I think the placement of the wave track status text, before my
>> >> >>> changes, was rather obviously unacceptable.  Did nobody else raise
>> >> >>> this
>> >> >>> issue?
>> >> >>>
>> >> >>> As for reinventing sizers, this is beyond the scope of what I mean
>> >> >>> for
>> >> >>> 2.2.0.  Really this recent thing is another small obstacle to the
>> >> >>> real
>> >> >>> track
>> >> >>> panel refactor which is still pending.  An obstacle I needed to
>> >> >>> take
>> >> >>> on.
>> >> >>>
>> >> >>> PRL
>> >> >>>
>> >> >>>
>> >> >>> On Tue, Jun 6, 2017 at 3:37 AM, James Crook <[hidden email]>
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> Looks a bit tidier.
>> >> >>>>
>> >> >>>> I think the long term goal (not for 2.2.0) should be to go for a
>> >> >>>> sizer
>> >> >>>> like mechanism, so we avoid all these per-button functions for
>> >> >>>> different
>> >> >>>> positions.  It is hardly worth it for the TCP alone, but if the
>> >> >>>> tracks and
>> >> >>>> toolbars also are in a sizer then it starts to be worthwhile.  Of
>> >> >>>> course
>> >> >>>> we'd need functionality that does not yet exist in sizers to
>> >> >>>> support
>> >> >>>> everything the TCP, Track Panel and docks do with sizing and
>> >> >>>> positioning.
>> >> >>>> I'd say our own sizer (re)implementation, rather than extending
>> >> >>>> the
>> >> >>>> one in
>> >> >>>> wxWidgets. Something to think about for the future.
>> >> >>>>
>> >> >>>> --James.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> On 6/6/2017 2:57 AM, Paul Licameli wrote:
>> >> >>>>>
>> >> >>>>> See commit ca62891
>> >> >>>>>
>> >> >>>>> I think the changes James and Pokechu22 made were slightly at
>> >> >>>>> cross
>> >> >>>>> purposes. James made buttons in the Track Control Panels (TCP)
>> >> >>>>> slightly
>> >> >>>>> taller which caused the MIDI channel controls to be slightly
>> >> >>>>> overlapped.  I
>> >> >>>>> have moved them and the Velocity slider down a little.
>> >> >>>>>
>> >> >>>>> Also the status text in WaveTracks was overlapped at top by one
>> >> >>>>> pixel.
>> >> >>>>> I
>> >> >>>>> have moved the text down three pixels, leaving all else unmoved.
>> >> >>>>>
>> >> >>>>> Also (an old problem), sliders and buttons that are hidden when
>> >> >>>>> you
>> >> >>>>> lessen
>> >> >>>>> the track height still remained responsive to mouse clicks!  That
>> >> >>>>> is
>> >> >>>>> fixed.
>> >> >>>>>
>> >> >>>>> Also I rewrote much code in what I think is a better way that
>> >> >>>>> eliminates
>> >> >>>>> several "magic numbers" and puts more layout details into a
>> >> >>>>> declarative,
>> >> >>>>> tabular form rather than procedural.
>> >> >>>>>
>> >> >>>>> PRL
>> >> >>>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> ------------------------------------------------------------------------------
>> >> >>>> Check out the vibrant tech community on one of the world's most
>> >> >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> >>>> _______________________________________________
>> >> >>>> Audacity-quality mailing list
>> >> >>>> [hidden email]
>> >> >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> ------------------------------------------------------------------------------
>> >> >>> Check out the vibrant tech community on one of the world's most
>> >> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> >>> _______________________________________________
>> >> >>> Audacity-quality mailing list
>> >> >>> [hidden email]
>> >> >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> ------------------------------------------------------------------------------
>> >> >> Check out the vibrant tech community on one of the world's most
>> >> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> >> _______________________________________________
>> >> >> Audacity-quality mailing list
>> >> >> [hidden email]
>> >> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Check out the vibrant tech community on one of the world's most
>> >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> > _______________________________________________
>> >> > Audacity-quality mailing list
>> >> > [hidden email]
>> >> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> _______________________________________________
>> >> Audacity-quality mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > Audacity-quality mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

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

Re: Reconciling Dark Audacity and MIDI play changes to TCP layout

Peter Sampson-2
In reply to this post by Peter Sampson-2


On Fri, Jun 9, 2017 at 6:07 PM, Peter Sampson <[hidden email]> wrote:


On Fri, Jun 9, 2017 at 5:26 PM, Paul Licameli <[hidden email]> wrote:


On Tue, Jun 6, 2017 at 5:52 PM, James Crook <[hidden email]> wrote:
On 6/6/2017 3:10 PM, Paul Licameli wrote:
I should mention what I did here will change the screen shots of Wave
tracks that include the controls, and this has implications for manual
update.

Does this make much more work for documentation?
My (personal) view is that manual does not have to update all the screenshots for a small positional change.  The point of  manual is to explain, and already on Linux/Mac images will be very slightly different.

I agree with that.

That was my view too. 
 
 

More significant is the decision on whether to release 2.2.0 with Classic theme as the default or Light as the default.  That is a decision for RM.  Even then, manual team might decide not to update the annotated toolbar images in the manual, just Bill's hyperlinked image on the front page.

Again, I said we can go with Light.  "Maniual" (Peter) exresses willingness to cooperate.

Great - so "Light"  as default it is then - I assume someone will make the necessary reset
in a commit at some stage.

But now the decision for "Light" theme we can get on with sorting the necessary pages in
the Manual.

As James says, critical reference pages like the Front page and the Toolbars will, of course,
be redone with "Light" theme.   And I will consider which others need reworking.

I've trawled through the Manual and marked up with P1s the pages that *must* be updated
for Light theme.

Some of thees will just fall into place when I update the images for icons like the Puse and Stop
buttons.  But some (like the front page imagemap) will involve a fair bit of work.

Peter.

 
 
 



But I think the placement of the wave track status text, before my changes,
was rather obviously unacceptable.  Did nobody else raise this issue?
On windows I think the positioning of the status message was better previously.  On windows it now needs a little more space below the text for it to look right.


I took a harder look at both Windows and Mac.  Result was commit acce480, which leaves things as James coded them, except on Mac.  I think we have to compensate some cross-platform differences in what wxWidgets does with text, to get it good looking on all platforms.

PRL
 

As for reinventing sizers, this is beyond the scope of what I mean for
2.2.0.  Really this recent thing is another small obstacle to the real
track panel refactor which is still pending.  An obstacle I needed to take
on.
Yes.  That's what I said too.  Our own sizers are to think about as a long term goal for the future, not for 2.2.0.  I have actually implemented simple box sizers for controls that aren't hWnd based (in AU14), with something very like ShuttleGUI for using them.  Main benefit (relative to wxWidgets sizers) was no flicker on resizing/dragging.

--James.




PRL


On Tue, Jun 6, 2017 at 3:37 AM, James Crook <[hidden email]> wrote:

Looks a bit tidier.

I think the long term goal (not for 2.2.0) should be to go for a sizer
like mechanism, so we avoid all these per-button functions for different
positions.  It is hardly worth it for the TCP alone, but if the tracks and
toolbars also are in a sizer then it starts to be worthwhile.  Of course
we'd need functionality that does not yet exist in sizers to support
everything the TCP, Track Panel and docks do with sizing and positioning.
I'd say our own sizer (re)implementation, rather than extending the one in
wxWidgets. Something to think about for the future.

--James.



On 6/6/2017 2:57 AM, Paul Licameli wrote:

See commit ca62891

I think the changes James and Pokechu22 made were slightly at cross
purposes. James made buttons in the Track Control Panels (TCP) slightly
taller which caused the MIDI channel controls to be slightly overlapped.
I
have moved them and the Velocity slider down a little.

Also the status text in WaveTracks was overlapped at top by one pixel.  I
have moved the text down three pixels, leaving all else unmoved.

Also (an old problem), sliders and buttons that are hidden when you lessen
the track height still remained responsive to mouse clicks!  That is
fixed.

Also I rewrote much code in what I think is a better way that eliminates
several "magic numbers" and puts more layout details into a declarative,
tabular form rather than procedural.

PRL





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


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




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