[Development] Suggestion on QML portability

[Alan Alpert]

On Sun, 15 Jul 2012 23:30:13 ext Robin Burchell wrote:
> Hi,
> 
> Again, looking at MeeGo's components in QtQuick2 world, I notice that
> some painful changes required for porting from QML1 to QML2 are in
> renaming methods, or rearranging things a bit. From the documentation:
> 
>   Property and Method Changes
> 
>     ListView's highlightMoveSpeed and highlightResizeSpeed properties
> have been renamed to highlightMoveVelocity and
> highlightResizeVelocity, respectively.
> TextInput and TextEdit's openSoftwareInputPanel() and
> closeSoftwareInputPanel() methods have been removed. Use the new
> Qt.inputMethod property and call Qt.inputMethod.show()
> Qt.inputMethod.hide() to show and hide the virtual keyboard.
> 
> As I'm looking at a single codebase here, and in the future, I'd like
> to ideally have a single branch which can work with QML1 or QML2, I'm
> going to be looking at some pretty horrible hacks to work around these
> renames/reshuffles, which leaves me wondering what the actual point of
> them is.

The theory is that you're not trying to maintain a single codebase for both 
QML1 and QML2. Perhaps we just gave up because the significant behavioural 
differences guaranteed that it would be a major pain no matter what. But I 
don't understand why MeeGo components need to have a unified branch, surely the 
first version using Qt5 uses QML2, the previous version uses QML1, and they 
have to be on separate branches anyways?

> Is there really that much pain in having a deprecated
> closeSoftwareInputPanel method so I don't have to resort to somehow
> preprocessing the QML, for instance?

Yes, there is that much pain. At least that's my interpretation from the 
example of Qt3Support. When do deprecated methods get discarded, if not across 
major versions?

> (and to those people who say that preprocessing as a feature of QML
> isn't required, I'd point you to this as being yet another example of
> why that's not the case in the real world)

The real world is using QML without C++? As I recall, the main reason 
preprocessing as a feature of QML isn't required is because QML/C++ 
applications already have excellent preprocessing features on the C++ side 
which you can use. I'm not saying it wouldn't be helpful in QML if done 
properly, but it's not strictly required and so it's worth waiting until a 
good solution is designed.

--
Alan Alpert