SysStaff::distanceUp() and ::distanceDown() gone for good?

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

SysStaff::distanceUp() and ::distanceDown() gone for good?

sideways

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SysStaff::distanceUp() and ::distanceDown() gone for good?

sideways
I submitted this question to the list 5 days ago, and there has been no response, so I wanted to try again.  Is there a replacement for SysStaff::distanceUp() and distanceDown() in the latest master code?

Thanks,

Sideways

On 4/16/2016 12:29 PM, Sideways Skullfinger wrote:

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SysStaff::distanceUp() and ::distanceDown() gone for good?

wschweer9
_distanceUp and _distanceDown are gone and will not come back. The staff distance is now calculated in System->layout2()
and the system distance in Score->collectPage() which calls layoutPage().
The distance between systems can be determined by looking at system->pos().y().
SysStaff->_distanceUp/Down was used to collect information from layouting  elements like fret symbols etc. which might increase
the staff distance. This is replaced by a more generic algorithm which uses the Shape of staves to determine the minimum distance without
any collision.

Am 21.04.2016 um 20:43 schrieb Sideways Skullfinger:
I submitted this question to the list 5 days ago, and there has been no response, so I wanted to try again.  Is there a replacement for SysStaff::distanceUp() and distanceDown() in the latest master code?

Thanks,

Sideways

On 4/16/2016 12:29 PM, Sideways Skullfinger wrote:

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z


_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SysStaff::distanceUp() and ::distanceDown() gone for good?

sideways
Thank you for the detailed information.  I'll be changing my code today.  Like Michael Corleone, "Just when I thought I was out... they pull me back in."  I was very comfortable in my Qt 5.4 environment, but exactly 1 day before the master switched to 5.6, I was notified of some issues with code I had modified.  To enable a simple (barely any code changed) PR the next day, I had to upgrade.  Now I'm stuck, forced to use the latest master code now, not at some future time of my choosing.

I'm not complaining, just explaining my personal sense of urgency about this question (and possibly future questions).  I don't mind contributing to QA testing and making unplanned changes - that's just how it is some times in the Open Source world.  It's part of the price you pay for "free" software.

Thanks again for the clearly stated response.

--
James

On 4/22/2016 3:07 AM, Werner Schweer wrote:
_distanceUp and _distanceDown are gone and will not come back. The staff distance is now calculated in System->layout2()
and the system distance in Score->collectPage() which calls layoutPage().
The distance between systems can be determined by looking at system->pos().y().
SysStaff->_distanceUp/Down was used to collect information from layouting  elements like fret symbols etc. which might increase
the staff distance. This is replaced by a more generic algorithm which uses the Shape of staves to determine the minimum distance without
any collision.

Am 21.04.2016 um 20:43 schrieb Sideways Skullfinger:
I submitted this question to the list 5 days ago, and there has been no response, so I wanted to try again.  Is there a replacement for SysStaff::distanceUp() and distanceDown() in the latest master code?

Thanks,

Sideways

On 4/16/2016 12:29 PM, Sideways Skullfinger wrote:

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways




------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SysStaff::distanceUp() and ::distanceDown() gone for good?

Marc Sabatella
I seems like many of these issues are serious enough to want fixed on the 2.0.4 branch, so maybe focus first on building, developing, and testinh there? Then worry about restructuring for master later? Unless werner or lasconic advise otherwise...
On Fri, Apr 22, 2016 at 10:26 AM Sideways Skullfinger <[hidden email]> wrote:
Thank you for the detailed information.  I'll be changing my code today.  Like Michael Corleone, "Just when I thought I was out... they pull me back in."  I was very comfortable in my Qt 5.4 environment, but exactly 1 day before the master switched to 5.6, I was notified of some issues with code I had modified.  To enable a simple (barely any code changed) PR the next day, I had to upgrade.  Now I'm stuck, forced to use the latest master code now, not at some future time of my choosing.

I'm not complaining, just explaining my personal sense of urgency about this question (and possibly future questions).  I don't mind contributing to QA testing and making unplanned changes - that's just how it is some times in the Open Source world.  It's part of the price you pay for "free" software.

Thanks again for the clearly stated response.

--
James


On 4/22/2016 3:07 AM, Werner Schweer wrote:
_distanceUp and _distanceDown are gone and will not come back. The staff distance is now calculated in System->layout2()
and the system distance in Score->collectPage() which calls layoutPage().
The distance between systems can be determined by looking at system->pos().y().
SysStaff->_distanceUp/Down was used to collect information from layouting  elements like fret symbols etc. which might increase
the staff distance. This is replaced by a more generic algorithm which uses the Shape of staves to determine the minimum distance without
any collision.

Am 21.04.2016 um 20:43 schrieb Sideways Skullfinger:
I submitted this question to the list 5 days ago, and there has been no response, so I wanted to try again.  Is there a replacement for SysStaff::distanceUp() and distanceDown() in the latest master code?

Thanks,

Sideways

On 4/16/2016 12:29 PM, Sideways Skullfinger wrote:

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SysStaff::distanceUp() and ::distanceDown() gone for good?

lasconic
Administrator
Which issues are you talking about in particular?

lasconic

2016-04-22 19:09 GMT+02:00 Marc Sabatella <[hidden email]>:
I seems like many of these issues are serious enough to want fixed on the 2.0.4 branch, so maybe focus first on building, developing, and testinh there? Then worry about restructuring for master later? Unless werner or lasconic advise otherwise...
On Fri, Apr 22, 2016 at 10:26 AM Sideways Skullfinger <[hidden email]> wrote:
Thank you for the detailed information.  I'll be changing my code today.  Like Michael Corleone, "Just when I thought I was out... they pull me back in."  I was very comfortable in my Qt 5.4 environment, but exactly 1 day before the master switched to 5.6, I was notified of some issues with code I had modified.  To enable a simple (barely any code changed) PR the next day, I had to upgrade.  Now I'm stuck, forced to use the latest master code now, not at some future time of my choosing.

I'm not complaining, just explaining my personal sense of urgency about this question (and possibly future questions).  I don't mind contributing to QA testing and making unplanned changes - that's just how it is some times in the Open Source world.  It's part of the price you pay for "free" software.

Thanks again for the clearly stated response.

--
James


On 4/22/2016 3:07 AM, Werner Schweer wrote:
_distanceUp and _distanceDown are gone and will not come back. The staff distance is now calculated in System->layout2()
and the system distance in Score->collectPage() which calls layoutPage().
The distance between systems can be determined by looking at system->pos().y().
SysStaff->_distanceUp/Down was used to collect information from layouting  elements like fret symbols etc. which might increase
the staff distance. This is replaced by a more generic algorithm which uses the Shape of staves to determine the minimum distance without
any collision.

Am 21.04.2016 um 20:43 schrieb Sideways Skullfinger:
I submitted this question to the list 5 days ago, and there has been no response, so I wanted to try again.  Is there a replacement for SysStaff::distanceUp() and distanceDown() in the latest master code?

Thanks,

Sideways

On 4/16/2016 12:29 PM, Sideways Skullfinger wrote:

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SysStaff::distanceUp() and ::distanceDown() gone for good?

Marc Sabatella
Well, I was thinking of https://musescore.org/en/node/105436https://musescore.org/en/node/105471, and https://musescore.org/en/node/107081, which I guess are already fixed for 2.0.4 branch.  I guess maybe the last of these is the same as https://musescore.org/en/node/107126, but if not, then that one.  Together, these tell me there were big enough changes in SVG export that I won't be surprised to see other regressions serious enough to want to fix for any eventual 2.0.4, and given that the existing code presumably doesn't really work in master because so much has changed, it might be worth it to hold onto a 2.0.3 build environment for now in anticipation of further fixes needing to be applied.

On Fri, Apr 22, 2016 at 11:17 AM Lasconic <[hidden email]> wrote:
Which issues are you talking about in particular?

lasconic

2016-04-22 19:09 GMT+02:00 Marc Sabatella <[hidden email]>:
I seems like many of these issues are serious enough to want fixed on the 2.0.4 branch, so maybe focus first on building, developing, and testinh there? Then worry about restructuring for master later? Unless werner or lasconic advise otherwise...
On Fri, Apr 22, 2016 at 10:26 AM Sideways Skullfinger <[hidden email]> wrote:
Thank you for the detailed information.  I'll be changing my code today.  Like Michael Corleone, "Just when I thought I was out... they pull me back in."  I was very comfortable in my Qt 5.4 environment, but exactly 1 day before the master switched to 5.6, I was notified of some issues with code I had modified.  To enable a simple (barely any code changed) PR the next day, I had to upgrade.  Now I'm stuck, forced to use the latest master code now, not at some future time of my choosing.

I'm not complaining, just explaining my personal sense of urgency about this question (and possibly future questions).  I don't mind contributing to QA testing and making unplanned changes - that's just how it is some times in the Open Source world.  It's part of the price you pay for "free" software.

Thanks again for the clearly stated response.

--
James


On 4/22/2016 3:07 AM, Werner Schweer wrote:
_distanceUp and _distanceDown are gone and will not come back. The staff distance is now calculated in System->layout2()
and the system distance in Score->collectPage() which calls layoutPage().
The distance between systems can be determined by looking at system->pos().y().
SysStaff->_distanceUp/Down was used to collect information from layouting  elements like fret symbols etc. which might increase
the staff distance. This is replaced by a more generic algorithm which uses the Shape of staves to determine the minimum distance without
any collision.

Am 21.04.2016 um 20:43 schrieb Sideways Skullfinger:
I submitted this question to the list 5 days ago, and there has been no response, so I wanted to try again.  Is there a replacement for SysStaff::distanceUp() and distanceDown() in the latest master code?

Thanks,

Sideways

On 4/16/2016 12:29 PM, Sideways Skullfinger wrote:

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SysStaff::distanceUp() and ::distanceDown() gone for good?

sideways
Predicting future SVG Export issues is not an easy task.  The recent spate of fixes were simply regression tests that had not taken place until recently.  If there is a set of SVG test cases, these newly fixed issues should be added.  If you have other features that you want to make sure function the way you expect in SVG, you should test those cases, and even add them to the existing set of regression tests.

If you want assistance from me in developing test cases, let me know.  If you want to make any my recent changes to any other branch, please do so.  Less than 10 lines of code changed across the 3 combined PRs.  That is the positive side of the recent issues reported, and a positive reflection on the health of the code (I'm feeling some small need to defend my work here).  The real issue is having and executing a complete set of test cases.  Anything else is purely speculative.

--
James

On 4/22/2016 11:32 AM, Marc Sabatella wrote:
Well, I was thinking of https://musescore.org/en/node/105436https://musescore.org/en/node/105471, and https://musescore.org/en/node/107081, which I guess are already fixed for 2.0.4 branch.  I guess maybe the last of these is the same as https://musescore.org/en/node/107126, but if not, then that one.  Together, these tell me there were big enough changes in SVG export that I won't be surprised to see other regressions serious enough to want to fix for any eventual 2.0.4, and given that the existing code presumably doesn't really work in master because so much has changed, it might be worth it to hold onto a 2.0.3 build environment for now in anticipation of further fixes needing to be applied.

On Fri, Apr 22, 2016 at 11:17 AM Lasconic <[hidden email]> wrote:
Which issues are you talking about in particular?

lasconic

2016-04-22 19:09 GMT+02:00 Marc Sabatella <[hidden email]>:
I seems like many of these issues are serious enough to want fixed on the 2.0.4 branch, so maybe focus first on building, developing, and testinh there? Then worry about restructuring for master later? Unless werner or lasconic advise otherwise...
On Fri, Apr 22, 2016 at 10:26 AM Sideways Skullfinger <[hidden email]> wrote:
Thank you for the detailed information.  I'll be changing my code today.  Like Michael Corleone, "Just when I thought I was out... they pull me back in."  I was very comfortable in my Qt 5.4 environment, but exactly 1 day before the master switched to 5.6, I was notified of some issues with code I had modified.  To enable a simple (barely any code changed) PR the next day, I had to upgrade.  Now I'm stuck, forced to use the latest master code now, not at some future time of my choosing.

I'm not complaining, just explaining my personal sense of urgency about this question (and possibly future questions).  I don't mind contributing to QA testing and making unplanned changes - that's just how it is some times in the Open Source world.  It's part of the price you pay for "free" software.

Thanks again for the clearly stated response.

--
James


On 4/22/2016 3:07 AM, Werner Schweer wrote:
_distanceUp and _distanceDown are gone and will not come back. The staff distance is now calculated in System->layout2()
and the system distance in Score->collectPage() which calls layoutPage().
The distance between systems can be determined by looking at system->pos().y().
SysStaff->_distanceUp/Down was used to collect information from layouting  elements like fret symbols etc. which might increase
the staff distance. This is replaced by a more generic algorithm which uses the Shape of staves to determine the minimum distance without
any collision.

Am 21.04.2016 um 20:43 schrieb Sideways Skullfinger:
I submitted this question to the list 5 days ago, and there has been no response, so I wanted to try again.  Is there a replacement for SysStaff::distanceUp() and distanceDown() in the latest master code?

Thanks,

Sideways

On 4/16/2016 12:29 PM, Sideways Skullfinger wrote:

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z


_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SysStaff::distanceUp() and ::distanceDown() gone for good?

lasconic
Administrator
All the SVG fixes I'm aware of are already merged in the 2.0.4 branch.

We don't have any SVG tests suite, but it's a good idea, we could modify the vtests to render SVG too (or instead of PNG?)
(If you don't know what the vtests are, check the vtests directory and http://vtest.musescore.org/index.html)

Diffing SVG is easier so we could even use them for regression testing.

lasconic



2016-04-22 19:47 GMT+02:00 Sideways Skullfinger <[hidden email]>:
Predicting future SVG Export issues is not an easy task.  The recent spate of fixes were simply regression tests that had not taken place until recently.  If there is a set of SVG test cases, these newly fixed issues should be added.  If you have other features that you want to make sure function the way you expect in SVG, you should test those cases, and even add them to the existing set of regression tests.

If you want assistance from me in developing test cases, let me know.  If you want to make any my recent changes to any other branch, please do so.  Less than 10 lines of code changed across the 3 combined PRs.  That is the positive side of the recent issues reported, and a positive reflection on the health of the code (I'm feeling some small need to defend my work here).  The real issue is having and executing a complete set of test cases.  Anything else is purely speculative.

--
James


On 4/22/2016 11:32 AM, Marc Sabatella wrote:
Well, I was thinking of https://musescore.org/en/node/105436https://musescore.org/en/node/105471, and https://musescore.org/en/node/107081, which I guess are already fixed for 2.0.4 branch.  I guess maybe the last of these is the same as https://musescore.org/en/node/107126, but if not, then that one.  Together, these tell me there were big enough changes in SVG export that I won't be surprised to see other regressions serious enough to want to fix for any eventual 2.0.4, and given that the existing code presumably doesn't really work in master because so much has changed, it might be worth it to hold onto a 2.0.3 build environment for now in anticipation of further fixes needing to be applied.

On Fri, Apr 22, 2016 at 11:17 AM Lasconic <[hidden email][hidden email]> wrote:
Which issues are you talking about in particular?

lasconic

2016-04-22 19:09 GMT+02:00 Marc Sabatella <[hidden email]>:
I seems like many of these issues are serious enough to want fixed on the 2.0.4 branch, so maybe focus first on building, developing, and testinh there? Then worry about restructuring for master later? Unless werner or lasconic advise otherwise...
On Fri, Apr 22, 2016 at 10:26 AM Sideways Skullfinger <[hidden email][hidden email]> wrote:
Thank you for the detailed information.  I'll be changing my code today.  Like Michael Corleone, "Just when I thought I was out... they pull me back in."  I was very comfortable in my Qt 5.4 environment, but exactly 1 day before the master switched to 5.6, I was notified of some issues with code I had modified.  To enable a simple (barely any code changed) PR the next day, I had to upgrade.  Now I'm stuck, forced to use the latest master code now, not at some future time of my choosing.

I'm not complaining, just explaining my personal sense of urgency about this question (and possibly future questions).  I don't mind contributing to QA testing and making unplanned changes - that's just how it is some times in the Open Source world.  It's part of the price you pay for "free" software.

Thanks again for the clearly stated response.

--
James


On 4/22/2016 3:07 AM, Werner Schweer wrote:
_distanceUp and _distanceDown are gone and will not come back. The staff distance is now calculated in System->layout2()
and the system distance in Score->collectPage() which calls layoutPage().
The distance between systems can be determined by looking at system->pos().y().
SysStaff->_distanceUp/Down was used to collect information from layouting  elements like fret symbols etc. which might increase
the staff distance. This is replaced by a more generic algorithm which uses the Shape of staves to determine the minimum distance without
any collision.

Am 21.04.2016 um 20:43 schrieb Sideways Skullfinger:
I submitted this question to the list 5 days ago, and there has been no response, so I wanted to try again.  Is there a replacement for SysStaff::distanceUp() and distanceDown() in the latest master code?

Thanks,

Sideways

On 4/16/2016 12:29 PM, Sideways Skullfinger wrote:

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z


_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SysStaff::distanceUp() and ::distanceDown() gone for good?

Marc Sabatella
Sorry if my response came off as critical - it was not meant that way.  You wrote of your "personal sense of urgency about this question (and possibly future questions)", which I interpreted to mean, you were anticipating needing to make further changes in the near future and realized you wouldn't be able to do so on the master.  Given that there were some regressions found by users already, I assumed you were contemplating the likelihood of needing to do further fixes in the near future and were trying to prepare for that possibility.  So I was trying to support you in preparing for that possibilty.  If you aren't feeling any particularly high likelihood of further regressions, then I'd say, there is probably not any real urgency - you can worry about adapting your code to work on the master at your leisure.

Marc



On Fri, Apr 22, 2016 at 12:02 PM Lasconic <[hidden email]> wrote:
All the SVG fixes I'm aware of are already merged in the 2.0.4 branch.

We don't have any SVG tests suite, but it's a good idea, we could modify the vtests to render SVG too (or instead of PNG?)
(If you don't know what the vtests are, check the vtests directory and http://vtest.musescore.org/index.html)

Diffing SVG is easier so we could even use them for regression testing.

lasconic



2016-04-22 19:47 GMT+02:00 Sideways Skullfinger <[hidden email]>:
Predicting future SVG Export issues is not an easy task.  The recent spate of fixes were simply regression tests that had not taken place until recently.  If there is a set of SVG test cases, these newly fixed issues should be added.  If you have other features that you want to make sure function the way you expect in SVG, you should test those cases, and even add them to the existing set of regression tests.

If you want assistance from me in developing test cases, let me know.  If you want to make any my recent changes to any other branch, please do so.  Less than 10 lines of code changed across the 3 combined PRs.  That is the positive side of the recent issues reported, and a positive reflection on the health of the code (I'm feeling some small need to defend my work here).  The real issue is having and executing a complete set of test cases.  Anything else is purely speculative.

--
James


On 4/22/2016 11:32 AM, Marc Sabatella wrote:
Well, I was thinking of https://musescore.org/en/node/105436https://musescore.org/en/node/105471, and https://musescore.org/en/node/107081, which I guess are already fixed for 2.0.4 branch.  I guess maybe the last of these is the same as https://musescore.org/en/node/107126, but if not, then that one.  Together, these tell me there were big enough changes in SVG export that I won't be surprised to see other regressions serious enough to want to fix for any eventual 2.0.4, and given that the existing code presumably doesn't really work in master because so much has changed, it might be worth it to hold onto a 2.0.3 build environment for now in anticipation of further fixes needing to be applied.

On Fri, Apr 22, 2016 at 11:17 AM Lasconic <[hidden email][hidden email]> wrote:
Which issues are you talking about in particular?

lasconic

2016-04-22 19:09 GMT+02:00 Marc Sabatella <[hidden email]>:
I seems like many of these issues are serious enough to want fixed on the 2.0.4 branch, so maybe focus first on building, developing, and testinh there? Then worry about restructuring for master later? Unless werner or lasconic advise otherwise...
On Fri, Apr 22, 2016 at 10:26 AM Sideways Skullfinger <[hidden email][hidden email]> wrote:
Thank you for the detailed information.  I'll be changing my code today.  Like Michael Corleone, "Just when I thought I was out... they pull me back in."  I was very comfortable in my Qt 5.4 environment, but exactly 1 day before the master switched to 5.6, I was notified of some issues with code I had modified.  To enable a simple (barely any code changed) PR the next day, I had to upgrade.  Now I'm stuck, forced to use the latest master code now, not at some future time of my choosing.

I'm not complaining, just explaining my personal sense of urgency about this question (and possibly future questions).  I don't mind contributing to QA testing and making unplanned changes - that's just how it is some times in the Open Source world.  It's part of the price you pay for "free" software.

Thanks again for the clearly stated response.

--
James


On 4/22/2016 3:07 AM, Werner Schweer wrote:
_distanceUp and _distanceDown are gone and will not come back. The staff distance is now calculated in System->layout2()
and the system distance in Score->collectPage() which calls layoutPage().
The distance between systems can be determined by looking at system->pos().y().
SysStaff->_distanceUp/Down was used to collect information from layouting  elements like fret symbols etc. which might increase
the staff distance. This is replaced by a more generic algorithm which uses the Shape of staves to determine the minimum distance without
any collision.

Am 21.04.2016 um 20:43 schrieb Sideways Skullfinger:
I submitted this question to the list 5 days ago, and there has been no response, so I wanted to try again.  Is there a replacement for SysStaff::distanceUp() and distanceDown() in the latest master code?

Thanks,

Sideways

On 4/16/2016 12:29 PM, Sideways Skullfinger wrote:

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z


_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SysStaff::distanceUp() and ::distanceDown() gone for good?

sideways
The personal sense of urgency is my own code, not merged with the master, that suddenly didn't compile because of the upgrades I was forced to make due to circumstances beyond my control.  Absolutely nothing to do with the current master itself.

I have an SVG animation project that uses MuseScore SVG Export.  I have a couple of thousand lines of code I've added in my own branch in order to create various types of animatable scores, including drum-machine-style graphical representations.  That's the cause of my personal sense of urgency.

--
Sideways

On 4/22/2016 12:14 PM, Marc Sabatella wrote:
Sorry if my response came off as critical - it was not meant that way.  You wrote of your "personal sense of urgency about this question (and possibly future questions)", which I interpreted to mean, you were anticipating needing to make further changes in the near future and realized you wouldn't be able to do so on the master.  Given that there were some regressions found by users already, I assumed you were contemplating the likelihood of needing to do further fixes in the near future and were trying to prepare for that possibility.  So I was trying to support you in preparing for that possibilty.  If you aren't feeling any particularly high likelihood of further regressions, then I'd say, there is probably not any real urgency - you can worry about adapting your code to work on the master at your leisure.

Marc



On Fri, Apr 22, 2016 at 12:02 PM Lasconic <[hidden email]> wrote:
All the SVG fixes I'm aware of are already merged in the 2.0.4 branch.

We don't have any SVG tests suite, but it's a good idea, we could modify the vtests to render SVG too (or instead of PNG?)
(If you don't know what the vtests are, check the vtests directory and http://vtest.musescore.org/index.html)

Diffing SVG is easier so we could even use them for regression testing.

lasconic



2016-04-22 19:47 GMT+02:00 Sideways Skullfinger <[hidden email]>:
Predicting future SVG Export issues is not an easy task.  The recent spate of fixes were simply regression tests that had not taken place until recently.  If there is a set of SVG test cases, these newly fixed issues should be added.  If you have other features that you want to make sure function the way you expect in SVG, you should test those cases, and even add them to the existing set of regression tests.

If you want assistance from me in developing test cases, let me know.  If you want to make any my recent changes to any other branch, please do so.  Less than 10 lines of code changed across the 3 combined PRs.  That is the positive side of the recent issues reported, and a positive reflection on the health of the code (I'm feeling some small need to defend my work here).  The real issue is having and executing a complete set of test cases.  Anything else is purely speculative.

--
James


On 4/22/2016 11:32 AM, Marc Sabatella wrote:
Well, I was thinking of https://musescore.org/en/node/105436https://musescore.org/en/node/105471, and https://musescore.org/en/node/107081, which I guess are already fixed for 2.0.4 branch.  I guess maybe the last of these is the same as https://musescore.org/en/node/107126, but if not, then that one.  Together, these tell me there were big enough changes in SVG export that I won't be surprised to see other regressions serious enough to want to fix for any eventual 2.0.4, and given that the existing code presumably doesn't really work in master because so much has changed, it might be worth it to hold onto a 2.0.3 build environment for now in anticipation of further fixes needing to be applied.

On Fri, Apr 22, 2016 at 11:17 AM Lasconic <[hidden email]> wrote:
Which issues are you talking about in particular?

lasconic

2016-04-22 19:09 GMT+02:00 Marc Sabatella <[hidden email]>:
I seems like many of these issues are serious enough to want fixed on the 2.0.4 branch, so maybe focus first on building, developing, and testinh there? Then worry about restructuring for master later? Unless werner or lasconic advise otherwise...
On Fri, Apr 22, 2016 at 10:26 AM Sideways Skullfinger <[hidden email]> wrote:
Thank you for the detailed information.  I'll be changing my code today.  Like Michael Corleone, "Just when I thought I was out... they pull me back in."  I was very comfortable in my Qt 5.4 environment, but exactly 1 day before the master switched to 5.6, I was notified of some issues with code I had modified.  To enable a simple (barely any code changed) PR the next day, I had to upgrade.  Now I'm stuck, forced to use the latest master code now, not at some future time of my choosing.

I'm not complaining, just explaining my personal sense of urgency about this question (and possibly future questions).  I don't mind contributing to QA testing and making unplanned changes - that's just how it is some times in the Open Source world.  It's part of the price you pay for "free" software.

Thanks again for the clearly stated response.

--
James


On 4/22/2016 3:07 AM, Werner Schweer wrote:
_distanceUp and _distanceDown are gone and will not come back. The staff distance is now calculated in System->layout2()
and the system distance in Score->collectPage() which calls layoutPage().
The distance between systems can be determined by looking at system->pos().y().
SysStaff->_distanceUp/Down was used to collect information from layouting  elements like fret symbols etc. which might increase
the staff distance. This is replaced by a more generic algorithm which uses the Shape of staves to determine the minimum distance without
any collision.

Am 21.04.2016 um 20:43 schrieb Sideways Skullfinger:
I submitted this question to the list 5 days ago, and there has been no response, so I wanted to try again.  Is there a replacement for SysStaff::distanceUp() and distanceDown() in the latest master code?

Thanks,

Sideways

On 4/16/2016 12:29 PM, Sideways Skullfinger wrote:

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SysStaff::distanceUp() and ::distanceDown() gone for good?

sideways
In reply to this post by lasconic
Using text diff for SVG test cases is an excellent idea.  Fully automatable if you're into that.  That's a lot of stuff out there in the vtests directory.  If the PNG tests cover all the different types of graphical elements then that's a good start.  I think the main thing to check is that all types of graphics that MuseScore generates are handled properly.  Every type of articulation, every type of line, etc.

--
Sideways

On 4/22/2016 12:01 PM, Lasconic wrote:
All the SVG fixes I'm aware of are already merged in the 2.0.4 branch.

We don't have any SVG tests suite, but it's a good idea, we could modify the vtests to render SVG too (or instead of PNG?)
(If you don't know what the vtests are, check the vtests directory and http://vtest.musescore.org/index.html)

Diffing SVG is easier so we could even use them for regression testing.

lasconic



2016-04-22 19:47 GMT+02:00 Sideways Skullfinger <[hidden email]>:
Predicting future SVG Export issues is not an easy task.  The recent spate of fixes were simply regression tests that had not taken place until recently.  If there is a set of SVG test cases, these newly fixed issues should be added.  If you have other features that you want to make sure function the way you expect in SVG, you should test those cases, and even add them to the existing set of regression tests.

If you want assistance from me in developing test cases, let me know.  If you want to make any my recent changes to any other branch, please do so.  Less than 10 lines of code changed across the 3 combined PRs.  That is the positive side of the recent issues reported, and a positive reflection on the health of the code (I'm feeling some small need to defend my work here).  The real issue is having and executing a complete set of test cases.  Anything else is purely speculative.

--
James


On 4/22/2016 11:32 AM, Marc Sabatella wrote:
Well, I was thinking of https://musescore.org/en/node/105436https://musescore.org/en/node/105471, and https://musescore.org/en/node/107081, which I guess are already fixed for 2.0.4 branch.  I guess maybe the last of these is the same as https://musescore.org/en/node/107126, but if not, then that one.  Together, these tell me there were big enough changes in SVG export that I won't be surprised to see other regressions serious enough to want to fix for any eventual 2.0.4, and given that the existing code presumably doesn't really work in master because so much has changed, it might be worth it to hold onto a 2.0.3 build environment for now in anticipation of further fixes needing to be applied.

On Fri, Apr 22, 2016 at 11:17 AM Lasconic <[hidden email]> wrote:
Which issues are you talking about in particular?

lasconic

2016-04-22 19:09 GMT+02:00 Marc Sabatella <[hidden email]>:
I seems like many of these issues are serious enough to want fixed on the 2.0.4 branch, so maybe focus first on building, developing, and testinh there? Then worry about restructuring for master later? Unless werner or lasconic advise otherwise...
On Fri, Apr 22, 2016 at 10:26 AM Sideways Skullfinger <[hidden email]> wrote:
Thank you for the detailed information.  I'll be changing my code today.  Like Michael Corleone, "Just when I thought I was out... they pull me back in."  I was very comfortable in my Qt 5.4 environment, but exactly 1 day before the master switched to 5.6, I was notified of some issues with code I had modified.  To enable a simple (barely any code changed) PR the next day, I had to upgrade.  Now I'm stuck, forced to use the latest master code now, not at some future time of my choosing.

I'm not complaining, just explaining my personal sense of urgency about this question (and possibly future questions).  I don't mind contributing to QA testing and making unplanned changes - that's just how it is some times in the Open Source world.  It's part of the price you pay for "free" software.

Thanks again for the clearly stated response.

--
James


On 4/22/2016 3:07 AM, Werner Schweer wrote:
_distanceUp and _distanceDown are gone and will not come back. The staff distance is now calculated in System->layout2()
and the system distance in Score->collectPage() which calls layoutPage().
The distance between systems can be determined by looking at system->pos().y().
SysStaff->_distanceUp/Down was used to collect information from layouting  elements like fret symbols etc. which might increase
the staff distance. This is replaced by a more generic algorithm which uses the Shape of staves to determine the minimum distance without
any collision.

Am 21.04.2016 um 20:43 schrieb Sideways Skullfinger:
I submitted this question to the list 5 days ago, and there has been no response, so I wanted to try again.  Is there a replacement for SysStaff::distanceUp() and distanceDown() in the latest master code?

Thanks,

Sideways

On 4/16/2016 12:29 PM, Sideways Skullfinger wrote:

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Height of last visible staff on a page?

sideways
This is a follow-up to my recent post about SysStaff:distanceUp/Down().  The relevant parts of that email thread are all below.

I am now doing the following to get each staff's height (I was already collecting the visibleStaves vector, now I'm using it to solve this requirement too):

EXISTING CODE TO COLLECT VISIBLE STAVES
    QVector<int> visibleStaves;
    visibleStaves.resize(score->nstaves());
    int nVisible = 0;
    for (int i = 0; i < score->nstaves(); i++)
        visibleStaves[i] = score->staff(i)->invisible() ? -1 : nVisible++;

NEW CODE TO GET STAFF TOP AND HEIGHT
        const System* s = page->systems().value(0);
        const qreal top = s->staff(idxStaff)->y();
        const int idxVisible = (*pVisibleStaves)[idxStaff];
        qreal bot = -1;
        if (idxVisible < nVisible - 1) {
            for (int i = idxStaff + 1; i < pVisibleStaves->size(); i++) {
                if ((*pVisibleStaves)[i] > 0) {
                    bot = s->staff(i)->y();
                    break;
                }
            }
        }
        if (bot < 0)
            bot = page->height() - page->bm();

height = bot - top;  It's SVG and the y-axis values increment top-to-bottom.  The new code is inside a separate sub-routine, outside the scope of the visibleStaves declaration, so it has a pointer to visibleStaves.

It seems to be working well so far, though it's more complex than I would like.  And using page->height() as the bottom of the last visible staff is not a real solution, it's simply something that poses no issues with for my specific SVG scores that use this code.  Otherwise, determining the bottom-most visible staff's height does not seem straightforward.  It would be nice to have a truly general-purpose solution to the question: What is the full height of the bottom-most visible staff on a page?

Is there a straightforward way in the current master to answer that?

--
Sideways

On 4/22/2016 3:07 AM, Werner Schweer wrote:
_distanceUp and _distanceDown are gone and will not come back. The staff distance is now calculated in System->layout2()
and the system distance in Score->collectPage() which calls layoutPage().
The distance between systems can be determined by looking at system->pos().y().
SysStaff->_distanceUp/Down was used to collect information from layouting  elements like fret symbols etc. which might increase
the staff distance. This is replaced by a more generic algorithm which uses the Shape of staves to determine the minimum distance without
any collision.

Am 21.04.2016 um 20:43 schrieb Sideways Skullfinger:
I submitted this question to the list 5 days ago, and there has been no response, so I wanted to try again.  Is there a replacement for SysStaff::distanceUp() and distanceDown() in the latest master code?

Thanks,

Sideways

On 4/16/2016 12:29 PM, Sideways Skullfinger wrote:

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways




------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Height of last visible staff on a page?

wschweer9
Maybe you should have a look at layout.cpp: Score::collectPage() . It calculates the visible height of systems to determine how many will
fit on a page.

Am 24.04.2016 um 19:28 schrieb Sideways Skullfinger:
This is a follow-up to my recent post about SysStaff:distanceUp/Down().  The relevant parts of that email thread are all below.

I am now doing the following to get each staff's height (I was already collecting the visibleStaves vector, now I'm using it to solve this requirement too):

EXISTING CODE TO COLLECT VISIBLE STAVES
    QVector<int> visibleStaves;
    visibleStaves.resize(score->nstaves());
    int nVisible = 0;
    for (int i = 0; i < score->nstaves(); i++)
        visibleStaves[i] = score->staff(i)->invisible() ? -1 : nVisible++;

NEW CODE TO GET STAFF TOP AND HEIGHT
        const System* s = page->systems().value(0);
        const qreal top = s->staff(idxStaff)->y();
        const int idxVisible = (*pVisibleStaves)[idxStaff];
        qreal bot = -1;
        if (idxVisible < nVisible - 1) {
            for (int i = idxStaff + 1; i < pVisibleStaves->size(); i++) {
                if ((*pVisibleStaves)[i] > 0) {
                    bot = s->staff(i)->y();
                    break;
                }
            }
        }
        if (bot < 0)
            bot = page->height() - page->bm();

height = bot - top;  It's SVG and the y-axis values increment top-to-bottom.  The new code is inside a separate sub-routine, outside the scope of the visibleStaves declaration, so it has a pointer to visibleStaves.

It seems to be working well so far, though it's more complex than I would like.  And using page->height() as the bottom of the last visible staff is not a real solution, it's simply something that poses no issues with for my specific SVG scores that use this code.  Otherwise, determining the bottom-most visible staff's height does not seem straightforward.  It would be nice to have a truly general-purpose solution to the question: What is the full height of the bottom-most visible staff on a page?

Is there a straightforward way in the current master to answer that?

--
Sideways

On 4/22/2016 3:07 AM, Werner Schweer wrote:
_distanceUp and _distanceDown are gone and will not come back. The staff distance is now calculated in System->layout2()
and the system distance in Score->collectPage() which calls layoutPage().
The distance between systems can be determined by looking at system->pos().y().
SysStaff->_distanceUp/Down was used to collect information from layouting  elements like fret symbols etc. which might increase
the staff distance. This is replaced by a more generic algorithm which uses the Shape of staves to determine the minimum distance without
any collision.

Am 21.04.2016 um 20:43 schrieb Sideways Skullfinger:
I submitted this question to the list 5 days ago, and there has been no response, so I wanted to try again.  Is there a replacement for SysStaff::distanceUp() and distanceDown() in the latest master code?

Thanks,

Sideways

On 4/16/2016 12:29 PM, Sideways Skullfinger wrote:

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways





------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z


_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Height of last visible staff on a page?

sideways
I just looked at collectPage(), and like Measure::layout2(), I wouldn't exactly call it straightforward :-)  For me, right now, it's not worth entangling my code with a bunch of copying/pasting from either of those two functions.  But it's good to know where to look in case I really do need to answer the question with precision.  The scores that pass through this code of mine are all a single page that scrolls horizontally, like continuous view or a horizontal piano roll.  The pages must be precisely sized anyway, and there are no footers or margins.

Thanks for the info.

--
Sideways

On 4/25/2016 12:58 AM, Werner Schweer wrote:
Maybe you should have a look at layout.cpp: Score::collectPage() . It calculates the visible height of systems to determine how many will
fit on a page.

Am 24.04.2016 um 19:28 schrieb Sideways Skullfinger:
This is a follow-up to my recent post about SysStaff:distanceUp/Down().  The relevant parts of that email thread are all below.

I am now doing the following to get each staff's height (I was already collecting the visibleStaves vector, now I'm using it to solve this requirement too):

EXISTING CODE TO COLLECT VISIBLE STAVES
    QVector<int> visibleStaves;
    visibleStaves.resize(score->nstaves());
    int nVisible = 0;
    for (int i = 0; i < score->nstaves(); i++)
        visibleStaves[i] = score->staff(i)->invisible() ? -1 : nVisible++;

NEW CODE TO GET STAFF TOP AND HEIGHT
        const System* s = page->systems().value(0);
        const qreal top = s->staff(idxStaff)->y();
        const int idxVisible = (*pVisibleStaves)[idxStaff];
        qreal bot = -1;
        if (idxVisible < nVisible - 1) {
            for (int i = idxStaff + 1; i < pVisibleStaves->size(); i++) {
                if ((*pVisibleStaves)[i] > 0) {
                    bot = s->staff(i)->y();
                    break;
                }
            }
        }
        if (bot < 0)
            bot = page->height() - page->bm();

height = bot - top;  It's SVG and the y-axis values increment top-to-bottom.  The new code is inside a separate sub-routine, outside the scope of the visibleStaves declaration, so it has a pointer to visibleStaves.

It seems to be working well so far, though it's more complex than I would like.  And using page->height() as the bottom of the last visible staff is not a real solution, it's simply something that poses no issues with for my specific SVG scores that use this code.  Otherwise, determining the bottom-most visible staff's height does not seem straightforward.  It would be nice to have a truly general-purpose solution to the question: What is the full height of the bottom-most visible staff on a page?

Is there a straightforward way in the current master to answer that?

--
Sideways

On 4/22/2016 3:07 AM, Werner Schweer wrote:
_distanceUp and _distanceDown are gone and will not come back. The staff distance is now calculated in System->layout2()
and the system distance in Score->collectPage() which calls layoutPage().
The distance between systems can be determined by looking at system->pos().y().
SysStaff->_distanceUp/Down was used to collect information from layouting  elements like fret symbols etc. which might increase
the staff distance. This is replaced by a more generic algorithm which uses the Shape of staves to determine the minimum distance without
any collision.

Am 21.04.2016 um 20:43 schrieb Sideways Skullfinger:
I submitted this question to the list 5 days ago, and there has been no response, so I wanted to try again.  Is there a replacement for SysStaff::distanceUp() and distanceDown() in the latest master code?

Thanks,

Sideways

On 4/16/2016 12:29 PM, Sideways Skullfinger wrote:

2.0.3 source code here:
https://github.com/musescore/MuseScore/blob/2.0.3/libmscore/system.h#L48

The 2.0.3 class SysStaff looks like this:

class SysStaff {
      QRectF _bbox;           ///< Bbox of StaffLines.
      qreal _yOff;            ///< offset of top staff line within bbox
      qreal _distanceUp;      ///< distance to previous staff
      qreal _distanceDown;    ///< distance to next staff
      bool _show;             ///< derived from Staff or false if empty 
...

The current master has removed these variables and commented-out lines where the public properties for these variables are called, sometimes with a "TODO" in the comment.

I use SysStaff::distanceDown() and SysStaff::distanceUp() in my code, and now I have no substitute for it. What is the plan here? How should I be determining the distance between staves?

I posted this same thing on the musescore forums here: https://musescore.org/en/node/106501

Thanks,

Sideways


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

mtests, vtests, PNG and SVG

sideways
In reply to this post by lasconic
On 4/22/2016 12:01 PM, Lasconic wrote:
> We don't have any SVG tests suite, but it's a good idea, we could
> modify the vtests to render SVG too (or instead of PNG?)
> (If you don't know what the vtests are, check the vtests directory and
> http://vtest.musescore.org/index.html)
>
> Diffing SVG is easier so we could even use them for regression testing.
I now understand this a bit better, and want to understand it fully in
order to make it happen.  I assume the goal would be to add SVG exports
to the mtests, and leave the PNG vtests around, at least for now.  But I
know very little about how all this is set up.

I now know that the automated testing is setup in the mtests folder.  I
am assuming that the vtest files are generated automatically in mtests
somewhere, and I would need to duplicate that or add an SVG export of
the same scores.  Correct?

Then there is the automated diff process and reporting on differences
encountered.  Is there an existing way that this is done in MuseScore?

Those are my questions for now, I'm sure I'll have more as I get into it...

--
Sideways


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mtests, vtests, PNG and SVG

Marc Sabatella
vtests themselves are all created manually - the source files and the reference graphics. The tests are run via the "gen" script in the vtest folder - that's what actually generates the tests files and diffs them against the reference.  Go to vtest and type ./gen (you might need to configure some things first so the script uses the right version of MuseScore) and you'll see the tests being run; at the end an HTML file is generated that you can inspect manually.

On Tue, Apr 26, 2016 at 1:36 PM Sideways Skullfinger <[hidden email]> wrote:
On 4/22/2016 12:01 PM, Lasconic wrote:
> We don't have any SVG tests suite, but it's a good idea, we could
> modify the vtests to render SVG too (or instead of PNG?)
> (If you don't know what the vtests are, check the vtests directory and
> http://vtest.musescore.org/index.html)
>
> Diffing SVG is easier so we could even use them for regression testing.
I now understand this a bit better, and want to understand it fully in
order to make it happen.  I assume the goal would be to add SVG exports
to the mtests, and leave the PNG vtests around, at least for now.  But I
know very little about how all this is set up.

I now know that the automated testing is setup in the mtests folder.  I
am assuming that the vtest files are generated automatically in mtests
somewhere, and I would need to duplicate that or add an SVG export of
the same scores.  Correct?

Then there is the automated diff process and reporting on differences
encountered.  Is there an existing way that this is done in MuseScore?

Those are my questions for now, I'm sure I'll have more as I get into it...

--
Sideways


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mtests, vtests, PNG and SVG

sideways
So is the goal here simply to duplicate the vtests using SVG?  Or is there additional automation can be applied to the existing process?  If you're already automating the diff reporting, what more does SVG actually offer you?  Yes, it would test both the PNG and SVG export processes, but relative to automation: I don't see the difference between running a diff between two PNG files vs. two text files.  Am I missing something?

If it's just duplicating the existing vtests to use SVG, that shouldn't be too hard.

--
Sideways

On 4/26/2016 2:06 PM, Marc Sabatella wrote:
vtests themselves are all created manually - the source files and the reference graphics. The tests are run via the "gen" script in the vtest folder - that's what actually generates the tests files and diffs them against the reference.  Go to vtest and type ./gen (you might need to configure some things first so the script uses the right version of MuseScore) and you'll see the tests being run; at the end an HTML file is generated that you can inspect manually.

On Tue, Apr 26, 2016 at 1:36 PM Sideways Skullfinger <[hidden email]> wrote:
On 4/22/2016 12:01 PM, Lasconic wrote:
> We don't have any SVG tests suite, but it's a good idea, we could
> modify the vtests to render SVG too (or instead of PNG?)
> (If you don't know what the vtests are, check the vtests directory and
> http://vtest.musescore.org/index.html)
>
> Diffing SVG is easier so we could even use them for regression testing.
I now understand this a bit better, and want to understand it fully in
order to make it happen.  I assume the goal would be to add SVG exports
to the mtests, and leave the PNG vtests around, at least for now.  But I
know very little about how all this is set up.

I now know that the automated testing is setup in the mtests folder.  I
am assuming that the vtest files are generated automatically in mtests
somewhere, and I would need to duplicate that or add an SVG export of
the same scores.  Correct?

Then there is the automated diff process and reporting on differences
encountered.  Is there an existing way that this is done in MuseScore?

Those are my questions for now, I'm sure I'll have more as I get into it...

--
Sideways


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mtests, vtests, PNG and SVG

lasconic
Administrator
So in my previous comment, I was wondering if it would make sense to add SVG or replace PNGs by SVGs in the mtest.
I thought that it would solve a recurring problem: pngs rendered on different platforms looks different, and so when we "diff" them pixel by pixels we don't get blank files but some pixels are different. So the vtests are currently not automated, we need to check them from time to time and see if there is a change. We don't have any automated "red flag".

My hope was that diffing SVG (and so XML) would avoid this problem and so we could automate the diff and raise a red flag if we find a regression in the layout/drawing algorithm. I'm not sure if it's true or not and if it's not, then we need to solve the root cause and find why different OS gives different rendering...

lasconic

2016-04-26 22:17 GMT+02:00 Sideways Skullfinger <[hidden email]>:
So is the goal here simply to duplicate the vtests using SVG?  Or is there additional automation can be applied to the existing process?  If you're already automating the diff reporting, what more does SVG actually offer you?  Yes, it would test both the PNG and SVG export processes, but relative to automation: I don't see the difference between running a diff between two PNG files vs. two text files.  Am I missing something?

If it's just duplicating the existing vtests to use SVG, that shouldn't be too hard.

--
Sideways

On 4/26/2016 2:06 PM, Marc Sabatella wrote:
vtests themselves are all created manually - the source files and the reference graphics. The tests are run via the "gen" script in the vtest folder - that's what actually generates the tests files and diffs them against the reference.  Go to vtest and type ./gen (you might need to configure some things first so the script uses the right version of MuseScore) and you'll see the tests being run; at the end an HTML file is generated that you can inspect manually.

On Tue, Apr 26, 2016 at 1:36 PM Sideways Skullfinger <[hidden email]> wrote:
On 4/22/2016 12:01 PM, Lasconic wrote:
> We don't have any SVG tests suite, but it's a good idea, we could
> modify the vtests to render SVG too (or instead of PNG?)
> (If you don't know what the vtests are, check the vtests directory and
> http://vtest.musescore.org/index.html)
>
> Diffing SVG is easier so we could even use them for regression testing.
I now understand this a bit better, and want to understand it fully in
order to make it happen.  I assume the goal would be to add SVG exports
to the mtests, and leave the PNG vtests around, at least for now.  But I
know very little about how all this is set up.

I now know that the automated testing is setup in the mtests folder.  I
am assuming that the vtest files are generated automatically in mtests
somewhere, and I would need to duplicate that or add an SVG export of
the same scores.  Correct?

Then there is the automated diff process and reporting on differences
encountered.  Is there an existing way that this is done in MuseScore?

Those are my questions for now, I'm sure I'll have more as I get into it...

--
Sideways


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mtests, vtests, PNG and SVG

sideways
Unless someone knows the answer to your question, we'll have to generate some SVG files and see how they look across diff platforms.  For me, that requires other people with the other platforms installed, as I am only running Windows 7.  Are there particular PNGs that are problematic and that should be tested first across platforms?

--
James

On 4/27/2016 2:50 AM, Lasconic wrote:
So in my previous comment, I was wondering if it would make sense to add SVG or replace PNGs by SVGs in the mtest.
I thought that it would solve a recurring problem: pngs rendered on different platforms looks different, and so when we "diff" them pixel by pixels we don't get blank files but some pixels are different. So the vtests are currently not automated, we need to check them from time to time and see if there is a change. We don't have any automated "red flag".

My hope was that diffing SVG (and so XML) would avoid this problem and so we could automate the diff and raise a red flag if we find a regression in the layout/drawing algorithm. I'm not sure if it's true or not and if it's not, then we need to solve the root cause and find why different OS gives different rendering...

lasconic

2016-04-26 22:17 GMT+02:00 Sideways Skullfinger <[hidden email]>:
So is the goal here simply to duplicate the vtests using SVG?  Or is there additional automation can be applied to the existing process?  If you're already automating the diff reporting, what more does SVG actually offer you?  Yes, it would test both the PNG and SVG export processes, but relative to automation: I don't see the difference between running a diff between two PNG files vs. two text files.  Am I missing something?

If it's just duplicating the existing vtests to use SVG, that shouldn't be too hard.

--
Sideways

On 4/26/2016 2:06 PM, Marc Sabatella wrote:
vtests themselves are all created manually - the source files and the reference graphics. The tests are run via the "gen" script in the vtest folder - that's what actually generates the tests files and diffs them against the reference.  Go to vtest and type ./gen (you might need to configure some things first so the script uses the right version of MuseScore) and you'll see the tests being run; at the end an HTML file is generated that you can inspect manually.

On Tue, Apr 26, 2016 at 1:36 PM Sideways Skullfinger <[hidden email]> wrote:
On 4/22/2016 12:01 PM, Lasconic wrote:
> We don't have any SVG tests suite, but it's a good idea, we could
> modify the vtests to render SVG too (or instead of PNG?)
> (If you don't know what the vtests are, check the vtests directory and
> http://vtest.musescore.org/index.html)
>
> Diffing SVG is easier so we could even use them for regression testing.
I now understand this a bit better, and want to understand it fully in
order to make it happen.  I assume the goal would be to add SVG exports
to the mtests, and leave the PNG vtests around, at least for now.  But I
know very little about how all this is set up.

I now know that the automated testing is setup in the mtests folder.  I
am assuming that the vtest files are generated automatically in mtests
somewhere, and I would need to duplicate that or add an SVG export of
the same scores.  Correct?

Then there is the automated diff process and reporting on differences
encountered.  Is there an existing way that this is done in MuseScore?

Those are my questions for now, I'm sure I'll have more as I get into it...

--
Sideways


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer




------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z


_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
12
Loading...