Code working in Plugin Creator but not directly as plug-in

• Jul 28, 2015 - 00:18

While attempting to use in a dialogue plug-in of mines a combo box dynamically filled, I discovered that a procedure which works correctly if run from the Plugin Creator, no longer works if the plug-in is run directly.

Context: all versions from 2.0.0 to current github master code, run under Linux Mint 17.1.

Sample code: this is a minimal plug-in (of the dialogue type) which just displays a combo box and fills it with strings at run time (just some boring "Name 0", "Name 1", ... strings).

The combo box is correctly filled if the plug-in is run from the Plugin Creator, but remains empty if the plug-in is run directly from the "Plugins" menu.

Note that, in both cases, the dynamically created strings are correctly inserted in the ListModel attached to the CombBox (as the few diagnostic logs at the end show), but this seems not to affect the combo box itself.

1) Anybody can confirm (or falsify) this under other platforms?

2) Can anybody explain the difference?

Thanks!

import QtQuick 2.0
import QtQuick.Controls 1.2
import QtQuick.Layouts 1.1
import MuseScore 1.0

MuseScore
{
version:		"2.0"
description:	qsTr("To test ComboBox working")
menuPath:		"Plugins.Test Combo"
pluginType:		"dialog"

//
//	The UI
//

id:	window
property	int	wdgMargin:	8
property	int	wndWidth:	300
property	int	wndHeight:	200
width:		wndWidth;
height:		wndHeight;

RowLayout
{
	id:				rowSelect
	anchors.top:		window.top
	anchors.left:		window.left
	anchors.right:		window.right
	anchors.margins:	window.wdgMargin
	spacing:			window.wdgMargin
	Label
	{
		id:				label
		text:				qsTr("Combo:")
		Layout.alignment:	Qt.AlignVCenter
	}
	ComboBox
	{
		id:				combo
		Layout.fillWidth:	true
		model: ListModel
		{
			id: listModel
		}
	}
}

//
// Components and Methods
//

onRun:		{ init(); }

//-------------------------------------------------------------------
//	init()
//	initializes the combo box. Called by main object's onRun().
//-------------------------------------------------------------------

function init()
{
	var	i;
	var	names	= [];

	// fill the combo box
//	combo.textRole = "text";			// does anything at all?
	for (i = 0; i < 5; i++)
		names[i] = { "text": "Name " + i };
	listModel.append(names);
// some diagnostics
console.log("Combo text role: " + combo.textRole);
console.log("Num. of names in list model: " + listModel.count);
var model = combo.model;
console.log("Model: " + model);
for (i = 0; i < combo.count; i++)
	console.log("Name " + i + ": " + model.get(i).text);
}

}											// plugin end

Comments

Can't help you with a radically different platform but the problem exists in ubuntu 15.04, MS build 7f58e9f (compiled a couple of hours ago). As you state, works fine in Creator but the list items it the drop-down in the combo are missing when one runs it directly.

In reply to by underquark

Thanks anyway! Ubuntu and Linux Mint are rather near relatives indeed (Mint can even use Ubuntu repositories), but your tests at least show that it is not a glitch specific to my own system.

Now the question remains: why?

I could not find in the code anything relevant the Plugin Creator does which is not done by the 'direct' plug-in launcher, but to all evidence the Plugin Creator does something additional and useful (or even required!) during the plug-in (or during its own) initialisation.

Thanks again,

M.

I just wanted to add, that this problem only occurs for pluginType "dialog".
If you comment that line out and create a modal Window item, everything works fine.

In reply to by heuchi

Nice catch! Would you mind adding a few lines of code: I think to have got rid of all examples of modal windows.

What I am after at the moment is a port of my temperament plug-in to 2.x and I vaguely remember the modal Window way got nowhere because of some limitation of it (this plug-in is rather complex with multiple dialogue boxes and more than one hundred of controls cumulatively).

Still, I would like to understand why the same code works if launched in one way and not in the other.

Thanks!

M.

In reply to by Miwarre

Here's what I added:

To be able to use Window:

import QtQuick.Window 2.2

Add a Window item at the beginning:

//pluginType:           "dialog"

//
//      The UI
//

Window {
    id: window
    visible: true
    modality: Qt.ApplicationModal // behave like a dialog
    color: "lightgrey"


property        int     wdgMargin:      8
property        int     wndWidth:       300
property        int     wndHeight:      200
width:          wndWidth;
height:         wndHeight;

    // center on screen
    x: Screen.width / 2  - width / 2
    y: Screen.height / 2 - height / 2

...

You need a closing } at the end for Window of course.

I attach the qml file.

You can also have a look at the batch converter plugin which uses a Window, a FileDialog and a Dialog item. So maybe using Dialog instead of Window (and setting modality) might even be more straight forward.
I had to do a type "dialog" version for Mac (branch mac), because FileDialog doesn't work otherwise (a know Qt bug in MacOs). It would certainly be interesting to know, why FileDialog actually works for pluginType "dialog"...

But using the "dialog" version on Linux had several problems (centering the window on screen, window would sometimes open in background...)

Attachment Size
ComboBoxTest.qml 1.8 KB

In reply to by heuchi

@heuchi: thank you for your reply and for the sample code.

I tried and with a Window object the combo box does work indeed.

Unfortunately, (some of?) the layout statements do not work any more and all the controls are stacked one above the other in a single row at the top of the window and some of them (TextArea, Rectangle) collapse into a 0-sized control.

Also, the Window object does not dynamically update the layout when its sizes change.

So, at first sight, the Window object seems too rudimentary for a complex dialogue box like the one I am trying to build.

As dynamically filled combo boxes do work correctly in dialogue boxes if the plug-in runs within the Plugin Creator, the framework can support this approach, so I still wonder why results are different if the plug-in is run directly from the menu.

EDIT: I had to change Qt.ApplicationModal into Qt.WindowModal, otherwise the plug-in window would take control and would no longer allow to operate on the score.

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