> Multi platform capability isn't as simple anymore: The inclusion of QML > components for different platforms make that the source code needs to be > changing to compile for MeeGo, Symbian, Linux, Windows or Mac platform every > single time. The current Qt4 is as simple as changing the target in QtCreator > and the application is compiled to the next OS without absolutely any change > in your code.
There is also exists a Meego C++ SDK framework for Meego based on the QWidget stack. (MeegoTouch) I could just as well use the existence of that as an argument against the C++ widget based stack. It is unfortunate that the SDK needs to expose specific UI elements that are platform specific. But I think this is a better solution than forcing every single mobile platform into a single API. That said, the basic API for Slider and Button is exactly the same in all the component sets. I honestly think Qt needs more platform specific components and widgets. Not less of them. We should enable cross platform development by default, but you should also have the _possibility_ of having a few platform specific components when you really need to give your app that little bit of extra polish. I think everyone developing end-user centric applications for Mac would agree to that. If you don't like the idea of having platform specific code in your application, you really don't have to. > The same code means just that, the same set of .cpp, .h and .ui files. No > need to link to different libraries or make changes in my .pro. I have to use > #ifdefs in the code to make the difference, but it is not a problem. I have a cross platform Qt Quick application. It consists of .cpp, .h, js and .qml files. You can still use #ifdefs in your code. You can use properties on the qml side to define different behavior on different platforms. This by itself is not an argument against Qt Quick. > I'm not expert in QML and I may be wrong in some comments, but instead of > fighting back it would be more proactive to be guided to real examples for > instance clarifying my doubts and possibly enforcing your point. I apologize that I sounded negative. There were a lot of claims and arguments flying in both directions and I think we all got a little bit carried away. I tried to stay out of this thread until someone started claiming that QML could not possibly look native and at the same time that we should not make any effort in ensuring that it could. My point is that we can make Qt Quick look every bit as native as QWidget for the traditional desktop platforms. So that by itself is also not an argument against it. You can look up the Loader and Component API for seeing how to Load or create QML components dynamically. > As mentioned in my last email and to conclude this thread, I'm giving a real > try to QML to develop a small and simple application using pure C++ so let's > see how it works. Thank you. I think that is a very good idea. There are a lot of good arguments against Qt Quick and I am sure you will find real issues with it but at least they should be based on facts and not assumptions. If you run into problems, let us know so we can address them. I would again like to stress that the widget stack is not going away in Qt 5 and as of this thread we also clarified that we will not force it on top of OpenGL. It will in fact stay there and be the correct and best solution for many project also in Qt 5. When it comes to desktop development, I want to make sure that people choose Qt Quick because they feel it benefits their project and not because they feel forced into using it. Anything else would be insane. Regards, Jens Bache-Wiig _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
