This .next() vs .next thing is bothering more than it should.
OK, the principle is that we should use a property if it just returns a
more or less static value, and a function if it does something to the
object.
cursor.next() is legit, because it changes the the internal state of the
cursor (ie, moves it on to the next whatever.
measure.next is actually static, it is a pointer to the next measure,
and calling it does not change the internals.
BUT: cursor.segment() is currently implemented as a function, but it
doesn't change anything, just returns the currently selected segment.
Using Q_PROPERTY gives more control over what it is exposed as, so I can
return wrapped elements without changing the internal name of the functions.
Using Q_INVOKABLE means I'm stuck with the actual name of the function,
meaning I have to export a different function name if the existing one
does not do what I want.
Then there is the way we've changed the namespace for Q_ENUM, but that
is another issue.
I'm probably overthinking it, but a few guiding principles now may make
life easier for all the the future.
Robbie
On 11/10/2017 3:37 PM, David Bolton wrote:
Robbie,
Speaking to question 5, I appreciate what you are doing. Plugins are a
great way for people to jump into making MuseScore better who have
trouble with C++. Plugins also allow development without having to
rebuild the whole source code which lowers lots of barriers. Plugins
are great for anyone that wants to develop a small feature that is
unique. Sometimes there are features that you want only for a specific
project.
David
On 10/10/2017 8:41 PM, Robbie Matthews wrote:
I've been working steadily on the 3.0 plugins, and have reached a
point where I'd like some feedback.
Discussion to date: https://musescore.org/en/node/255081
PR to date: https://github.com/musescore/MuseScore/pull/3303
Among other things, I posed the question, do we prefer functions or
read only properties?
Specifically, should it be *measure.next* or *measure.next()* ?
jojo-schmidt expressed a preference for functions if they do
something, and properties if they don't.
I have a slight preference for that approach myself, so started
exposing the .next as a Q_INVOKABLE (ie, .next()) rather than a read
only property.
Score represents a problem, in that a) Score is a QObject, so is
exposed directly, as distinct from most other elements, which are
wrappered.
Score::firstMeasure() is already used internally, and I can't just
Q_INVOKE it because it returns an unwrapped Element*
So it is currently exposed as a read only property, which breaks the
pattern I'm trying to estabish.
Question 1: Was the decision to keep Score a QObject critical to
development?
Question 2: Should I in any case create a ScoreW to wrap Score and
register that with QML? (Starting to think so...)
Question 3: Do others have any strong opinions on .next vs .next() ?
Question 4: Is there anything actually documenting what the various
properties do? (for get and set)?
Question 5: Am I wasting my time?
Any input appreciated.
Robbie
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
