Developer handbook page about plugin framework

• Feb 12, 2010 - 19:02

I started a new developer handbook page to explain the plugin framework to newcomers and gather interesting information. This thread can be used to discuss the content of this page.

Comments

• Feb 12, 2010 - 21:54

I agree with thomas. While writing the couple of plugins I made so far, I felt like dealing with black magic; luckily I have access to a full Qt dev enviro and mostly used it as a documentation, but this is going to change!

I think one of the first things to add in that page is an improved version of the README.scripts text file.

Thanks!

M.

Reply

• Feb 21, 2010 - 06:04

The legal section cites a source that dates to 2008 and references Qt 4.0. In January 2009 Nokia announces that Qt 4.5 would be released under GNU LGPL.

I assume this means that plugin authors have the choice of whether to release under GPL or LGPL?

Reply

• Feb 21, 2010 - 08:48

I'm not a lawyer :) My understanding is that the plugin inherits the licence of the bindings it uses.
Qt > 4.5 is indeed LGPL, MuseScore is GPL since the beginning. The Qt bindings shipped with MuseScore on Mac or WIndows could be GPL if we decide so I guess. There is no licence included for the moment in the SVN. so I assume it's GPL.
On linux, I'm not sure if the Qt script bindings are packaged with MuseScore or as a dependance.

If a plugin uses only LGPL Qt bindings, it might be released under LGPL or GPL but if it used the MuseScore bindings or the GPL Qt bindings it has to be GPL.

So in short, I guess the legal section is quite right.

Reply

• Feb 24, 2010 - 17:53

Would I break any site policy by being bold and starting adding to that handbook page other pages documenting the individual scripting objects (Chord, Cursor, Score, etc)? I can make a (mild) promise to keep it reasonably up-to-date.

M.

Reply

• Feb 25, 2010 - 06:43

My plan was to replace this page with a version of the README.scripts file.
Maybe a page per Object is indeed better and so a new book, maybe "Plugin developper handbook" could be a solution?
You are very welcome to take the job! The pages will be on wiki mode, so I will help keeping up to date.

Reply

• Feb 27, 2010 - 23:28

I think a book just means it can have sub-pages (or "child pages") which helps group pages into one "book". Sub-pages in a book can also have their own sub-pages (or "child pages") which is useful if you want to organize by chapters within a book.

Reply

• Feb 28, 2010 - 10:15

Thomas created a book at http://musescore.org/plugin-development/plugin-development
Maybe we can remove one "plugin-development" from the URL?

As far as I understand this is the fronpage of the book and we can add children pages to it.
I tried to add a page to describe the Score object. See the bottom, there is a link to http://musescore.org/handbook/score
That's a weird url. Could it be change to include the name of the book?

I tried to use html syntax the best I can but the page is far from a doxygen generated documentation. Any idea to improve this?

It's better to find a good way to write the documentation for one object before adding pages for every one of them. Maybe a wiki is not the best way ?

Reply

• Feb 28, 2010 - 11:31

I fixed the url issue.

One tip: for new book child pages, take 'language neutral' since we don't want these book pages to be translated. If you take 'English', not only will they presented for translation to the translators, but also the url will be /handbook/....

Reply

• Mar 3, 2010 - 23:31

I made some changes with an attempt of a new format for method descriptions (if it is crap, the wiki mechanism allows to revert to the original version, doesn't it?).

Basically, I built on the Qt own documentation format (smaller header for function prototypes, parameters in italic, and so on), adding bold for method names. I'm uncertain about language keywords: true and undefined, or true and undefined?

M.

Reply

• Mar 4, 2010 - 13:23

With the available tags there are very few alternatives (= none?).

To my eye, H4 is not so large and would stand out enough from the regular text; it is probably H3 which is too similar. I tried to change H3 to H2 but H2 is not allowed.
Reducing H4 to H5 changes nothing as H4 and H5 are defined in the same way.
Changing the colour of the method prototypes is not possible as no font or style tags are allowed (correctly, IMHO).

Any change to the style sheet would affect the whole site and it is probably unwise. The only changes with as little side effects as possible would be either to add an H2 style larger than H3 or an H5 style, maybe not smaller, but in some way different from H4 (different font, different colour, ...), but this is something for the site gurus.

Cannot we settle for the layout as it is now?

M.

P.S.: Back to the Score page contents: if hasLyrics and hasHarmonies really need no parentheses, should not they be filed among properties rather than among methods?
P.P.S.: Thee is a reason for not sorting properties and methods in alphabetical order?

Reply

• Mar 4, 2010 - 23:29

I do not know enough of JavaScript and its history to tell, so I leave the issue to the code gurus (as a C programmer, I have difficulties with the very concept of a read-only variable...).

Coming back to the plugin documentation: if this is the best we can do for now, can we go on with the other pages? There are 10 pages in all (9 objects and 1 for the global properties), should we dramatically change our minds it is not a disaster to go back and change them.

If everybody agrees, I could go on and add the other pages (but I did not find a way to create them and add them to the main page!).

M.

Reply

• Mar 5, 2010 - 17:11

When I saw the video, I thought to be very stupid but, coming back to the "Plugin Development" page, I saw no "Add child page" link at the bottom, only "Printer-friendly version" and "Subscribe". And, yes, I'm logged in.

Is some kind of authorization needed?

Thanks,

M.

Reply

• Mar 5, 2010 - 05:04

It is normal to have read-only properties in JavaScript. Take a look at the Math object for example. So the read only aspect isn't a deciding factor.

In my mind JavaScript methods usually do something (manipulate or calculate/analyze), JavaScript properties just store information related to an object. hasHarmonies and hasLyrics seem to be simple analysis's of the score so probably they should be methods. Perhaps they are comparable to the Global JavaScript methods isFinite() and isNaN()

Reply

• Mar 5, 2010 - 07:56

Ok so let's decide.
I will majke the change for these 2.
hasLyrics --> method
hasHarmonies --> method

What about?
pages? For the moment, property
staves ? For the moment, property
measures ? For the moment, property
parts? For the moment, property
keysig? For the moment, property
duration? For the moment, property

Reply

Do you still have an unanswered question? Please log in first to post your question.