On Monday, 2014-04-21, 14:15:16, André Pönitz wrote: > On Mon, Apr 21, 2014 at 10:53:01AM +0200, Kevin Krammer wrote: > > The language "barrier" between C++ and QML makes it easier to see where UI > > ends and program logic begins, leading to better abstraction between core > > application and its interface. > > The compulsory QML/JS - C++ language cut generates otherwise uneeded work > on the user side as well as significant tooling (refactoring, debugging, > profiling...) problems. In a typical Qt Quick application the cut usually > goes straight through the middle of the Controler part of a classical > Model-View-Controler setup, i.e. sits in a pretty bad (and expensive...) > location. It's a sink of resources.
Can you given an example? What kind of controller pieces would you do in QML? > Having an enforced language break in the system takes away this > flexibility, leaving essentially the options (a) to accept the need to > re-write parts of the system in the "other" language once the time comes, > or (b) to use a waterfall style development model, fix the V/M/C boundary > before coding starts (and ignore future uses that might need some > wiggling). I presume we agree that neither sounds good. Well, you don't have an enforced language break, you can still make the logic depend on the UI and maniulate the objects instantiated by QML via code, similar to using QUiLoader but more bidirectional. Obviously removes any flexibility you had for having different UIs for different usage scenarios. Cheers, Kevin -- Qt Developer Days 2014, October 6 - 8 at BCC, Berlin. Save the dates! Kevin Krammer | [email protected] | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
