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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
