[Development] New Qt 5.8 rc snapshot for testing

[Jani Heikkinen]

Hi

We have new Qt 5.8.0 rc snapshot for testing

Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/720/
mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/726/
Linux: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/622/
src: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/latest_src/

All known blockers should be fixed in these packages and we are targeting to 
release Qt 5.8.0 Tue 17th January if nothing really serious found during 
testing. So please inform me immediately if there is some new blocker in the 
packages.

Please update known issues page (https://wiki.qt.io/Qt_5.8.0_Known_Issues) when 
needed as well

br,
Jani


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

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Stottlemyer, Brett (B.S.)]

On 1/10/17, 7:42 PM, "Stottlemyer, Brett (B.S.)"  wrote:



>On 1/10/17, 7:11 AM, "Development on behalf of Oswald Buddenhagen" 
>oswald.buddenha...@qt.io> wrote:
>
>>you mostly lost me here, because i just don't know enough about the data
>>flows of the qtro build system, so it would be helpful if you outlined
>>that.

...

>*QtRO will do type checking at compile time if an API gets generated from
>repc.

Maybe it is worth expanding on this a little bit.  If you are using QtRO from
the beginning of a project, the idea would be for the owner of an interface
to define the API their object will use in a .rep file.  In the .pro file,
REPC_SOURCE += someInterface.rep is added, which causes repc to generate the
Source side header file, which provides a QObject class for that API with
pure virtual methods for Slots.  The developer then inherits from the base
API class and implements the internal logic to meet the API.  Side note: 
additional Qt Signals/Slots can be added to the derived class, which aren’t
exposed to Replicas if they aren’t in the .rep file.

Anyone that wants to use this interface would add
REPC_REPLICA += someInterface
to their .pro file, which generates (you guessed it) the Replica side header
file.  It is possible to inherit from this class, but usually isn’t necessary
and the class/code can be used directly.

The reason for having moc code as part of repc is to handle the use-case of
someone having an already developed QObject type and wanting to use that
with QtRO.  I.e., a class that doesn’t derive from the auto generated
Source class.  In this case, moc is used to parse the header, and generate
the .rep for your class.  The .rep file can then be used by clients to
get Replicas.

There is another level of detail in QtRO for efficiency and type safety (see
the auto generated someInterfaceSourceAPI template in the Source header).
Feel free to look at that if you want more detail.

Regards,
Brett

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

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Marc Mutz]

Hi Brett,

On Wednesday 11 January 2017 01:42:38 Stottlemyer, Brett (B.S.) wrote:
> With this picture in mind, the key to getting it to work is to hook into
> qt_metacall and pass the invocations between processes.  This takes custom
> code, so QtRO has repc (REPlica Compiler) for this.  It reads a .rep file,
> a simple text format for describing the object’s API via Signals, Slot,
> Properties and Enums, and generates a Qt header file for the Source and
> Replica sides.  The mkspecs then add these files for moc to process.

Speaking as someone who has almost no clue about QtRO, from an engineering 
pov, it feels weird to have an easily-parsable representation of a 
QMetaObject, then generate C++ code from it, and then use moc to parse the C++ 
code to generate a QMetaObject. Wouldn't it be much simpler to generate the 
moc files directly from the rep files (maybe even at runtime, with 
QMetaObjectBuilder)?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Review needed on QFileSelector

[Lösch , Sebastian]

Hello,

I developed a patch to qt's core module to remove the necessity to have
an unused base file when only loading variants of the file using the
QFileSelector.

I am looking for someone with knowledge in QFileSelector to review my
patch on gerrit:
https://codereview.qt-project.org/#/c/175376/

Thanks in advance for any feedback.

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

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Stottlemyer, Brett (B.S.)]

On 1/11/17, 4:43 AM, "m...@kdab.com on behalf of Marc Mutz"  wrote:



>Hi Brett,
>
>On Wednesday 11 January 2017 01:42:38 Stottlemyer, Brett (B.S.) wrote:
>> With this picture in mind, the key to getting it to work is to hook into
>> qt_metacall and pass the invocations between processes.  This takes custom
>> code, so QtRO has repc (REPlica Compiler) for this.  It reads a .rep file,
>> a simple text format for describing the object’s API via Signals, Slot,
>> Properties and Enums, and generates a Qt header file for the Source and
>> Replica sides.  The mkspecs then add these files for moc to process.
>
>Speaking as someone who has almost no clue about QtRO, from an engineering 
>pov, it feels weird to have an easily-parsable representation of a 
>QMetaObject, then generate C++ code from it, and then use moc to parse the C++ 
>code to generate a QMetaObject. Wouldn't it be much simpler to generate the 
>moc files directly from the rep files (maybe even at runtime, with 
>QMetaObjectBuilder)?

Hi Marc.  I was not trying to give a comprehensive overview (that what docs
are for, right?) just trying to address Ossi’s comments.  QtRO does provide
for pushing a standard QObject out on the QtRO network and getting a “dynamic”
Replica of it without needing repc/moc.  But while this is possible, it is
a bit painful to work with.  The assumption is that the Replica is in a
different process than the QObject it represents.  The Replica will match the
API, but it needs extra plumbing and is a specific type (a mouthful,
QRemoteObjectDynamicReplica).  It can’t know anything about itself until it
gets information from QtRO about the object is should represent, and then you
need to (in code) look up the methods/properties from the runtime generated
metaobject.  There are no compile time checks against anything.  Works
reasonably well from QML, but as said, hard from C++.  The additional mkspecs
in QtRO hide the additional steps almost completely, and the generated code
provides better performance, the ability to have default values until the
connection is made, and type-safety.  Both options are available, though.

Regards,
Brett


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

[Development] Qt pi

[Edward Welbourne]

Hi all,

In the course of testing 5.8.0, I was puzzled by an example hard-coding
a value for pi, rather than re-using one from some public header as I
expected.  To my surprise, the standard library only provides M_PI as a
POSIX extension.  It turns out we do have a qmath.h that, sensibly
enough, does

#ifndef M_PI
#define M_PI (3.14159265358979323846)
#endif

Despite this, 302 other places in my Qt-dev source tree supply their own
values for pi.  There is some diversity of values.  Let's start with the
correctly-rounded ones:

3.14159
3.14159265 (enough for float - see below)
3.14159265358979
3.141592653589793 (enough for double - see below)
3.1415926535897932
3.141592653589793238
3.14159265358979323846 (same as M_PI in qmath.h)
3.1415926535897932384626433832795
3.14159265358979323846264338327950288
3.14159265358979323846264338327950288419717
3.14159265359
3.1415927

Then the truncated ones that aren't correct roundings (in each case, the
last digit needs +1):
3.1415
3.141592
3.1415926
3.1415926535
3.141592653589

Finally, the values that look suspiciously like they were meant to be
pi, but aren't (inserting a space after the last matching digit):

3.1415 2 (missing 9) In several parameters to sin(...)
3.14159 62 (last two digits swapped) In some JS benchmarks
3.14159265358979 23846 (missing 3) In an ECMA JS test

I am fairly sure the parameters to sin were meant to use pi; and I
suspect changing the JS tests is out-of-scope as they look like imports
(i.e. third-party).

Wikipedia gives the following first 49 digits (followed by a 0):

3.1415926535897932384626433832795028841971693993751

Experiment with gcc on 64-bit Intel reveals that there is no point
supplying more than the following digits, for each type:

long double: 3.1415926535897932385
 double: 3.141592653589793
  float: 3.1415927

So our M_PI is almost good.  It coincides with what Linux's 
provides, except that we put parentheses round it - can anyone give me a
good reason for that ?  I doubt it matters.  However, neither M_PI puts
an L suffix on it, so its last four digits are effectively ignored
(because a floating literal is double by default).

It looks like it would make sense to:

i) Change qmath.h's M_PI to (3.14159265358979323846L)
   i.e. make it a long double, let context downgrade it as needed

ii) Change all other hand-crafted approximations to use M_PI.

Can anyone offer me a sane reason to not do this ?
We have have little arithmetic irregularities creeping in from our
inconsistencies ...

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

Re: [Development] Qt pi

[Lars Knoll]

Hi Eddy,

plan sounds good, just go ahead :)

Cheers,
Lars

> On 11 Jan 2017, at 15:35, Edward Welbourne  wrote:
> 
> Hi all,
> 
> In the course of testing 5.8.0, I was puzzled by an example hard-coding
> a value for pi, rather than re-using one from some public header as I
> expected.  To my surprise, the standard library only provides M_PI as a
> POSIX extension.  It turns out we do have a qmath.h that, sensibly
> enough, does
> 
> #ifndef M_PI
> #define M_PI (3.14159265358979323846)
> #endif
> 
> Despite this, 302 other places in my Qt-dev source tree supply their own
> values for pi.  There is some diversity of values.  Let's start with the
> correctly-rounded ones:
> 
> 3.14159
> 3.14159265 (enough for float - see below)
> 3.14159265358979
> 3.141592653589793 (enough for double - see below)
> 3.1415926535897932
> 3.141592653589793238
> 3.14159265358979323846 (same as M_PI in qmath.h)
> 3.1415926535897932384626433832795
> 3.14159265358979323846264338327950288
> 3.14159265358979323846264338327950288419717
> 3.14159265359
> 3.1415927
> 
> Then the truncated ones that aren't correct roundings (in each case, the
> last digit needs +1):
> 3.1415
> 3.141592
> 3.1415926
> 3.1415926535
> 3.141592653589
> 
> Finally, the values that look suspiciously like they were meant to be
> pi, but aren't (inserting a space after the last matching digit):
> 
> 3.1415 2 (missing 9) In several parameters to sin(...)
> 3.14159 62 (last two digits swapped) In some JS benchmarks
> 3.14159265358979 23846 (missing 3) In an ECMA JS test
> 
> I am fairly sure the parameters to sin were meant to use pi; and I
> suspect changing the JS tests is out-of-scope as they look like imports
> (i.e. third-party).
> 
> Wikipedia gives the following first 49 digits (followed by a 0):
> 
> 3.1415926535897932384626433832795028841971693993751
> 
> Experiment with gcc on 64-bit Intel reveals that there is no point
> supplying more than the following digits, for each type:
> 
> long double: 3.1415926535897932385
> double: 3.141592653589793
>  float: 3.1415927
> 
> So our M_PI is almost good.  It coincides with what Linux's 
> provides, except that we put parentheses round it - can anyone give me a
> good reason for that ?  I doubt it matters.  However, neither M_PI puts
> an L suffix on it, so its last four digits are effectively ignored
> (because a floating literal is double by default).
> 
> It looks like it would make sense to:
> 
> i) Change qmath.h's M_PI to (3.14159265358979323846L)
>   i.e. make it a long double, let context downgrade it as needed
> 
> ii) Change all other hand-crafted approximations to use M_PI.
> 
> Can anyone offer me a sane reason to not do this ?
> We have have little arithmetic irregularities creeping in from our
> inconsistencies ...
> 
>   Eddy.
> ___
> 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 pi

[Edward Welbourne]

Lars Knoll:
> plan sounds good, just go ahead :)

I've opened QTBUG-58083 for the sake of tracking it.
Anyone with further comments is welcome to look there.
On IRC, peppe has pointed out using L may get narrowing warnings from some 
compilers.
So I'll start with using M_PI and Math.PI more widely.

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

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Oswald Buddenhagen]

On Wed, Jan 11, 2017 at 12:42:38AM +, Stottlemyer, Brett (B.S.) wrote:
> I guess to start off, I don’t consider QtRO to be a RPC mechanism.
> In my mind, RPC would be akin to exposing a QObject’s slots for calling
> individually.  With QtRO (which only works Qt to Qt, it isn’t currently
> available to other “languages”, like ruby/python/etc.) you talk QObjects.
> 
technically speaking, it's a distributed object system (which puts it
into the same category as CORBA), but the underlying mechanism is still
rpc.

> At some level, I see the .rep format as an extreme of a Q_OBJECT definition
> in that only the “API” is defined (property, signal, slot, enum), and
> everything else is private/pimpl.
>
yes, that makes .rep an idl format.

> >but my naive understanding of rpc implementations is that you actually
> >want to create some idl (is this what .rep is about?) from the c++, and
> >in a later step compile that into stubs and skeletons. the former sounds
> >like a task moc could do as a side effect, while the latter is for repc.
> 
> I see it as the opposite for QtRO.  The .rep defines the API, repc creates
> the Qt headers for the types,
>
i'm not sure how it's the opposite, when you effectively confirmed what
i speculated.

> then moc generates the code based on the headers.
> 
that's just a rather convoluted way to achieve the same, as marc noted
as well.

> I don’t want to miss the deadline for feature freeze, so I’m hoping to
> get past that hurdle and address some of your proposals afterwards as
> a tech preview.
> 
that seems a bit optimistic, given that we're discussing some rather
fundamental aspects of the design.

also, i don't think we've been bothering a lot about deadlines for TP
modules, so who cares.

> As a playground project I think we haven’t gotten a lot of attention
> from The Qt Company and I really do welcome that.
>
from experience, this isn't going to change. it's on you to reach out
(preferably without imposing a deadline).
it's your project, and it will be released in whatever state it is when
you deem it ready.

and if later somebody else with resources suddenly finds it interesting
but finds it to suck a lot, there will be struggling to get it into
shape, or to get rid of it again, to push for a better solution. we've
been there before.

it doesn't help that you apparently haven't even explored the prior art
within qt even though it was pointed out to you two years ago already.

> The repc tool specifically is kind of in a weird spot.  I’m not sure
> there are any other tools that are bootstrapped and aren’t in qtbase.
> Should repc* not be bootstrapped?  Alternatively, should it be part of
> qtbase (so moc doesn’t need to be “3rdParty”)?  Until QtRO is promoted
> to a Qt module, I don’t think these questions can really be answered.
> 
there is nothing extraordinary about repc from the buildsystem
perspective.
there are some things to fix, but this is not place to discuss them.
other paragraphs are concerned with the duplication of moc.

> >>*QtRO will do type checking at compile time if an API gets generated from
> >>repc.
> 
> Maybe it is worth expanding on this a little bit.  [...]
>
afaict, you just described *precisely* what qdbuscpp2xml and
qdbusxml2cpp do, except that you decided to put both tools into one
executable.

the part that is shared with moc is the c++ parser, and as expressed in
the previous mail, the hope is to get rid of that entirely in favor of
clang.

that leaves us with extracting the relevant meta data from the AST, the
intermediate storage of the meta data (the idl), and the code generator.
this is all relatively little code, so sharing *as such* doesn't seem
too useful. however, it's quite ineffcient that the c++ parsing is done
multiple times, so a unified meta data processing pipeline appears
preferable:
- moc parses the c++ to create an idl file that contains all qt-specific
  meta data (what it should extract and how it should represent it can
  be declared in the headers it includes, so in principle it's possible
  to make it quite generic)
- alternatively, the user provides the idl file (both qtro and qtdbus
  support that already)
- the idl file is fed to various code generators
- the code generated by repc is not fed back into moc for parsing from
  scratch, but instead repc creates a modified idl which is fed directly
  into the moc code generator
  - come to think of it, qtdbus also has *precisely the same* problem
(see qtbase/mkspecs/features/dbus*). you really managed to replicate
it down to its warts. ;)

a concrete action point would be exploring in how far it's possible (and
actually sensible) to design a shared meta data representation (idl).
qtdbus' xml is horrible (of course it is), but it's easy to process.
repc's "proper" idl is the exact opposite ...

ah, yeah, qtsystems. have a look and report. ;)

just some food for thought. ;)

___
Development mailing list
Development@qt-proje

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Tuukka Turunen]

> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Oswald
> Buddenhagen
> Sent: keskiviikkona 11. tammikuuta 2017 18.50
> To: development@qt-project.org
> Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for
> Qt 5.9
> 
> > I don’t want to miss the deadline for feature freeze, so I’m hoping to
> > get past that hurdle and address some of your proposals afterwards as
> > a tech preview.
> >
> that seems a bit optimistic, given that we're discussing some rather
> fundamental aspects of the design.
> 
> also, i don't think we've been bothering a lot about deadlines for TP modules,
> so who cares.
> 

As this is a module to be added, we need to have it in place latest at the FF. 
Preferably modules should be in place earlier than FF.

The criteria for the content of the module is of course less strict when it is 
a TP, but still if it is likely to need full refactoring perhaps waiting for 
5.10 is a better option?

Yours,

Tuukka

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

Re: [Development] [root_ptr] GC + Automatic Reference Counting

[Phil Bouchard]

On 01/10/2017 06:46 PM, Phil Bouchard wrote:

Greetings,

To go back on the main subject, it came to my attention that Apple is
using mostly "Automatic Reference Counting" since 2011:
https://en.wikipedia.org/wiki/Automatic_Reference_Counting

The good news is it's not using the GC which makes the OS hangs once in
a while but the bad news is it still suffers from cyclic references
which I don't think is acceptable for the software industry nowadays.
This means the Apple OS leaks.

root_ptr clearly stands apart, hands down.  I just did my research
regarding all aspects, objectively, in order to mold the best memory
manager ever and I welcome any objection.  I am also glad the
boost::fast_pool_allocator does such a great job in the user space.


Moreover I will try part of the following kernel level memory manager 
sooner or later:

https://github.com/tempesta-tech/tempesta

At the same time I was just wondering what is the next step?  I am 
obviously trying to get this library part of the Boost library but for 
that I need a review manager:

http://www.boost.org/community/reviews.html#Review_Manager

So any volunteer is most welcome.  It would be subjective to say there 
is no demand in that area given the state of the art in the IT industry 
like previously mentioned.


Also I did compare popular pool allocators and once again I find that 
the boost::fast_pool_allocator stands out.


Lastly I find this subject really interesting and I'm sure I'm not the 
only one so I wish I can help while I still have some free time available.



Sincerely,
-Phil

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

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Stottlemyer, Brett (B.S.)]

On 1/11/17, 11:50 AM, "Development on behalf of Oswald Buddenhagen" 
 wrote:


>> >but my naive understanding of rpc implementations is that you actually
>> >want to create some idl (is this what .rep is about?) from the c++, and
>> >in a later step compile that into stubs and skeletons. the former sounds
>> >like a task moc could do as a side effect, while the latter is for repc.
>> 
>> I see it as the opposite for QtRO.  The .rep defines the API, repc creates
>> the Qt headers for the types,
>>
>i'm not sure how it's the opposite, when you effectively confirmed what
>i speculated.

To clarify, I simply meant that you described c++ -> idl, while the normal
process for QtRO is idl -> c++.

>> I don’t want to miss the deadline for feature freeze, so I’m hoping to
>> get past that hurdle and address some of your proposals afterwards as
>> a tech preview.
>> 
>that seems a bit optimistic, given that we're discussing some rather
>fundamental aspects of the design.

This is a bit dramatic, isn’t it?  Unless I misinterpret, you are not
suggesting the generated code change, just the process for generating it.
As such, it would seem that any change would be a drop-in replacement, so
I don’t see any criticality to the timing, especially for a TP module.

It also seems like your main objection is the use of moc, which is (as
I’ve already said) an edge case.  If this is the key sticking point, I
can drop support for converting QObjects to .rep files and remove moc
from the repo.

>also, i don't think we've been bothering a lot about deadlines for TP
>modules, so who cares.

Apparently Tuukka does, since he’s suggesting holding off until 5.10...

>it doesn't help that you apparently haven't even explored the prior art
>within qt even though it was pointed out to you two years ago already.

Looking again now, I believe you are talking about Qt Service Framework.  It
does look familiar, so I probably looked at it and discarded it as solving a
separate problem, then forgotten I’d looked.

Top hits on google are

https://blog.qt.io/blog/2009/05/26/qt-service-framework/
https://doc-snapshots.qt.io/qt-mobility/service-frameworks.html

And
https://wiki.qt.io/Service_Framework_API


It provides platform specific implementations of services/daemons with a
common Qt API.  “Once the service has been identified the framework starts
the service and returns a pointer to it.”  This isn’t the use-case I’m
trying to solve.  It doesn’t work between platforms (like QtRO does with
the tcp/ip backend), doesn’t support Q_PROPERTY, doesn’t support default
values, and assumes services can be started from any user code.  It is RPC,
not a distributed object system.  I don’t consider it “prior art”, except
at a "rectangular device with rounded corners" kind of level.

>afaict, you just described *precisely* what qdbuscpp2xml and
>qdbusxml2cpp do, except that you decided to put both tools into one
>executable.

Right, I DO consider the dbus code to be prior art, in that is solves a
very similar problem, so I leveraged the pieces that I could.

>the part that is shared with moc is the c++ parser, and as expressed in
>the previous mail, the hope is to get rid of that entirely in favor of
>clang.
>
>that leaves us with extracting the relevant meta data from the AST, the
>intermediate storage of the meta data (the idl), and the code generator.
>this is all relatively little code, so sharing *as such* doesn't seem
>too useful. however, it's quite ineffcient that the c++ parsing is done
>multiple times, so a unified meta data processing pipeline appears
>preferable:
>- moc parses the c++ to create an idl file that contains all qt-specific
>  meta data (what it should extract and how it should represent it can
>  be declared in the headers it includes, so in principle it's possible
>  to make it quite generic)
>- alternatively, the user provides the idl file (both qtro and qtdbus
>  support that already)
>- the idl file is fed to various code generators
>- the code generated by repc is not fed back into moc for parsing from
>  scratch, but instead repc creates a modified idl which is fed directly
>  into the moc code generator
>  - come to think of it, qtdbus also has *precisely the same* problem
>(see qtbase/mkspecs/features/dbus*). you really managed to replicate
>it down to its warts. ;)
>
>a concrete action point would be exploring in how far it's possible (and
>actually sensible) to design a shared meta data representation (idl).
>qtdbus' xml is horrible (of course it is), but it's easy to process.
>repc's "proper" idl is the exact opposite ...

Is it reasonable to assert that all of the above should either be needed for
both QtRO and QtDbus or neither?  If so, I’ll drop the moc support from QtRO
and re-add it once the above is done for qtdbus. 

>ah, yeah, qtsystems. have a look and report. ;)

See above.

>just some food for thought. ;)

Appreciated.  With removal of moc, can we proceed as a Tech Preview in 5.9?

Regards,
Brett

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Lars Knoll]

I didn't find time to have a more detailed look at the code so far, but hope to 
get to it over the weekend.

But in general I think we need to put the bars for becoming a TP at the right 
level. It's not a fully supported module yet, and we put it out especially to 
collect feedback. So it doesn't have to be 100% at the same level as supported 
modules. Here are the criteria I think we should have (and that we IMO 
implicitly used in the past):

* The module solves a problem our users have
  - It either implements new and so far non existent functionality
  - Or it solves an existing problem in a new and better way (and is intended 
to replace the old functionality over time)
* The module builds inside the Qt build system on all platforms
- Compilation could be disabled on some platforms, but is not allowed to 
break any platform we support
* The module is CI controlled
* There is a decent set of automated tests covering the main functionality and 
most of the API of the module
  - The tests pass on all platforms where the module is supported
* APIs have been reviewed, and we are reasonably satisfied with them (we've 
done larger changes to APIs after TPs before)
* Architecture makes sense
* It follows the Qt coding style and conventions
* Implementation has been checked for sanity
  - It's ok to have parts that are flagged as needing further work (those have 
to be fixed before moving from TP to supported state)

IMO that should cover most of the needs and demands we should have for new 
modules before offering them as a TP.

From the discussion so far I didn't hear too many things that speak against a 
TP, the code duplication with moc is one of the issues that fall into the 
'flagged and need to be resolved before moving out of TP' category for me. How 
about the other points in the list above that haven't been discussed yet here?

Cheers,
Lars

On 12 Jan 2017, at 02:19, Stottlemyer, Brett (B.S.) 
mailto:bstot...@ford.com>> wrote:

On 1/11/17, 11:50 AM, "Development on behalf of Oswald Buddenhagen" 
mailto:development-bounces+bstottle=ford@qt-project.org>
 on behalf of oswald.buddenha...@qt.io> wrote:


but my naive understanding of rpc implementations is that you actually
want to create some idl (is this what .rep is about?) from the c++, and
in a later step compile that into stubs and skeletons. the former sounds
like a task moc could do as a side effect, while the latter is for repc.

I see it as the opposite for QtRO.  The .rep defines the API, repc creates
the Qt headers for the types,

i'm not sure how it's the opposite, when you effectively confirmed what
i speculated.

To clarify, I simply meant that you described c++ -> idl, while the normal
process for QtRO is idl -> c++.

I don’t want to miss the deadline for feature freeze, so I’m hoping to
get past that hurdle and address some of your proposals afterwards as
a tech preview.

that seems a bit optimistic, given that we're discussing some rather
fundamental aspects of the design.

This is a bit dramatic, isn’t it?  Unless I misinterpret, you are not
suggesting the generated code change, just the process for generating it.
As such, it would seem that any change would be a drop-in replacement, so
I don’t see any criticality to the timing, especially for a TP module.

It also seems like your main objection is the use of moc, which is (as
I’ve already said) an edge case.  If this is the key sticking point, I
can drop support for converting QObjects to .rep files and remove moc
from the repo.

also, i don't think we've been bothering a lot about deadlines for TP
modules, so who cares.

Apparently Tuukka does, since he’s suggesting holding off until 5.10...

it doesn't help that you apparently haven't even explored the prior art
within qt even though it was pointed out to you two years ago already.

Looking again now, I believe you are talking about Qt Service Framework.  It
does look familiar, so I probably looked at it and discarded it as solving a
separate problem, then forgotten I’d looked.

Top hits on google are

https://blog.qt.io/blog/2009/05/26/qt-service-framework/
https://doc-snapshots.qt.io/qt-mobility/service-frameworks.html

And
https://wiki.qt.io/Service_Framework_API


It provides platform specific implementations of services/daemons with a
common Qt API.  “Once the service has been identified the framework starts
the service and returns a pointer to it.”  This isn’t the use-case I’m
trying to solve.  It doesn’t work between platforms (like QtRO does with
the tcp/ip backend), doesn’t support Q_PROPERTY, doesn’t support default
values, and assumes services can be started from any user code.  It is RPC,
not a distributed object system.  I don’t consider it “prior art”, except
at a "rectangular device with rounded corners" kind of level.

afaict, you just described *precisely* what qdbuscpp2xml and
qdbusxml2cpp do, except that you decided to put both tools into one
executable.

Right, I DO consi