Is there design mode for Qt Creator?

SGaist

Then designer doesn't run any code.

What do you have in mind that should not get executed ?

mtrch

You can add special variable (or property) to your widget and set it in plugin's createWidget method:

QWidget *MyWidgetPlugin::createWidget(QWidget *parent)
{
    MyWidget*widget = new MyWidget(parent);
    widget->designMode = true; //or widget->setDesignMode(true);
    return widget;
}

Panoss

@mtrch said in Is there design mode for Qt Creator?:

You can add special variable (or property) to your widget and set it in plugin's createWidget method:
QWidget *MyWidgetPlugin::createWidget(QWidget *parent)
{
    MyWidget*widget = new MyWidget(parent);
    widget->designMode = true; //or widget->setDesignMode(true);
    return widget;
}

The code that I want not to be executed in design mode, is in the init of my class:

def __init__(self, parent=None):
    parent.refreshsignal.connect(self.refresh)

It's a connection with the widget's parent signal.(when executed in Qt Designer, causes an error, "The custom widget factory registered for widgets of class PyPGDataTextBox returned 0. The creation of a widget of the class '' failed.")
So this line:

MyWidget*widget = new MyWidget(parent);

executes the code in the init.
And after this, if I set the designMode=True, it's already too late, the init has been executed.

mrjj

Hi
In c++ you would add to the constructor to include the parameter
or create new constructor.

MyWidget*widget = new MyWidget(parent, IsDesignMode); // new param to constructor

I assume you can do the same in Pyt ?

def init(self, parent=None, IsDesign):

ps Python uber noob :)

Panoss

Yes it's almost identical in python, I tried this too, but the function createWidget() gets called in both cases:
when in design mode and
when in run mode
So the parameter designMode is always true!

mrjj

@Panoss
Hi
Oh ok.
Im not sure what will be easiest way of detecting Design mode.
Some use process id , some check if Designer interface can be initialized.

And you are sure that the error from
def init(self, parent=None):
parent.refreshsignal.connect(self.refresh)

is not coming from parent being NULL ( ehh None in python?)?

def init(self, parent=None):
if ( parent )
parent.refreshsignal.connect(self.refresh)

Panoss

I tried this:

            if parent is not None:
                parent.refreshsignal.connect(self.refresh)

And gives me the same error.
So, parent is not None (not null)but the error still exists.
It only goes away if I remove the connect command.

mrjj

@Panoss
Ok so not that.
What does parent.refreshsignal.connect do ?
( not seen same in c++)

It seems strange it could prevent the factory from working.

SGaist

Just one thing: your use of parent is a design error.

You are creating a tight coupling here and it's a bad idea. If the there's a need for a connection between a parent signal and a child slot, it's the responsibility of the parent object to create it. The child shouldn't know nor care about what its parent is or does.

Panoss

@mrjj said in Is there design mode for Qt Creator?:

What does parent.refreshsignal.connect do ?

Parent sends a signal named 'refreshsignal'.
To no one specific. Doesn't know who receives it and doesn't care.

But the ones who receive it, are those ones who have been 'connected' to this signal named 'refreshsignal'.

@SGaist said in Is there design mode for Qt Creator?:

Just one thing: your use of parent is a design error.

You are creating a tight coupling here and it's a bad idea. If the there's a need for a connection between a parent signal and a child slot, it's the responsibility of the parent object to create it. The child shouldn't know nor care about what its parent is or does.

But the parent doesn't know who are the receivers of the signal, and this simplifies the code A LOT!!
I thought that's the point of the signals.
I 'm new in python so maybe you 're right, I don't know.

SGaist

And the day you modify your parent object and the signal name changes, how many classes will you need to modify ?

The signal emitter shouldn't care who is connected to it as well as the slot owner shouldn't care who emitted the signal. However, there's a need for an object somewhere to manage the connections and like I wrote before, using the parent argument in the child object is the wrong way to do it.

You're thinking it simplifies the code a lot now, then you'll face maintenance nightmare later on. A good design doesn't mean the code will be simple, it means that the code will be easily understandable (as much as can be) and easy to maintain/update/improve.

Panoss

@SGaist said in Is there design mode for Qt Creator?:

And the day you modify your parent object and the signal name changes, how many classes will you need to modify ?

Two.

@SGaist said in Is there design mode for Qt Creator?:

The signal emitter shouldn't care who is connected to it as well as the slot owner shouldn't care who emitted the signal. However, there's a need for an object somewhere to manage the connections and like I wrote before, using the parent argument in the child object is the wrong way to do it.

You're thinking it simplifies the code a lot now, then you'll face maintenance nightmare later on. A good design doesn't mean the code will be simple, it means that the code will be easily understandable (as much as can be) and easy to maintain/update/improve.

Can you give me an example of how should I do it?

mtrch

HACK: You can check applicationName and organizationName properties of application than uses widget.
It will not work if somebody use custom Designer version with changed application/organization name. Also, it can be changed in future Designer versions.

bool TestWidget::isDesignMode()
{
    if((qApp->applicationName() == "Designer") &&
       ((qApp->organizationName() == "QtProject") || (qApp->organizationName() == "Trolltech")))
        return true;
    else
        return false;
}

Panoss

@mtrch said in Is there design mode for Qt Creator?:

HACK: You can check applicationName and organizationName properties of application than uses widget.
It will not work if somebody use custom Designer version with changed application/organization name. Also, it can be changed in future Designer versions.
bool TestWidget::isDesignMode()
{
    if((qApp->applicationName() == "Designer") &&
       ((qApp->organizationName() == "QtProject") || (qApp->organizationName() == "Trolltech")))
        return true;
    else
        return false;
}

I think this is very close to what I 'm looking for!!!
But what is qApp? is it QtGui.QApplication?

I tried this in the code that executes my class:

if __name__ == "__main__":

    import sys

    qApp = QtGui.QApplication(sys.argv)    
    widget = PyPGDataTextBox(qApp.applicationName())
    widget.show()
    sys.exit(qApp.exec_())

So my class inits with qApp.applicationName() as a parameter:

    def __init__(self, parent=None, appName=""):
        super(PyPGDataTextBox, self).__init__(parent)
        print("appName", appName, app)
        self.setPlainText("appName=" + appName)

But it prints nothing, appName is empty, either in design mode or in run mode.

Panoss

In my init I put:

appName=QtGui.qApp.applicationName()

And when it runs in the design mode, returns 'Designer' while in run mode returns 'python'
At last!! I found it!
Thank you all for helping!

SGaist

if __name__ == "__main__"":
    textBox = PyPGDataTextBox()
    otherWidget = PyOtherWidget()
    otherWidget.refreshsignal.connect(textBox.refresh)

There, it's clean, understandable and easy to maintain. No need for workarounds or hacks for designer to work. PyPGDataTextBox doesn't need to know anything about PyOtherWidget.

Panoss

I have some questions about this code.
The value of name attribute is set to 'main' when module is run as main program.
My widget, is never run as main program, so it's name attribute never gets a value of 'main'.
Right?

From my widget 's code, I removed totally the code at if name == "main": and the widget runs fine, in design and in run mode.

So, maybe I don't need at all the 'if name == "main":' part?

Edit: from what I understand, this code is in the module that gets executed.
In my case, I have main.py, pgdatatextbox.pyw and pgdataform.pyw (a container (and parent) widget for data controls like pgdatatextbox).
So this code is in my main.py, textbox is an instance of PyPGDataTextBox, and otherWidget is an instance of PyPGDataForm.
And main connects these two with the signal.
Do I get it right?

If so, then when I add a new instance of PyPGDataTextBox, I 'll have to write code for it , in order to connect to the signal,in the main.

With the 'QtGui.qApp.applicationName()', the new instance will connect (or not) by it's self, no extra code is needed anywhere.
Isn't it better?

SGaist

That was just an example in the case you'd be creating your widget as part of your application start in main. Feel free to adapt that to whatever class constructor/function fits.

Like I said before, your child class assume that the parent is of a certain type that provides that signal, which by design is a bad idea.

You are now implementing a hack just to work around the fact that this expectation fails when using Designer which should also trigger an alarm.

Where exactly are you creating PyPGDataTextBox instances ?
What is your need of refreshsignal ?

Panoss

@SGaist said in Is there design mode for Qt Creator?:

Where exactly are you creating PyPGDataTextBox instances ?
What is your need of refreshsignal ?

My PyPGDataTextBox instances are not created with code, they are created by Qt Designer.
When a PyPGDataTextBox recieves 'refreshsignal', it updates it 's text.

SGaist

Then put the connection code in the constructor of the widget where you put PyPGDataTextBox in.