On Tuesday 08 May 2012 04:13:40 Alan Alpert wrote: > On Mon, 7 May 2012 07:44:56 ext André Pönitz wrote: > > On Mon, Apr 23, 2012 at 07:35:02AM +0000, lars.kn...@nokia.com wrote: > > > [...] And who says that 100% of the code has to be C++? > > > > Nobody reasonably wants that. But people like to have a choice, and > > different people will base their choice on different factors. > > > > > I bet you are also happily using Perl/python where it makes sense. .ui > > > files in Qt 4.x are XML, yet nobody complains about these. > > > > > > Qt is about finding pragmatic solutions to problems. Yes it comes from > > > a C++ heritage, but I don't see why we should limit ourselves to > > > purely C++ if we can create better solutions to the problem. > > > [...] No, you should be using QML. [...] > > > > A better language does not automatically translate into a better > > solution. The currently envisioned use of QML as a hybrid (at edit > > and(!) run time) severely impacts the choice of available tools > > to handle ordinary tasks like editing, debugging, profiling, and > > whatever else is typically needed to make an application fly. > > > > With old .ui this was not much of a problem because (a) one could > > not do much with it anyway i.e. could not get it wrong either, (b) it > > had no runtime implications, no need for mixed debugging/profiling > > (QUiLoader is not exactly popular), and (c) one could even opt for > > not using it at all. > > > > Now we suddenly have an easy to use, yet compulsory, Turing complete > > language with essentially no support from off-the-shelf tools. > > It's this "compulsory" part that I don't understand. The current situation > is that if you don't want to use QML you don't use it. I understand that > we're talking about transitioning to QML as the primary tool for UIs in > Qt5, but that's both merely 'primary', and also very in-progress (don't > make me copy in a boiler-plate "forward-looking statements" disclaimer ;) > ). So these accurate holes that people are pointing out are issues that > should be resolved over the Qt 5.x lifetime and only then, at the end of > the journey, is QML going to be the only viable option. > > Obviously I think QML is viable now, but I've thought that for years. Over > those years I've watched it progress from where I'd seriously suggest it > for 10% of applications to where I'd seriously suggest it for 60% of > applications. Once it grows to me thinking 100% of applications should use > it (I'll probably be the first one to think this, if not the only one ;)) > then we can talk about compulsory. I'd hope to reach that point around Qt > 5.2, maybe 5.3. > > > How are people supposed to handle that? Who is going to provide the > > QML enabled substitutes to the emacs-visual studio-xcode-valgrind > > -gdb-cdb-purify-doxygen-designer-whatever-tool-hotchpotch people are > > happily using? What happens to people who cannot or do not want to > > use substitutes? Who is going to support and maintain the substitutes? > > The Qt SDK already is starting to contain profiling and debugging tools for > QML. So there's where and how they'll be provided/maintained.
Nice to hear that there will be qt-related tools in sight. Still I'm used to develop with emacs for many years now. And I definitely do not want to be forced to use specific tools which imply new dependencies! Frank _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
