[Development] Qt for iOS - iOSStyle

André Pönitz andre.poenitz at mathematik.tu-chemnitz.de
Wed Mar 13 00:51:05 CET 2013

On Mon, Mar 11, 2013 at 05:59:01PM -0700, Thiago Macieira wrote:
> On segunda-feira, 11 de março de 2013 23.02.02, André Pönitz wrote:
> > Why shouldn't it be possible to have a clearly layered stack with
> > proper interfaces?
> Maybe "possible" is not the right point. The point is whether it is
> feasible with the time and manpower available.
> Defining a proper interface takes time. Not defining it saves time,
> therefore allows us to finish the higher-level API sooner.

[Reminds me somehow of the procedure how the cellar of the house in
which I grew up came into existence about 50 years after the house
itself was build. Anyway, that's for later...]

> > > But it's possibly even easier to write a single 
> > > Qt Quick-based solution, with no C++ API.
> > > Given the lack of manpower, that's an alternative to consider.
> > 
> > I am not sure I understand what this alternative would consist of.
> A QML-only API.

Alright, I'll bite.

I'll try hard to abstain from anything resembling irony or sarcasm.
I just want to carry on this theoretical discussion based on purely
hypothetical facts.

I'd ask you kindly to either read all, or nothing.

----------------------- "all" starts here ---------------------

Let's assume that at some point of time we will have such a QML-only
API. For the sake of argument, let's also assume it covers reasonable
part of what in-scope use cases would like to use. Let's suppose that
its performance is considered good enough for those cases, and let's
assume existing use does not matter, so there are no migration costs
for the in-scope users, and any use that does not fit can be declared
as out-of-scope at no cost.

For simplicity, also let's assume we had this setup today. Let's
assume it is fully functional and mature out-of-the-box, i.e. no
further development cost to have a "clean slate", without "legacy"

  I'd like you to agree that this is the "best possible" setup
  one can think of.

Now what?

What would users of this perfect QML API do when they develop
applications?  Obvious answer should be "They _use_ it" i.e.

 - write source code
 - test 
 - deploy
 - debug
 - profile
 - ...  [have iterations on that]

Historically, developing with Qt was developing "simple C++" plus some
minor additions that were mostly neutral to the general tooling. So
most if the infrastructure development around Qt could be, and has
been, offloaded to the "general C++ tools" makers, which typically
include the "owners" of the respective target platforms.  Qt got
compilers, debuggers, profilers "for free". Qt can be used using
Visual Studio on Window, using XCode on Mac, without much a-do. There
are other options, at the discretion and convenience of the user.

Now, let's put the "QML-only API" that you want to consider as
candidate "effort saving alternative under resource constraints" into
the perspective of a concrete user.  Let's pick someone following
recent Qt development as indicated e.g. on

  "Development and especially deployment is done using Xcode. The
   supported workflow is to maintain a .pro file based project, export it
   to Xcode (and re-export when the project setup changes), and then
   build and deploy using Xcode. Source code editing can as usual be done
   in any editor."

So how do we in this setup
  - write source code?
    -> fire up XCode, create a .pro and a .qml file, start typing?
        [_no_ support like code completion, refactoring, etc]
      - or -
    -> fire up Qt Creator, create a Qt Quick project, type?
        [_with code_ completion, a bit of refactoring] THEN
        save when done, export to XCode to build/run/test?
      - or -
   -> have a QML editor plugin for XCode?
    (check http://stackoverflow.com/questions/6316921/xcode-4-plugin-development)
      - or -
    -> [add your favourite]

  - deploy?
    -> fire up XCode, "deploy"?
      - or -
    -> use some 3rd party solution?
      - or -
    -> implement it in Creator (assuming there are suitable APIs and
      the platform owner does not interfere) and declare all other uses
      as "out-of-scope"
      - or -
    -> [add your favourite]

  - debug?
    -> not at all? - XCode has no notion of .qml after all.
      - or -
    -> implement it in Creator (assuming...), and declare all other
       uses as "out-of-scope"
      - or -
    -> [add your favourite]
  - profile?
    -> not at all?
      - or -
    -> implement in in Creator (assuming...), and declare all other
       uses as "out-of-scope"
      - or -
    -> [add your favourite]

Feel free to pick _any_ combination of answers. I claim whatever you
choose, the result would be _worse_ than what "Qt/C++ development"
looked like so far. [Note that we are still in the supposedly "easy",
"pure QML" setup, not the C++/QML hybrid that is usually referred to
when talking about Qt Quick colloqually.]

If you lean towards the "not at all" choices you'll end up with a
toolkit with tight limits on scope and size of the applications is can
be used for, i.e. the ones that are always "obviously correct and
fast", so no debugging/profiling needed. 

If you lean towards the "implement it in Creator" choices you'll end
up with significant effort for the implementation itself, and are
constantly at the mercy of platform owners to keep your use "open".

I don't see how either can be considered beneficial, or at least as
"less evil" than setting up C++ interfaces to the Qt Quick stack.

So after considering the consequences even in the most favourable
environment I could think of it I am tempted to conclude that the
alternative you suggested to examine is not a good one.

----------------------- "all" ends here ---------------------


More information about the Development mailing list