3

I have to reuse the Widget application in the Qml based application with latest Qt version (Qt 5.2). But as per most of the people its is very bad idea to do so.

Can someone explain, why it is bad idea?

Some of the code snippet,

*.h

class MyAppItem: public QQuickPaintedItem{
    Q_OBJECT
public:

    explicit MyAppItem(QQuickItem *parent = 0);
    void paint(QPainter *painter);
private:

    CMyAppWidget *bp;
};

class RouteBWExtensionPlugin: public QQmlExtensionPlugin
{
  Q_OBJECT
  Q_PLUGIN_METADATA(IID "org.qt-project.Qt.QQmlExtensionInterface")

public:

  /**
  * @brief                register the plugin
  * @param[in]  uri to be registered
  */
  void registerTypes(const char * uri);
};

*.cpp

MyAppItem::MyAppItem(QQuickItem *parent)
    : QQuickPaintedItem(parent)
{
    bp = new CMyAppWidget();
}

void MyAppItem::paint(QPainter *painter)
{
    bp->render(painter);
}

void RouteBWExtensionPlugin::registerTypes(const char * uri)
{
  qmlRegisterType<MyAppItem>(uri, 1, 0, "MyAppItem");
}

*.qml file 

import MyAppWidget 1.0
Item {
    width: 300
    height: 10
    anchors.right: parent
    MyAppItem {
        width: 94
        height: 240
        anchors.right: parent
        MouseArea{
            anchors.fill: parent
            onClicked: {
                console.log("[veo] onClicked - capture triggered")
            }
        }
    }
}
Swapnil
  • 1,424
  • 2
  • 19
  • 30
  • How are you planning on doing that? – Mitch Aug 05 '15 at 10:35
  • I have used the QQuickPaintedItem and QQmlExtensionPlugin class from new Qt version. – Swapnil Aug 05 '15 at 10:57
  • 1
    So... no widgets then? What am I missing here? :p That sounds like a very sensible way to do it, assuming that you just copied over the `QPainter` commands from your widget classes and no widgets-related stuff. – Mitch Aug 05 '15 at 11:01

2 Answers2

1

Because you do not want to add a dependency on 3d rendering when you don't need to. 3d rendering can cause massive amount of trouble, which you might be able to avoid in a Qt Widgets application without Qt Quick.

If you are planning to develop a Qt Quick application it is likely that at some point you need stuff from Qt Widgets. This applies for example when you need proper file dialogs, tray icons or just want to get native system colors which you have in a Qt Widgets QApplication but not in Qt Quick's QGuiApplication. So I'd argue against Micht's point Unnecessary dependency to Qt Widgets based on my own experience.

So for new Qt Quick applications using existing QWidgets I think this is a nice intermediate step.

Simon Warta
  • 10,850
  • 5
  • 40
  • 78
  • Good point about the system colours. I can't imagine the other stuff often being necessary for embedded or mobile. – Mitch Aug 06 '15 at 06:34
0

That's interesting, I didn't know that you could do that!

Here are some reasons that I can think of:

  1. Unnecessary memory overhead for storing and constructing each QWidget instance (this includes any signal/slot connections the widgets might make).
  2. Running through the QWidget::render() code path unnecessarily. I haven't looked into how complex this is, but it's something to consider.
  3. Unnecessary dependency to Qt Widgets.
  4. Loss of interaction (mouse, keyboard, touch, etc.), assuming that the widget had any in the first place.

These all assume that you don't need the widget dependency for other things. If you do need it elsewhere within the same application for some reason, it doesn't sound so crazy (feels weird writing this...). I'd actually be very interested in hearing reasons why this is a bad idea myself.

So, the question is, why can't you just move the painting commands out of the widget and directly into your QQuickPaintedItem::paint() implementation? Do you need widgets within your Qt Quick application for other things? If so, what?

Mitch
  • 23,716
  • 9
  • 83
  • 122