Extending existing QML components

[gemmell]

We have a class which is derived from QTextEdit and overrides all manner of things (e.g. createMimeDataFromSelection()), and we have recently come up with a use case to move such a thing into a view which would be great to do in QML. However after 30 mins looking at the source it is fairly evident that the QQuickTextEdit is not really meant to be extended. Given that you can't embed a QWidget into a QtQuick2 interface, are we stuck doing it in QtQuick1?

It seems rather short sighted to think that the standard implementation of the textedit will suit everyone, but the only alternative at the moment is to completely reimplement the entire thing yourself?! Or have I missed something?

[wysota]

A possible solution would be to refactor your widget into two separate components -- one would be the original QTextEdit and the other would be all your modifications encapsulated into a separate class with signals, slots and properties. Then you can reuse this component with Qt Quick's text edit item by providing a QML bridge between this C++ component and the item itself.

e.g.

// MyTextEdit.qml
import QtQuick 2.0
import TextEditEngine 1.0
 
TextEdit {
  TextEditEngine { id: engine; }
 
  onSelectedTextChanged: engine.createMimeDataFromSelection(selectedText)
}

// MyTextEdit.qml
import QtQuick 2.0
import TextEditEngine 1.0

TextEdit {
  TextEditEngine { id: engine; }
  
  onSelectedTextChanged: engine.createMimeDataFromSelection(selectedText)
}

To copy to clipboard, switch view to plain text mode 

[gemmell]

Ah thats an interesting idea. Of course you don't want to create the mime data every time you change the selection, and you also have to then somehow hook into the cut event and get it to call through to your engine to put it into the clipboard. Looks like you'd have to intercept the ctrl-x key directly - can we even do that? Not in a default TextEdit by the look of it... putting a textedit in a keys component also doesn't sound like the right thing to do... little help?

[wysota]

and you also have to then somehow hook into the cut event and get it to call through to your engine to put it into the clipboard. Looks like you'd have to intercept the ctrl-x key directly - can we even do that?

Crtl+X (or whatever the shortcut is on a particular platform) is only one of the ways of invoking cut functionality. If that's the only thing you are after then using the Keys attached property should work just fine. On a more global scale one would probably want some kind of shortcut mechanism to handle situations such as these. Unfortunately QtQuick is not really tailored towards complex UI operations such as those that often happen on desktop so if you want them, it is important to come up with a framework that you can reuse instead of implementing the same things over and over. In particular it could be an option to implement an attached property (similar to the "Keys" property) that would handle keyboard shortcuts on existing objects.

[gemmell]

At least if I stick with QtQuick1 I'll be able to drop in my extended QTextEdit and have it work pretty much straight up.... might give that a shot.

[wysota]

At least if I stick with QtQuick1 I'll be able to drop in my extended QTextEdit and have it work pretty much straight up.... might give that a shot.

If you do that, don't expect good efficiency.

[gemmell]

... Unfortunately QtQuick is not really tailored towards complex UI operations such as those that often happen on desktop so if you want them, it is important to come up with a framework that you can reuse instead of implementing the same things over and over. In particular it could be an option to implement an attached property (similar to the "Keys" property) that would handle keyboard shortcuts on existing objects.

Right, that answers a few questions for me as to whether it's suitable. I gather it's totally doable but that you require a fair bit of expertise to design frameworks and bend QML to your will. Given that I'm a QML noob I think I'd struggle to develop such frameworks at this point in time.

If you do that, don't expect good efficiency.

But no worse than regular QWidget based one using the Qt Animation Framework right? Anyways, it's going to be small, displaying 50 or so items, shouldn't be a problem for any technology.

[wysota]

But no worse than regular QWidget based one using the Qt Animation Framework right?

Much worse because you have to go through a widget proxy.

Anyways, it's going to be small, displaying 50 or so items, shouldn't be a problem for any technology.

Well... don't be so sure Widgets on graphics view (which is what you're going to use with QtQuick1) are sort of a nasty hack. If you start moving things around, they'll get really slow.

First question you should ask yourself is whether you really need (and can make use of) QtQuick (be it 1 or 2). So why do you think you want/need QtQuick?

[gemmell]

Much worse because you have to go through a widget proxy.


Well... don't be so sure Widgets on graphics view (which is what you're going to use with QtQuick1) are sort of a nasty hack. If you start moving things around, they'll get really slow.

First question you should ask yourself is whether you really need (and can make use of) QtQuick (be it 1 or 2). So why do you think you want/need QtQuick?

Yes, I think that first question is turning into a "no I don't need it". I originally thought to do it in quick since we have a QAbstractItemProxyModel based model which is a list and rather than stuffing around with delegates and widget's for index's thought I'd give QML a try since it's apparently easy to do this sort of stuff..... but thank you for your feedback, I'm going to do it with QWidget's - as a side benefit I know wtf I'm doing there so it'll get finished quicker.

In terms of the system wide shortcut stuff you mentioned, I came across this:
http://kdeblog.mageprojects.com/2012...out-qshortcut/
Which essentially allows you to setup you keypresses (e.g. ctrl+c/ctrl+v) and setup reactions in the elements.

In another post he goes on to add a clipboard object that you can use from QML:
http://kdeblog.mageprojects.com/2012...apper-for-qml/
Sounds like the ground work is already being done.

[wysota]

Yes, I think that first question is turning into a "no I don't need it". I originally thought to do it in quick since we have a QAbstractItemProxyModel based model which is a list and rather than stuffing around with delegates and widget's for index's thought I'd give QML a try since it's apparently easy to do this sort of stuff..... but thank you for your feedback, I'm going to do it with QWidget's - as a side benefit I know wtf I'm doing there so it'll get finished quicker.

As a semi-solution I'd suggest using QScrollArea. Not that elegant but let's you arrange widgets quickly.

In terms of the system wide shortcut stuff you mentioned, I came across this:
http://kdeblog.mageprojects.com/2012...out-qshortcut/
Which essentially allows you to setup you keypresses (e.g. ctrl+c/ctrl+v) and setup reactions in the elements.

Oh, I didn't mean system-wide (or actually application-wide) shortcuts. What you want is highly context-dependent.

In another post he goes on to add a clipboard object that you can use from QML

You don't really need that because you have a C++ component that does all the work (at least I assume that's what your createMimeSomethingSomething does). If you have working C++ logic, there is no point in rewriting it in QML.

And personally I don't like those approaches from the blog you quoted. 10 shortcuts mean 10 event filters on the application object, that's not a good design.