Page 6 of 6 FirstFirst ... 456
Results 51 to 53 of 53

Thread: Digia To Spin Off Qt Business Into Its Own Company

  1. #51
    Join Date
    Nov 2013
    Posts
    215

    Default

    Quote Originally Posted by Znurre View Post
    I think the difference between you and me is that we see differently on our C++ layers
    In my projects I always have many layers, not only core and data layers with business logic, but more UI centric layers of code like QML components implemented in C++ and view models.
    Sure, I do that as well, e.g. have application specific QML instantiatable types.
    Maybe core was a bad naming on my part. What I meant is that part of the application that is always there versus the bits that are instantiated through QML.

    This first, fixed, part is what I referred to as the core. This part should not need to know about anything that the QML engine could potentially have instantiated, especially not any UI types.

    Otherwise I need different code paths in there, potentially using #ifdefs, etc.

    Of course that will not always be possible, but it is a goal which needs very good reasons to abandon.

    Quote Originally Posted by Znurre View Post
    Behaviors are nice, I use them a lot (mainly to get around named limitations in QtQuick) but I still don't feel that it's declarative enough.
    Having to assign an id to my UI components in the QML files and invoking methods on them there is not what I would consider "pure".
    But isn't direct access to a pointer to a specific type and invoking methods on them even worse?

    As a third alternative for the animation example, what about binding to the animation's "running" property?

    Quote Originally Posted by Znurre View Post
    Therefore, my wish is for all official QtQuick components to be created in C++ (ApplicationWindow.qml, I am looking at you) and with a public API
    Sure, would be nice for corner cases.
    But my experience with two frameworks that do both C++ and QML instantiation (Cascades and QtWidgets) is that I tend to fall back to C++ out of laziness, because doing it properly would have required a cleaner separation and slightly more upfront work but of course advantageous in the long run.

    Cheers,
    _

  2. #52
    Join Date
    Oct 2010
    Posts
    62

    Default

    Quote Originally Posted by anda_skoa View Post
    But isn't direct access to a pointer to a specific type and invoking methods on them even worse?
    Haha, I don't know. It's C++, I don't mind writing imperative code there, as long as it's all typed

    As a third alternative for the animation example, what about binding to the animation's "running" property?
    This is a very fair point.

    But my experience with two frameworks that do both C++ and QML instantiation (Cascades and QtWidgets) is that I tend to fall back to C++ out of laziness, because doing it properly would have required a cleaner separation and slightly more upfront work but of course advantageous in the long run.

    Cheers,
    _
    Just out of interest, how did you work with QtWidgets through QML?
    Through the Declarative Widgets project from KDAB? Or did you put together something by yourself?

  3. #53
    Join Date
    Nov 2013
    Posts
    215

    Default

    Quote Originally Posted by Znurre View Post
    Haha, I don't know. It's C++, I don't mind writing imperative code there, as long as it's all typed

    My main concern in this case is that there is a raw pointer being passed through the separation layer and, from my point of view, in the wrong direction.

    Quote Originally Posted by Znurre View Post
    Just out of interest, how did you work with QtWidgets through QML?
    Through the Declarative Widgets project from KDAB? Or did you put together something by yourself?
    Yes, using DeclarativeWidgets.

    It is another one of those eye openers for me.
    Theoretically it or a similar module would allow me to write a mobile app with, e.g. native BB10 Cascades, UI and detect attaching of an external screen and keyboard/mouse and load a full features desktop-style widget based UI.
    Or for convertiables, assuming one can detect the switch.

    Or for having a desktop application with highly configurable UI.

    Cheers,
    _

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •