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
<[email protected]
<mailto:[email protected]>>:
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]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
