Re: [Development] How to include Standard Library headers from Qt ones?

[charleyb123 .]

Marc:

> I know Howard's ideas about hashing, and I agree with them. In Qt, we
> largely
> ignore the issue of hash collisions for a given type and just hash its
> members, combining with boost::hash_combine, and hope for the best. As
> such,
> the problem described in Paragraph 5 of
> https://isocpp.org/files/papers/n3980.html#Solution1B, if it is, indeed,
> the
> one you're referring to, is the same for qHash() and std::hash. Only a
> Hinnant-like hashing interface that takes the hash function as a parameter
> would solve that.
>
> Are you suggesting to skip supporting std::hash and go directly to
> providing
> Hinnant's interface in Qt instead?
>

I'm party-crashing the discussion, but +1.

(1) Skip std::hash, it's the wrong interface.
(2) Use a transactional hash interface (very performant and composable)

We implemented the Hinnant-style interface a long time ago throughout a
very large codebase, it works best when consistently supported across the
codebase, IMHO it's a vastly superior way to go.

For the casual reader, this implies a "transactional" approach to hashing:

(1) "Start/init" the hash
(2) Go nuts accumulating state into the hash
(3) Finalize the hash (for example, can be "lazy" when hash-value is
extracted)

The problem with "std::hash" is that it lumps all three steps into one
step, which is horrible and expensive in many/most real-world applications
requiring hashing of non-trivial state.

The Hinnant-style interface works great when all APIs take a
"QtHashBuilder" (or whatever).  Qt has tons of experience with consistent
APIs like that, for example, see recent discussions on QStringBuilder or
similar.

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[charleyb123 .]

On Fri, Feb 10, 2017 at 3:59 AM, Tuukka Turunen  wrote:
> Short summary: The Qt Company has decided to focus development effort to 5.9
> and dev branches in order to reach the planned timeline for Qt 5.9 release
> and make improvements in the CI system. ,

> In the CI system side we have major improvements happening during this year.
> We will be purchasing more blades and other HW during H1/17, which will add
> capacity, so we will be able to run more parallel integrations. 

Perhaps related, I think it might be a good idea to target more
closely new compiler releases from Microsoft.

In the past several years they have shifted to an early-and-frequent
update model, and organizations are adapting to more aggressively take
advantage of new C++ language features, and to target platform
technology changes.  For example MSVC++2017 (version 15) was previewed
in March-2016; has had three major updates; went to RC in Nov-2016;
and is announced for launch in March-2017 (see:
http://www.zdnet.com/article/microsoft-to-release-visual-studio-2017-on-march-7/).

That tool chain was actually at very high quality since its launch a
year ago (this is their new release model), and I'm aware of companies
that have relied on that version for commercial development since its
preview access.

IMHO, not providing binaries for that platform is a hindrance to Qt
adoption.  Intel provides chips to OEMs before launch, and companies
regularly provide pre-release technology access to allow OEMs time to
integrate with their products, and I'm suggesting Qt should similarly
support this type of early-access (we can call it "pre-release" access
if we want).

Yes, developers can build their own Qt binaries; but this is a
non-trivial point of friction, and you need to install Python, and
become familiar with config, etc.  The "experts" have success here,
but we continue to see email threads on stumped non-experts unable to
get working Qt binaries.  If we want friction-less Qt adoption
(perhaps even for casual and accidental developer exposure), we should
just provide the binaries.

Yes, I'm very aware that some companies are on the slow-stable upgrade
model and need long support for older compilers.  I'm talking about
another market where requirements and competitive advantage demand
access to new tooling, (consistent with the fast pace of web
technology advances and the need for security patches and updates).

Under this proposal, Qt binaries would be available for MSVC++2018
when it is previewed, or at least most certainly when it goes to RC.
Waiting for it to deploy is *way* too late, as the new Microsoft
release model suggests that developers have been integrating the
compiler into their tooling for a year before Qt "shows up".

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Use of Standard Library containers in Qt source code

[charleyb123 .]

On Tue, Jul 12, 2016 at 3:47 AM, Marco Bubke  wrote:

> , Lets face it, the world is much bigger than Qt, and I think there
> is much to gain if we integrate better with alien libraries.
>
My understanding is that most alien libraries are not binary-based (i.e.,
they are ternary or use other forms of multi-valued-logic (MVL)).

;-))

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtSingleApplication in Qt proper?

[charleyb123]

+1, I've found many good uses for QtSingleApplication, and think this is a
good (highly practical) feature for "Qt-proper".

--charley


On Sun, Jun 19, 2016 at 11:59 PM, Kevin Funk  wrote:

> On Donnerstag, 16. Juni 2016 00:19:10 CEST Kevin Funk wrote:
> > (snip)
> >
> > Question:
> >   Is there an interest in having QtSingleApplication in Qt proper? Say
> > qtbase? We'd love to do the work if there's a chance for it being
> accepted.
>
> Heya,
>
> Thanks for all the comments, I'll work on introducing QtSingleApplication
> into
> QtCore, including porting it to QLockFile, including porting it away from
> the
> QCoreApplication base.
>
> Hopefully within the upcoming weeks if I find the time.
>
> Cheers,
> Kevin
>
> > (snip)
>
> --
> Kevin Funk | kf...@kde.org | http://kfunk.org
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] HEADS UP: Updates to Qt 5.7 (and Qt 5.8) tool versions

[charleyb123 .]

>
> Visual Studio 2015 Update 1 to Windows 10
>
> Please let’s keep in mind that Visual Studio 2015 Update 2 is coming out,
> I don’t think that it will be ready for Qt 5.7, but we should be prepared
> for Qt 5.8 indeed.
>
> Regards,
> Diego
>

+1

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Dropping VS 2012 in Qt 5.7

[charleyb123 .]

On Thu, Feb 25, 2016 at 8:20 AM, Thiago Macieira 
wrote:

> Just starting a new thread to get the attention of those that may have
> missed
> it in the other platform.
>
> The proposal is to drop VS 2012 support in Qt 5.7 already, instead of
> supporting it in 5.7 only and dropping in 5.8.
>
> The rationale is that we need VS2012 for WEC 2013 support, but there's no
> point in supporting that operating system in Qt 5.7. It suffices that it is
> supported in Qt 5.6, which is the long-term release. In other words,
> needing
> WEC 2013 customers are better served by staying in Qt 5.6 than upgrading to
> 5.7.
>
> Opinions? Objections?
>
> I'd like to see this answered BEFORE we release 5.6 so we can add this
> interesting tidbit to the changelog. The 5.5.0 changelog said:
>
>  - Qt 5.7 will begin requiring certain C++11 features in order to
>compile. The minimum compiler versions for that release will be:
>* Clang 3.2 (included in XCode 5.0)
>* GCC 4.7
>* Intel C++ Composer XE 2013 SP1 (compiler version 14.0)
>* Microsoft Visual Studio 2012 (compiler version 17.0)
>
> Since that went out, we've already risen our minimum Clang required
> version to
> 3.4.
>
> > > > In summary Qt does not gain anything from pushing WEC2013 to 5.8:
> > > >
> > > > - Potential Qt Customers are not stranded due to 5.6
> > > > - WEC2013 in 5.8 doesn't really enable more projects
> > > > - MS says it is dead and licenses are hard to come by
> > > > - the currently visible project pipeline is rather dry on this
> > > > platform
> > > >
> > > > *But* our C++11 offering is yet longer chained.
> > >
> > > So why are we bothering with VS2012 for Qt 5.7 then? Why wait until
> 5.8?
> > >
> > > Let's drop it now.
> >
> > That is fine for me as well. As Alex wrote, most important is that Qt 5.6
> > LTS supports both WEC7 and WEC13 and that latest for Qt 5.8 we no longer
> > have these to slow down adoption of C++11 and other planned changes.


Works for me.

Since Microsoft now has WEC2013 as deprecated legacy, makes sense for the
long-term-support of Qt5.6 to be the last to support that platform.

I don't see what it gains to keep MSVC2012 beyond Qt5.6.

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] CppNow Call For Submissions 2016

[charleyb123 .]

The Call For Submissions for the CppNow conference (May 9-14, 2016) in
Aspen, CO will close this Friday (Fri-29-Jan).

This is an intimate C++ conference with great minds, including many Qt
users, and past speakers have come from the Qt community.

Consider attending, and/or submitting a talk.

http://cppnow.org/2016-conference/announcements/2015/11/17/call-for-submission.html

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[charleyb123 .]

Thiago sayeth:

> ,
> But I have no plans on extending QAtomicInteger and QAtomicPointer further.
> There are a couple of missing features that will probably never be
> implemented:
>
>  * std::memory_order_consume and std::memory_order_cst
>  * GCC's extension for hidden lock elision
>  * compare_exchange_weak (doesn't affect Intel, so I don't care)
>  * weaker memory model for the failing compare_exchange's reload
>  * atomics on non-integral and non-pointer types, including larger types
>  * volatile support
>
> From my point of view, if you need to go further on atomics, you should
> just
> use std::atomic.
>
> We could introduce QAtomic which wraps the std::atomic API and adds the Qt-
> style names. Is it worth it?
>

That would have been handy for a previous project, as we had the same
codebase deploying to multiple architectures and we effectively had to do
that ourselves -- we preferred QAtomics (because of the better API), but
needed to wrap std::atomic for our deployment to one ARM platform.

So, we made our own wrapper atomic class with the Qt interface, but had an
#ifdef...#endif to wrap std::atomic for one platform.  Worked fine (it's
now a preferred pattern).


> > > We started some experiments with convenience wrappers for std
> algorithms
> > > for use in Qt Creator when we started requiring C++11:
> > >
> http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algor
> > > ithm.h
> > Interesting. That could be a starting point for a QtAlgorithms successor.
>
> Agreed. Instead of reimplementing , expanding them for
> convenience
> API.
>

Agree here also, and with other comments in the thread regarding
"not-much-love" for STL API choices/semantics.

IMHO:

(1) Most programmers don't even know about the STL algorithms.

(2) Most programmers have a hard time conceptualizing what the STL
algorithms are "supposed to do", even when looking right at them, after
they are correctly employed in working code.

(3) STL API conventions and volatility across versions are ... unfortunate.

(4) Due to 1-3, many informed programmers remain unconvinced of the value
of even bothering to increase STL algorithm adoption.  (I think this is
disappointing, but concede it to be a rational response by many teams.)

I really think the, "convenience API" is worth a *lot*.  Even just wrapping
 with Qt semantics is worth a ton.  Programmers would actually
*use* those, and *understand* those in code.

Recall that even in on the C++ committee, there is not universal support
for the ".begin(), .end()" where two parameters are required to iterate a
single container (e.g., web search for, "Iterators Must Go", Niebler's new
iterators work, proposals for future modified APIs for parallel-iteration
of container elements).

So, this would add another interesting motivation (and I'm seriously going
to, "get out the popcorn" to watch the events unfold as I listen to the
wailing and lamenting and gnashing-of-teeth as...)

(5) In the not-too-distant future, the existing STL iterators API may be
deprecated in favor of new iterator conventions.

That sure is a lot of code to migrate, and it would be nice to have a
convenience API to adopt.

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[charleyb123 .]

Thiago sayeth:


> So no, I don't think we risk becoming irrelevant against other airplane
> makers
> anytime soon. Our competitor are those transatlantic heavyweight ships
> (HTML5).
>
,

LOL!!!

That's actually a very good point (in addition to the fact that I really
did Laugh-Out-Loud).

C++ is growing, and native-client apps are growing (mobile, embedded,
desktop, cloud).

The Qt value-proposition gets you native on that platform better than
anything else, including the C++ Standard (which is merely a language
standard, and not a technology platform).

We would likely get quite a few blank stares when walking into a bar for
programmers (do those exist?) and shouting, "C++ is easily approachable!"
 However, we'd get many nods-of-agreement saying the same about Qt.

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Virtual Keyboard (New KDE Free Qt Foundation Agreement and Changes)

[charleyb123 .]

+1

On Tue, Jan 19, 2016 at 4:32 AM, Knoll Lars 
wrote:

> +1 and +1 from me as well :)
>
> Cheers,
> Lars
>
>
>
>
> On 19/01/16 13:16, "Development on behalf of Marc Mutz" <
> development-boun...@qt-project.org on behalf of marc.m...@kdab.com> wrote:
>
> >On Tuesday 19 January 2016 08:22:54 Viironen Kalle wrote:
> >> Hi,
> >>
> >> As Lars mentioned in his email about KDE Free Qt foundation agreement
> and
> >> changes,  we’re pushing sources of Qt Virtual Keyboard to codereview.
> >>
> >> I’d like to propose the Qt Virtual Keyboard module to be taken as part
> of
> >> Qt add-on modules,it has been part of commercial Qt releases for some
> time
> >> now.
> >
> >+1
> >
> >> I also propose Mitch Curtis to be named as maintainer for the Qt
> >> Virtual Keyboard module.
> >
> >+1
> >
> >--
> >Marc Mutz  | Senior Software Engineer
> >KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> >Tel: +49-30-521325470
> >KDAB - The Qt Experts
> >___
> >Development mailing list
> >Development@qt-project.org
> >http://lists.qt-project.org/mailman/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[charleyb123 .]

Apologies for "hijacking" the thread, but two points were raised that IMHO
would be helpful if they were answered directly:

(1) Future of Qt binary compatibility
(2) Use of std:: containers (especially in context of (1)).

We can take this to another thread as-needed.  However, quick "recap":

===>PART (1), Future of Qt binary compatibility

Marc sayeth:


Notable quote (Marc):

> ,

This is why we need to stop duplicating std API. It's not Qt's core
> competency
> to meddle with things we only have a half-interest in. It's fun to write
> QOptional. Until it isn't anymore. And then the (Qt) world needs to live
> with
> the poor-man's std::optional for the next few decades.
> 


In further support of (1), ...

 Иван Комиссаров sayeth:
>
>> I've already heard those arguments, however we _can't_ use std::vector in
>> API, because it's implementation may differ between compliers (gcc and
>> clang stdlibs, for example).
>
>
Giuseppe D'Angelo respondeth:

> We might reopen the case about why we should care at preserving binary
> compatibility amongs different standard libraries. Or preserving binary
> compatibility at all...
>

IMHO, "something is different" now that C++17 will provide features like
"Modules".  While "phase 1" might merely be something like a glorified
"precompiled-header" bundle to speed compile-time, it's clear that "phase
2" is intended to approximate an ABI whereby a compiler could resolve these
implementation-mappings across compiled-lib boundaries.

This begs the question:  Past Qt design decisions providing binary
compatibility through *code* decisions (e.g., d-ptr and wrapper classes)
might in the (not-too-distant-future) be otherwise resolved with new C++
language features.  If this were true, how would Qt like to position itself?

Specifically, IMHO Qt remains the best-in-class cross-platform framework.
In part, this value came from its strong adherence to managing what nobody
else was managing -- its interface binary compatibility.  Going forward,
Qt's value proposition might more appropriately focus on what it *is*:  A
rich cross-platform framework (whereby it might continue its ABI stability
through C++ language advances, not through library conventions).

===>PART (2), Use of std:: containers

This is a big topic, discussed on other Qt threads.

However, from this thread:

Bo sayeth:

> ,
> However, my customers have developers that are a lot less experienced than
> us. And it's my observation that using the Qt classes over the std classes
> lead to fewer mistakes and faster applications. It seems much easier to
> shoot yourself in the foot with std. I don't know why this is, it's only
> what I observe when I look at code written by others.


Agree.  Completely.  IMHO, this is because:

std:: and friends:

  *- GOOD:  ...are mathematically elegant, and complete, and fast (e.g.,
Stepanov's work, iterators, API and implementation evolves with C++
language advances).

  *- BAD:  ...have really poor APIs that are error-prone, are often
inconsistent, and incomplete, and dangerous, and unlike how most
programmers "think" and designs "work", and are painfully volatile across
C++ Language Standards versions.

In our codebase, we've "wrapped" the std:: containers for stable-and-safe
interfaces.  Huge dividends.  You can get (unsafe) direct access to the
embedded std:: entity if you want.  This is another option/mechanism for
how we might evolve stable Qt interfaces, and work with std:: and friends.

<===END THREAD HIJACK

IMHO, the Qt community likely requires a long-term strategy for how it
wants to address ABI and std:: in the face of very active advances in C++
Language Standards, libraries, and STL idioms.  Also IMHO, these are big
things that we can leverage to great Qt advantage.

Specifically:

(a) There is a reason programmers want to use std::

(b) There is a reason programmers have a hard time using std:: in any
codebase (Qt can help with this)

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] API Change in QtRemoteObjects

[charleyb123 .]

Hi, Brett--

IMHO, this is a very good change.  The library will be easier to use, and
more accessible from QML.

Also, now is probably the time to make such an API change.

I'm watching this effort with great interest -- thanks for all your hard
work.

--charley


On Sat, Jan 2, 2016 at 10:51 AM, Stottlemyer, Brett (B.S.) <
bstot...@ford.com> wrote:

> Hello,
>
> For those of you using the QtRemoteObjects playground module (QtRO for
> short), some changes went in over the holidays that changed the public
> API.  So you will need to update your code when you update to any version
> of master past 16959709b59db45c07385ecc13b76061de851edf (or see the
> (merged) review: https://codereview.qt-project.org/#/c/144624/).
>
> From the commit message:
> > Convert Nodes to QObject based class(es)
> >
> > This change affects lots of lines of code, but is
> > basically a refactoring, not changing much.  It
> > does change the QtRO API, though.
> >
> > In the interest of making it easier to expose QtRO
> > types to QML, the move to QObject types for Nodes was
> > necessary.
> >
> > The static generators allowed for different "types²
> > of Nodes to be created with different combinations of
> > 1 or 2 QUrl parameters, but this also forced a Node
> > type that had methods that might not make sense (for
> > instance, enableRemoting() from a Node that wasn't a
> > Host Node).  And Nodes needed to be copy-able.
> >
> > This change addresses those issues by creating
> > three distinct types.  QRemoteObjectNode is
> > the most basic type, and only supports acquiring
> > Replica objects.  QRemoteObjectHost Nodes add the
> > ability to share Source objects on the network.  Both
> > Node and Host types support connecting to a Registry.
> >
> > QRemoteObjectRegistryHost Nodes host a Registry object
> > other nodes can connect to.
> >
> > This change requires converting end-user code from
> > the static functions (createHostNode, etc) to using
> > the new types explicitly.
> >
> > Aside from the obvious change from static generator
> > functions, there are two other impacts to user code:
> > 1) connect() was renamed to connectToNode to not
> > conflict with QObject's connect()
> > 2) default QUrls for Hosting and Registry were removed
> > (it was too easy to create name clashes with unexpected
> > results).
>
> Apologies for any inconvenience, but this will make QML integration
> simpler, and makes the APIs more aligned with other Qt APIs.
>
> Happy Holidays/Happy New Year!
> Brett
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.5.1 'rc' available

[charleyb123 .]

>
> On Wednesday 23 September 2015 08:37:54 Heikkinen Jani wrote:
> > We are targeting to release Qt 5.5.1 as soon as possible, most probably
> > during next week.
>

On Tue, Oct 6, 2015 at 2:56 AM, Gerhard Scheikl 
 wrote:

> Hi
>
> Could you please give us a new estimate?
> Unfortunately, we rely on one of the fixes in 5.5.1.
>
> Thanks!
>
> Best regards
> Gerhard
>



A couple weeks have gone by, and I've not seen "Meeting Minutes" from
recent release-team-meetings.

Do we have a feel for timing?  (I'm in a similar scenario as Gerhard.)

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS C++11 plans (CopperSpice)

[charleyb123 .]

 snip, shared pointers


Bo Thorsen sayeth:

 This answer is going to be one big IMHO.

 Anything that stops people from throwing shared pointers all over the
 code is A Good Thing. As someone once said: Shared pointers are a
 solution in search of a problem.

 Scoped pointers are fine, but shared pointers indicate a lack of
 handling of responsibility and ownership, which indicates bad design.


This.

Thank you, Bo.  We regularly see issues with new-grads that seem to think
that naked pointers should no longer exist, and all things should be
std::unique_ptr or std::shared_ptr.  OMFG.

My assertion is that Design is:

(1) What objects should exist.
(2) Who owns them.
(3) There is no Number Three

...and, we almost never have a good reason to use shared pointers.

For you to use this as a reason for forking Qt is a very bad indication.


I'm curious how much of the CopperSpice motivation is this, or other things
like signals-on-templates and removal of moc.  (I no longer need
signals-on-templates, but many years ago I thought I did.)

I must say, some of the CopperSpice decisions are very clever (heavy use of
preprocessor to generate unique IDs that would otherwise be handled by
moc).  I similarly thought the Woboq guys with their moc-removal approach
was quite clever, and these are two very different examples of a
possible-future-direction-of-Qt that I think is quite healthy for our
community to discuss.

I appreciate the CopperSpice guys talking about their decisions and
rationale on their design approach, and hope they will remain active in
these forums.

It's quite clear to me that some of the very dramatic moves occuring in
C++14/17, including possible modules, and some of the new TMP capabilities
open up options that we never previously could consider.

And, it seems that some of these patterns and directions remain somewhat
unexplored or otherwise represent new territory for consideration.

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] MSVC2015 and Qt5.5 -- dot release plans?

[charleyb123 .]

Microsoft announced MSVS2015 will be released on July 20:

http://www.zdnet.com/article/microsoft-sets-release-date-for-visual-studio-2015/

Those of us that have been following the MS compiler know that the MSVC2015
is a particularly strong compiler, making up for lots of lost-ground in
supporting C++11/14 features.

There was discussion on this list about a Qt5.5 dot-release for MSVC2015
... do we have a feel for timing on this?

(I know we can individually compile Qt for this compiler now, I was just
curious about a community Qt5.5 release.)

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS C++11 plans (CopperSpice)

[charleyb123 .]

  For example, with moc removed we support template classes that inherit 
  from QObject.

 Wow. I would (almost) kill for having that feature in Qt!

 You can work around it quite easily. What doesn’t work is adding new
 signals / slots inside a template class. So just add a base class declaring
 these signals/slots, and make your template class inherits from it.

 Unless you wan’t to use the template class as signal/slots arguments, this
 works fine.

 Regards,

 Julien


+1.

I do that a lot:

  QObject = MyClass = MyTemplate = MyClassDerived

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtRemoteObjects (was Replicant)

[charleyb123 .]

 Sayeth Simon:

 On the other hand I think it is critical for Qt's success to also support
 use-
  cases that leave our little universe (of Qt). And that means either
 building
  something yourself and convincing others to adopt it or adopt a
  technology/approach that already has existing mind share. For distributed
  objects architectures I do like the idea of supporting wire formats that
 have
  existing mind share and I also do think it is very important to make the
  programmers aware of the distribution.


Respondeth Brett:

 Sure.  I agree in concept.  But how are you suggesting we go about this?

 My resistance comes from several factors:
 1) I think what you are proposing is what D-Bus brings to the table.  By
 focusing on the Qt side, I think remote objects is easier to use than
 D-Bus, but is also not seen as competing with it.  You risk both by making
 it more general.
 2) What you are proposing is a massive increase in scope, which obviously
 takes a lot of time/resources to accomplish.  Is Digia offering to help?
 3) As stated, the existing code is spread throughout all of Qt.  I assert
 that any new wire format support needs to be spread throughout Qt as well.
 Otherwise you have a  maintenance nightmare trying to keep up with changes
 to all of the various types of objects.

 Unless you have a solution I'm not seeing, I think the best thing to do is
 try to future-proof remote objects so such a change is possible down the
 road.


Agree with Brett.

I think this is a vision/mission thing, as D-Bus and QtRemoteObjects are
doing different things, but as noted there happens to be some overlap.

Regarding the future-proof, I'd vote on a plain-text
serialization/synchronization of QVariant across the wire, possibly with
user-data type extensions for custom plain text to/from for state
serialization across the wire.  Plain text tends to be quite robust, and
future-proof, and it's often useful for debugging anyway, even in the case
where a binary protocol is available.  Good examples are things like date
and time and color -- the plain text version is well-understood and
forever future-proof, independent of native binary storage.  Most of the
automation and LIMS systems (lab information management systems) actually
stay plain-text for production, and that's what they use in production to
simplify integration across vendor devices and instruments.

It might not be practical for high-speed/high-volume data to be plain text,
but most systems aren't that.  QtRemoteObjects sitting on plain text (like
JSON) might enable alternative foreign-point implementations (such as for
other non-Qt libraries or languages).

Just guessing/speculating.

The most ideal might be a slow-plain-text protocol, and a fast-binary
protocol, where the user can toggle between them based on their
need-for-speed.  But, of course, that's double the work.  ;-)

So, I think there are really good points here, but my intended first use
is QtRemoteObjects with Qt on both sides for transparent synchronization.
In this case, I actually don't care about the details.  I want the library
to do all the cross-process details, so I don't need to. That's what makes
it really shine as a novel high-value thing, IMHO.

Further, if we did this, I could still write MyProprietaryLib on the
foreign-point to hook into other systems.  It would link Qt, and expose
the QtRemoteObjects API through my new API using MyWeirdLanguage.

Regarding the foreign-point not linking Qt (such as for embedded where no
Qt might be available), yes, we're back to discussing something like a
plain-text protocol where someone could re-implement using that protocol.

snip,

  This is clearly something where philosophies and opinions differ, so a
 perfect
  subject for a healthy debate of what we should focus on in Qt, as we try
 to to
  make software development easier.
 I think the discussion needs to be whether Qt will accept an alternate or
 additional method of marshalling data types.  But I guess that is up for
 debate!


I'll follow discussion here closely.  My impression is that we'll
eventually need/want to centralize marshalling/serialization for
QtRemoteObjects, possibly eventually allowing user-custom-type extensions
for synchronizing custom user-state.

It would either be centralized through something like a moc-generation that
handles the details for each type, or through a centralized marshaller
that is aware of the serialization details for each type.

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] CppCon Just Ended (next year will be 20-25 Sep 2015)

[charleyb123 .]

Just got back from CppCon (http://cppcon.org/), WOW what a great conference
for C++.

Apologies for cross-post qt-interest and qt-dev, but wanted to be sure both
groups saw the announcement for next year (20-25 Sep-2015).

WOW AGAIN for a great conference.  Really heavy-hitters there, with
information I don't know is available elsewhere.  For example:

*- Google C++ code base is 100 million lines, is managed as a single code
base serving many projects, and they don't use exceptions in it anywhere.
 Techniques on managing code base are impressive.

*- Similarly (from other presentations) lots of code bases don't/can't use
exceptions, and this is not a, solved problem (especially for the game
industry)

*- Facebook (Andrei Alexandrescu) cheats with stealing bits from their
implementation of a shared-pointer to steal-bits for the
object-count, with the understanding that the count rarely goes above
4.  Correctness is sacrificed to increase performance 0.4%, which is a
huge win for server load and electricity (saves $millions a month).
 Leak, Log, and Leave is what they do for the uncommon correctness
failure-case.

*- Empty constructors and empty destructors when inlined are not free,
and in large code bases can have significant cost.  Optimizations are not
intutive, and must be measured.  (Facebook)

*- Microsoft compiler team, library team, STL team was represented.  Really
fantastic talks, and these guys are smart.  If you had any concerns about
the toolchain, they are absolutely going in a clear and strong direction.
 (My biased recommendation for us is to move off our reference compiler of
MSVC2008 to MSVC2013, and then move asap to the next compiler (probably
released early next year) to make it our reference-compiler for an
extended period of time (I am not concerned about early adoption on this
next compiler, and I _do_ want the new language features).

*- Lots of Clang goodness -- have a look at Clang Format and Clang
MemorySanitizer.

*- Great talks by Intel on concurrency/parallelism, interfacing with
hardware, etc.  Other HW vendors there too like IBM, panel discussions on
issues, etc.  It's increasingly obvious that C++ developers need to have
greater understanding of hardware architectures to create well-engineered
designs that take advantage of all the cores and caches.

*- Tremendous consistency in low-level talks on coding to consider the
instruction-cache, L1 and L2 caches, other memory issues related to
performance.  General/common knowledge:  Let your data structures take
advantage of understanding that fitting inside 64-byte units is a Big Win
for cache optimization, consider data layout for word-alignment, and
consider allowing array-processing of raw contiguous data.  Also, using
std::vector will never get you in trouble, many other
std::container things can often get you in trouble.

*- Game industry had strong presence, including a keynote by Mike Acton
(InsomniacGames) on, Data Oriented Design.  GREAT example of engineering
in the face of hardware constraints, seemed similar to an approach of
OO-using-C (but using C++), talked about failed C++ design approaches for
games.  REALLY made a lot of the audience uncomfortable (you've got to
watch the video when it posts -- it will become a classic, was really a
punch in the gut for some people), but I thought it was one of the
highlights of the week (there were so many), and he wasn't wrong.

*- Some wickedly serious template metaprogramming techniques, including new
ones now possible through C++14, including expressing previous
meta-programming approaches with much greater elegance/readability and less
work.  IMHO there is a strong place for this, especially inside libraries.

*- It is estimated 3-4M C++ developers exist in the world (Google has 4K
C++ developers).  Tech book sales were down 3% over the past year, but C++
book sales were up 4% (C++ is growing in adoption).

*- C++ language standard is maturing in a non-trivial and deliberate way
through the Standard C++ Foundation (http://isocpp.org/) , especially for
more parallel/concurrent, and more intimate interface with hardware.  It
really is driven by the community -- you write a paper (proposal) so they
can review it, and it may eventually get codified into the language or
standard library.  They are always looking for people to review or write
papers, or work in any of the working groups.  Anyone can attend, members
can vote.  Especially when compared with what other programming languages
do for their standardization and evolution, the Standard C++ Foundation
IMHO really represents a great place for the community to substantively
address real-world issues (it is a tremendous asset to our community).

This is just a subset, because I could not attend all talks.  All talks
were professionally recorded, and will be posted online (for free).  Watch
them.

CLOSING REMARKS

This was a first-year conference, and it was a huge success (about 600
people, it exceeded their goals).  There 

Re: [Development] Request for a sandbox area: Replicant

[charleyb123 .]

 This cross process stuff is starting to feel like 1996 and
 remote procedure RPC calls, now using QT signals and slots. drool
 again for effect.

 One could review the history of microsoft and the fine RPC mechanisms
 that turned out to be mostly unusable, or maybe just unused.

 Keep the optimism in check folks. We have a lot of devices now in the
 mix, not just Win32.


I understand your assertion.  By 1996 I'd already completed multiple CORBA
projects for the telecom and aviation industries.  You're right -- it was
largely unusable.  Hence, those technologies are pretty much gone now (too
expensive and problematic).

That era had problems:

(1) Too complicated (security, platforms, versioning, etc.)
(2) Really big foot print.
(3) Really expensive tooling (pricing, and hardware requirements)
(4) Profound invasiveness/coupling across the tiers
(5) Non-scalable (real-world designs could not evolve without profound cost
or rewrite, despite promises to the contrary)
(6) Inability of the standard to be implemented (it was massive)
(7) Inability of the tools/libraries/APIs/standards to evolve (the
standard and industry variants were too big/complicated)

So, everybody shifted to lighter stuff, like RPC/SOAP/RMI/REST.

However, these don't solve the fundamental issue:  Asynchronous type-safe
messaging across processes.

Fundamentally, you can't have it.  (Not today, with current approaches; you
have to roll-your-own.)

I agree that today's lighter fare (like HTTP/REST) is better than
back-then.  However, that means you have to serialize to XML or JSON, and
do your own marshalling to/from your higher-order types.  Yes, it's simple.
But, it's tedious. The first thing any sane person would do is wrap
(hide) that detail so the system doesn't see it.  That's why I want the
library.

Today's assertion is more specific:  Cross-process and cross-hardware
scaling requires:

(a) Asynchronous/non-contention (i.e., messaging designs)

(b) Type-safe APIs (beyond POD, handling data marshalling)

The signals/slots approach is a new variation over the past, and over
what's widely used today.  IMHO it is an elegant approach (Qt users already
design for (a)  (b) when we do signal/slot).

Don't make me define a schema.  If I pass a QVariant to another process, it
had better show up as a QVariant.  If you make me define an XML/JSON
schema, I'll do it as an implementation detail, but I won't tell anyone
about it (because I own both ends).  If I want to give a customer access
to one end, I'll give them a library that lets them work with real-types
and which handles internal control flow/timing details, and not an
out-of-date JSON schema description.  That's why this should be a library.

A generalized solution is possible here.  That's why I'm saying killer
app.

Yes, the downside is that I need Qt on both ends -- so a QVariant is
sent and then received (through signal/slot).  However, this is *also*
why it offers benefits that today's other technologies cannot match
(transparent serialization and notification).  But, since we already use Qt
as our cross-platform porting layer, IMHO this is a feature.

True, large distributed systems may need other things like network
topology management (nodes come-and-go, security, etc.), but IMHO that's
pretty secondary and not terribly difficult to scale on top of the
premise/approach, which is type-safe cross-process messaging.

The reason why RPC died and HTTP/REST dominates is the simple fact that
 HTTP/REST is SIMPLE.  Not 10 million bloody incomprehensible parameters
 like RPC.
 Whey does SOAP continue to decline?  Extra complexity for little or no
 gain.  Who wants to worry about WSDL?

With HTTP/REST, If you do not have network connectivity, the ergonomics
 are dictated by a simple timeout and an HTTP/404 error or something like
 that.
 WIth RPC, you could NEVER tell why it was not working.  But you were
 SURE it was NOT working.  Sometimes, you were not sure it WAS working.
 Let alone a human being operator getting meaningful feedback
 and the library supporting such simple feedback.
 What does error WM_ERRORBASE+IPCERRORBASE+CUSTOMIPCERROR mean?


These are fair points.  I separate the two:

(1) Ease-to-use:  Signals/slots across processes is hands-down superior
in every way than anything listed above.  (Simpler, more correct, more
elegant, easier to scale.)  -- If it works.

(2) Ease-to-setup/administer:  I don't know yet.  This will be an important
detail.  I think this is consistent with your concern above, which is one
of the reasons HTTP/REST is so popular now (it's easy to setup and
diagnose).

So, I concede you raise good points.  However, if it is easy to
setup-and-administer (if we can properly address [2]), then I continue to
stand by the Killer App assertion.

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Request for a sandbox area: Replicant

[charleyb123 .]

(I'm just jumping in here...)

snip, Replicant for IPC

Bret spaketh:

 In trying to address your points, I fear it sounds like I think D-Bus is
 bad.  That's not
 what I'm trying to say.  I'm saying D-Bus/QtDBus didn't work *for my
 use-case*.
 So I created something that worked better *for my use-case*.

 There are cases where shared memory is better than sockets for IPC.  There
 is a
 single perfect solution.  I have a HUGE simplifying assumption that all
 processes use
 Qt.  That cuts down where Replicant is useful quite a bit.  But with this
 assumption,
 I can make IPC pretty easy.  And that was valuable to me, especially in
 the churn of
 early development.

 Thanks,
 Brett


I am *HUGELY* interested in this.  We do lots of IPC, and across physical
devices, and his design issues really hit home for us.  Part of the
reason for our interest is we've implemented similar things, and the
design-approach-overlap is uncanny.  (That's a CAN bus joke.)

We'd really prefer to not grow our own, because all of this is mere
plumbing.  We want signals/slots across processes, and across devices
(physical hardware).  The Prime/Replicant model concept really does work
nicely for this (I haven't looked at Brett's code, I'm just nodding a lot
as I hear him talk about it).

Did you guys catch the VoCore a few days ago (small Linux stack module)?
 This kind of thing is going to be *everywhere* with the new
internet-of-things.  After attending QtDevDays for the last couple years,
it's already clear that (today) you can ssh into your vacuum cleaner,
stove, and refrigerator.  IMHO, transparent signals/slots across hardware
stacks will be a killer app for Qt (in addition to its cross-platform and
declarative interface).  (VoCore:
http://linuxgizmos.com/tiniest-linux-com-yet/ )

Brett mentions:

(1) Assume processes are not on the same hardware (e.g., can't do shared
memory)
(2) Assume processes have different target OS (e.g., Linux, Windows)
(3) Assume processes have Qt

We *also* are willing to make these, HUGE simplifying assumption[s] to
make IPC pretty easy.  Effectively, if all IPC were expressed as mere
signals/slots across processes, that would be *awesome*.  Unbelievably
Awesome.  Killer App Awesome.

I estimate this would effectively cover 80+% (maybe 90+%) of the IPC
use-cases, with the remainder being dedicated sockets for
volume-data-transfer.  We do both, but I'd guess *most* applications are
nearly 100% status-and-control across processes.  (That's the whole point
of RESTful interfaces, and why it is increasingly popular.)

Recall that today, signals/slots are thread-safe bridges to enable
messaging across loosely coupled objects.  That's exactly what we're
talking about here, but also across-processes (and across hardware).
 Making it work across processes is already design-consistent with today.
 IMHO, that's a Killer Application.

This is also the *whole point* of a microkernel such as QNX that merely
enables messaging-across-processes.  Simple.  Reliable.  Bullet-proof.
 Scales nicely.  No locks/contention.

One design implication is the new need for some type of code generation
(e.g., extending moc), which Brett mentions he did.  We did this too.
 It's necessary to manage the adapter code that no human should write,
based on some kind of protocol or interface specification for the
Prime/Replicant bridge.  Things like IDLs were used in the past, and
CORBA-like systems added functionality like enabling versioning,
security, and lots of complicated things on top, but IMHO
simpler-is-better.

This is plumbing.  It should be in a library.  Sitting on top of Qt.
Providing simple type-safe cross-process messaging.

Signals/slots transparent across processes... drool...

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about Qt's future

[charleyb123 .]

On Mon, Apr 28, 2014 at 4:39 AM, Hartmann Thomas
thomas.hartm...@digia.comwrote:

 Hi,

 gluing together C++ and Java Script is currently not always that easy.
 The solution I propose is the option to write C++ code in the exact same
 way you currently write Java Script code.
 This means every QML context/component can have a C++ object attached to
 it that implements a set of methods
 that are exposed to QML. The important part would be that C++ would have
 access to the QML context (e.g. context.get(someID.x).

 All of this is already possible, if we assume that we handle the context
 via QVariant function arguments and resolve it on the JS side
 (someObjectInTheContext.mouseAreaClicked(mouse.x)), but it requires quite a
 lot of boiler plate code and there is no canonical well documented way how
 to exactly do this.
 Also the setting of context objects is string based and quite hard to
 track for the code model (especially if there is more then one engine in
 the project) for auto completion and code navigation.

 What problem does this solve?

 If there is a complex C++ backend there is no glue code needed anymore.
 There would be no need to expose types from C++ to QML anymore, since it
 would work the other way around. QML would expose its context to C++.
 People could work in nearly the same way as they work with .ui files.
  Typically the QML context is not very complex and only consists of a
 couple of objects, signals and state variables (e.g. currentIndex of a
 ComboBox).

 Kind Regards,
 Thomas Hartmann


This is *very* interesting.

I just wanted to re-quote that section that got me to sit up in my chair:

If there is a complex C++ backend there is no glue code needed anymore.
 There would be no need to expose types from C++ to QML anymore, since it
 would work the other way around. QML would expose its context to C++.


I'll need to think on this.  It seems to be proposing the act of QML==C++
binding is for C++ to act on signals/events forwarded to it from QML,
because C++ has all the type information (it can do the job).  I really
like that.

My current generator works well, wrapping the C++ types to expose them
natively into QML.  That also works, letting QML do the job.  However, we
then have expressions within QML (today's JS bound expressions), and as
others have said, those can sprawl and become difficult to maintain in
big/complex systems.

In general, I'd prefer to stay in C++ with my strong type information. QML
has strong typing for its internal types (which I think is essential), but
some GUI logic really needs knowledge of the domain-specific types (that's
this discussion).  I'll have to think on how much essential expression
logic is really an attribute of the GUI, and whether QML signals/events
exposed to C++ is sufficient to tool the GUI workflow.  It's certainly
different logic from the rest of the C++ system, so I'd want to separate
it (the C++ signal/event logic that services the GUI, as separate from the
C++ logic intrinsic to the large/complex back-end).

At present, I almost never write JS in my QML.  When the QML starts to get
even slightly rich-with-logic, we implement a C++ QML/GUI component to
expose to QML with knowlege-of the C++ types upon which it operates (like
custom domain-specific-controls that are then loaded as a plugin).

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtQml value types

[charleyb123 .]

 snip, use QVariant Maps to transfer property data between C++ and QML



  While your proposed approach is rather clean, it carries one drawback,
  which is the lack of type information, with all its consequences.


snip, need to convert domain-types to/from strings/doubles/QVariant on QML
side and C++ side

PRO:
*- Can data-clean/input-validate on either C++ or QML side, can add more
custom validators in different places
*- ?More fine-grain control at data-input/UI separate from back-end

CON:
*- Rules for validation now separate from domain-specific type
*- Property misspell no longer compile-caught, instead run-caught (if
validated input)
*- Must invest in this adapter-layer that may ultimately be merely a
pass-through, can be expensive to implement for big systems (many types),
or to value-copy/transform state for some rich types

 Also once you grab your data back from the QVariantMap in C++ in the
 controller you must use an accessor like .toString() etc to cast the
 QVariant to a known type, and that brings back your type checking on the
 C++ side.


For us, these are often lossy and very stale operations (converting
to/from string, double, etc. from our internal types. Dealing with hardware
and constantly changing values, it would be nice to reference the
real-item directly rather than establish an adapter layer that is (by
definition) lossy-and-stale for our use.

snip,

  A other problem i can see is the Code-Completion which you can't get for
  QVariantMap because it's a variable type which can store anything in any
  format. I think for Projects where the QML Developers know the C++
  Developers this works, but in larger Projects like having a API for
  3rdParties i think QVariantMaps doesn't work and we need to invest some
  time to make a proper solution.


Agree that QVariantMap drops type information.  Agree that loss of type
information can be an increasingly important issue in larger systems with
more domain types (because those types established rules/behaviors in the
system, and that's more important in large systems).


 Definitely, I’m not arguing against a better way / ‘proper solution’.  By
 all means lets work on that please.  I was only addressing the concern that
 you can’t use QML at all when working with large numbers of non QObject
 derived domain specific data objects.  In that respect I’d say we’re quite
 better of, at least in our project, for using QtQuick/QML over widgets.


I think there are two topics here:

(1) Deep/rich/many domain-specific C++ types (or their state/properties)
need to somehow be made available to QML through a reasonable mechanism
that scales for large C++ systems.  QVariantMap is one suggestion that
works for some systems.  IMHO, the loss of type-information is a
deal-breaker for large systems (see below), although I concede that some
people have a back-end to front-end transform, API collapse, or system
workflow where this would work.

(2) QtQuick/QML is preferred over widgets.  We agree; I realize some people
aren't sure, or currently disagree for a couple reasons.

IMHO using QVariantMap is really good when there is a strong API
collapse or transform from the very-deep-back-end-system and the
relatively-flat set of properties that should be exposed to the UI/QML.
 However, some systems are rich, and this deep-nested-type-state is
important (even through to the interface).  It becomes important to
*maintain* that nesting, and in that case, producing the
nested-QVariantMap may be expensive (and it might be big), and might be
especially difficult to describe in a granular form that supports
transactions at different levels of interface update.

Further, for our types, we have MANY derived-properties.  From one (or a
very small number) of data-members, we may have MANY properties that
are available, but these are computed-on-the-fly.  I don't want to
produce those to populate a QVariantMap if they are not really needed.
 Some hardware-reads are really expensive.

Others have touched on these, but to summarize:

(a) creation of a QVariantMap (or similar value-semantics) approaches are
investing in an adapter layer (I'd prefer to not write a bunch of
toQVariant()/fromQVariant() in my zillions of C++ classes, and it's hard
to guess the level-of-granularity to support transaction-updates at varying
levels of interface update.)

(b) the values populated in a QVariantMap are immediately stale and
lossy in our system (we drive hardware and embedded systems, or systems
with lots of dynamic updates and would prefer to reference the,
real-C++-object-thing)

(c) many of our property-values are functionally/dynamically computed,
and should not be computed unless explicitly needed.  (An example is a
class with one data member, which *is* a property, but also provides four
other properties that may be computed from that one data-member; all
five-properties should not be populated into the QVariantMap unless they
are really needed.)

In contrast, I could live 

Re: [Development] Question about Qt's future

[charleyb123 .]

Roland sayeth:

 snip, I liked the design to split business logic into
 C++ and UI design into QML and I still like it, but I came across
 several blocking issues (some of them are only valid for our
 application, some of them are general):

 - Our application has a huge framework of value classes. They cannot (or
 at least it does not make sense to) derive from QObject for several
 reasons. But subclassing QObject is the requirement to access data from
 C++ in QML. So we had our framework of well designed value classes and
 cannot use them in QML. There were evaluations to create QObject
 wrappers, but no nice solution. So no support for value classes is
 probably a show stopper for many projects. With Widgets we were able to
 use them easily.  snip


Ditto for us:  Huge network of value-classes, cannot derive from QObject.

However, integrating proprietary C++ classes to QML (both value and
reference semantics) through a code generator works great (and has other
advantages):  I did a talk on this at Qt Dev Days (San Fran) 2013, and the
slides are online:

http://www.qtdeveloperdays.com/northamerica/2013/c-object-adapter-layer-qml

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about Qt's future

[charleyb123 .]

I'm not Roland (talking about value-types), but I completely agree with
his comments on why they are important (we have that issue also).

But, jumping-in, ...

snip, from Roland,

  - Our application has a huge framework of value classes. They cannot
 (or
   at least it does not make sense to) derive from QObject for several
   reasons. But subclassing QObject is the requirement to access data
 from
   C++ in QML. So we had our framework of well designed value classes and
   cannot use them in QML. snip



  The term value classes is due to history reasons in our project. We
  started creating classes to handle physical values. Hence the name.

snip,

We call them, deep/rich types, sometimes domain-specific-abstractions,
sometimes value-types, sometimes popcorn-types (domain-specific values
that come-and-go, and typically comprise our API interfaces).

Kevin asketh:

 If you already have them as property values, what kind of operation do you
 need to do in QML that requires JS bindings for those objects?


The issue is that Real World Code almost always defines many value-types
that propagate through the interface.  They NEST.  That's the Big Deal
Thing(tm).  These typically define your APIs.  Those (existing C++) APIs
are EXACTLY what we want to (or must) expose to QML.  The values
*themselves* are typically properties, like those that you would want
exposed through QML.

For example, on our system:

  my_cytometer.laser.wavelength   // Yields Wavelength property

...In this case, none of class Cytometer nor class Laser nor class
Wavelength derive from QObject, but we want them exposed to QML.
 Including their nested properties.  Wrapping-or-deriving-from-QObject is
now required.  The Wavelength is literally an attribute of Laser, which
is an attribute of Cytometer in existing code.  We need to expose to QML
all of them:  QmlCytometer, QmlLaser, QmlWavelength

When you have hundreds of classes like this, and their relationships define
your APIs (this is C++ and strong-compile-time-typing and that's what you
are SUPPOSED to do), and NONE of these are derived from QObject, it is now
work to figure out how to expose these to QML.

No, exposing a long or double is not sufficient (you MUST expose a real
Wavelength-object to QML.  It has rules in the class, such as for
forming/parsing strings, conversion to/from RGB, and QML needs to
*reference* specific Wavelength instances in the back-end-system (and
sometimes have a value of a Wavelength instance).

And actually, the biggest-issue is the NESTING:  The Laser is an
attribute of Cytometer.  That granularity must be respected all the way
through to QML, because they comprise one-to-many and many-to-many in your
design (e.g., many Laser instances are on a single Cytometer, but a
single Laser typically has a single Wavelength, but sometimes more.)

 If I want to access this methods from QML I would have to derive them
  from QObject and register it in the QML context.

 Not necessarily, depends on what you want to do.
 However, it is true that it would be nice to have something similar to
 QtScript's binding facilities.


Agree with Roland.  Must.  I MUST have Cytometer and Laser and
Wavelength exposed to QML.

In only the simplest-of-toy-applications could we pretend that a
QmlCytometer exposed to QML has a vector-of-double values to represent
the several-wavelengths that might be associated with that cytometer.

In our system:  We code-gen to wrap everything.  Wavelength is now a QML
exposed property of Laser, which is a QML exposed property of Cytometer.

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development