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 <lasco...@gmail.com
<mailto:lasco...@gmail.com>> 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
<sidew...@sidewaysskullfinger.com
<mailto:sidew...@sidewaysskullfinger.com>>:
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 <lasco...@gmail.com
<mailto:lasco...@gmail.com>> wrote:
Which issues are you talking about in particular?
lasconic
2016-04-22 19:09 GMT+02:00 Marc Sabatella
<m...@outsideshore.com <mailto:m...@outsideshore.com>>:
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
<sidew...@sidewaysskullfinger.com
<mailto:sidew...@sidewaysskullfinger.com>> 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
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer
