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