How to do GUI stuff with the new QML plugin framework?
How to display an alertbox, i.e. what is the replacment for QMessageBox()
How to use a file selector, i.e. what is the replacement for QFileDialog()
How to load and use a .ui file, amongst others, what are the replacem,ents for QUiLoader() and QFile()
Comments
As you know, the QML plugin framework is under development, in the nightlies, very early and can/should change anytime
1/ UI files : UI files define a UI for Qt. Qt is no more accessible in QML. That was the whole point for dropping the Qt bindings. So you can't load UI files anymore.
2/ Alertbox: no idea yet.
3/ FileDialog; There is an example here: http://doc.qt.nokia.com/4.7-snapshot/gettingstartedqml.html#integrating… but it needs some C++ code to work.
I made a basic UI for the ABC import building in QML (https://gist.github.com/3116128). It's a simple UI but it was hard and cumbersome since the basic elements are quite low level (there is no Button for example). In the future, the Qt people are working on a set oh high level widget for desktop http://labs.qt.nokia.com/2012/06/06/desktop-components-for-qt-5/
I tried the HTML route as well (https://gist.github.com/3116132). It's slow to display, but it's very fast to code, just HTML/CSS. i18n might be an issue.
In reply to As you know, the QML plugin by [DELETED] 5
Yes, I am aware about the framework's volatility ;-), I hope though that it get extended rather than dropped or changed drastically.
And thanks for those hints. Pitty that UI files won't work anymore, that was a nice and easy way to implement GUIs
Maybe we'd need MuseScore to provide some kind of qml lib for generic stuff like alert boxes and file selectors.
Qt 5's release date would probably to late for MuseScore 2.0, wouldn't it?
I like the HTML route, putting up a form in html could be nearly as easy as the UI stuff.
You mean i18n might be an issue for the HTML route? Or with QML in general?
I don't see the former, if qsTr works, it'd do for html strings too. And the latter is said to work on the QML docs, I just don't understand why it does not for me. Hence my suspicion that there is some extra infrastructure missing in MuseScore yet.
In reply to Yes, I am aware about the by Jojo-Schmitz
HTML strings can be files of course. It was just a quick hack to see if it works. I like the HTML route as well but translating full HTML pages is not a good practise since it's the pain when the markup change.
In reply to HTML strings can be files of by [DELETED] 5
Ah, I see, yes you're right of course.
In reply to As you know, the QML plugin by [DELETED] 5
As lasconic noted above, making UI with QML is currently rather frustrating (added to the lack of debugging tools, this makes me wonder if this is really the way to go, at least now, but this is another topic...).
Now, I understand the plugin framework is under development; QML itself is under development; and both can remain rather volatile for any amount of time.
However, we need some practical way to develop (or port) a fair number of plugins, at least for testing the framework and spot missing parts.
So, I wonder if it would make any sense to add to the plugin framework a few "common dialogue boxes" as methods of the global MuseScore object.
Even only an alert box with title and text and a getOpenFileName (for instance, as a wrap around QFileDialog:: getOpenFileName() static method) would be quite useful.
They may become obsolete sooner or later, but could help working with plugins in the meantime.
M.
In reply to As lasconic noted above, by Miwarre
That's what I meant with "Maybe we'd need MuseScore to provide some kind of qml lib for generic stuff like alert boxes and file selectors." ;-)
In reply to That's what I meant with by Jojo-Schmitz
For me it would be a lack of time. If we have to replicate any new feature we want in the plugin framework by mapping a part of Qt, we will end up with the same problem as previously, with the added pain that the binding will be human generated.
So let's try to do a perennial and collaborative work with other and bigger projects. QML Desktop component seems to go this way. Another approach would be to discard the QML approach to another one, maybe more HTML oriented.
In reply to For me it would be a lack of by [DELETED] 5
Is those basic things, an alert box and a file selector, really asking too much?
In reply to Is those basic things, an by Jojo-Schmitz
Of course it's not... It's just on the principle... You'll quickly find out that you need more and so we will add more and the framework will grow organically. When any of these features will be in, plugin developers will use them and it will be another pain when we will have to delete them. I would prefer to avoid that and find a nice way in the first place.
Btw, it's not about the UI only. I needed to write a file when creating the ABC plugin, so I did exactly that. I added a FileIO module in the plugin framework. It's more C++ in the core and it's a non standard API to write files from QML. It will be a pain to maintain, and the documentation is nowhere. If we investigate a full HTML way, QtWebkit should be able to deal with W3C File API
In reply to Of course it's not... It's by [DELETED] 5
Most of lasconic points make perfect sense. However, I find a little hard putting them together.
1) It is true and clear that these additions would be hacks, quick-and-dirty tricks. However, everything in the plugin framework is still experimental, anything can go away at any moment and all the 2.0 plugins written now might require any sort of changes before 2.0 release. Once either QML or whatever else provides the missing blocks, these tricky additions will be removed and, if some pugin used it, "tant pis": we know it may happen.
2) To discover what is needed by the current framework (or even if the current framework IS the right way to go), some fairly complex plugins (more complex than notenames) need to be written (or at least attempted to be written (sorry for my English!)). If someone has to spend hours for creating the same alert box in several plugins, probabilities (s)he will engage in the task decrease... A little help would, hmmm..., help!
3) What if QML widget components do not deliver or only partially or not in time for our ver 2.0? Release a plugin framework where GUI's are a pain in the neck to create? And even this would not cover access to the 'big world out there' (I/O or other OS resources/services).
So, I would say: if we are decently confident QML is the right way, some temporary hacks may help gaining experience for understanding, completing and polishing the framework (even if this means periodically fixing (even re-writing) written plugins; as I said above, at this stage we know this may happen).
OTOH, if we (whatever "we" may mean in this context) are not sure, then it is probably better to evaluate alternatives as soon as possible. In which case, my very personal inclination would be to avoid declarative stuff (as HTML also is): plugins are almost always procedural, declarative languages will always fall short under some respect or another.
Yours confused,
M.
I support the Musescore appoach to reducing their need to support loads of code.
However, Please tell me I am wrong in my understanding that development has already taken place in which there is no current plan to support a GUI interface to plugins!
I have 2 plugins released and 2 more available in a couple of weeks. All use GUIs developed from QtCreator and could not work without such a user interface.
Im an (aged) programmer interested in music and hoping to use my skills to give something back to the community.
Without a GUI interface plugins have a limited scope.
In reply to I support the Musescore by johnhenry
I can only speak for myself, but I am fairly confident that nobody is planning to release a version 2.0 with a plugin framework not supporting GUI's.
OTOH, it is true that the current implementation makes GUI design slow and cumbersome (they CAN be done, but in a sub-optimal way).
Whether this is a structural limitation of the current base (QML) or not, whether it will be solved by QML itself, whether it makes sense to wait for this to happen, if it makes sense to hack something temporary in the meantime, if there are suitable working alternatives and so on: these are all points under discussion. But I think that a working, usable and reasonably complete plugin framework is the goal everyone is aiming at.
Thanks,
M.
In reply to I can only speak for myself, by Miwarre
I might be a minority opinion on this, but even if creating dialogs and so forth is somewhat more cumbersome than in previous releases, I would consider this a fair price to pay for a more robust / complete framework with respect to the actual music data structures. Ideally, of course, some sort of library of simple dialogs would be most appreciated in addition.
.. but I just stumbled on PyQt which provides a bridge between Python and seems to provide all (or most) of the Qt bindings (GUI and Qt Designer support included), taking the burden of maintaining them away from the MuseScore devs. Worth a glance, perhaps?
M.