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/105436,
https://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 <[email protected]
<mailto:[email protected]>> wrote:
Which issues are you talking about in particular?
lasconic
2016-04-22 19:09 GMT+02:00 Marc Sabatella <[email protected]
<mailto:[email protected]>>:
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
<[email protected]
<mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
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
[email protected]
<mailto:[email protected]>
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
[email protected]
<mailto:[email protected]>
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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
