On 1/22/17, 10:51 AM, "Simon Hausmann" wrote:
>Hi,
>
>I have scheduled a new build of the current master branch against qt's dev
>branch:
>
>http://testresults.qt.io/coin/integration/playground/qtremoteobjects/tasks/web_playground_qtremoteobjects_1485097792522
>
>
>5 out
From: "Stottlemyer, Brett (B.S.)" <bstot...@ford.com>
Sent: Jan 22, 2017 15:13
To: Simon Hausmann; Lars Knoll; Alistair Adams; Buddenhagen Oswald
Cc: Qt development mailing list
Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9
On 1/13/17, 3:22 AM,
On 1/13/17, 3:22 AM, "Simon Hausmann" wrote:
>I scheduled a test build in the CI against 5.8 (as dev continues to be broken).
What are the implications for feature freeze if dev is still broken?
>There are few issues:
>
>1) namespaced build doesn't work
Fixed
>2)
> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Stottlemyer,
> Brett (B.S.)
> Sent: keskiviikkona 18. tammikuuta 2017 15.50
> To: development@qt-project.org
> Subject: Re: [Development] Swi
On 1/18/17, 1:52 AM, "Tuukka Turunen" wrote:
>>
>
>When QtRO becomes part of Qt, would you continue as the maintainer of the
>module and have adequate time to polish it so that it can be fully supported
>in the upcoming Qt releases?
>
>Yours,
>
> Tuukka
Sure,
> On 16 Jan 2017, at 16:14, Oswald Buddenhagen wrote:
> On Sat, Jan 14, 2017 at 05:07:30PM +, Stottlemyer, Brett (B.S.) wrote:
>>
>> If you really did mean other object distributions systems, which ones are
>> you thinking of? Microsoft’s Component Object Model is
nt@qt-project.org
> Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for
> Qt 5.9
>
...
>
> For providing Qt new functionality, I feel the existing QtRO design is sound.
> If at some point #1 becomes a reality, I would be glad to revisit a generic
>
On 1/16/17, 10:14 AM, "Development on behalf of Oswald Buddenhagen"
wrote:
>of course, it may be that this task is too complex to get right, in
>which case qt bindings for specific systems are a more
On Sat, Jan 14, 2017 at 05:07:30PM +, Stottlemyer, Brett (B.S.) wrote:
> My interpretation was that Lars was looking for differences from a Qt user
> perspective, and I think my reply was accurate from that perspective. I
> would say you are looking at it from the s/w implementation
On 1/13/17, 10:09 AM, "Development on behalf of Oswald Buddenhagen"
wrote:
>for my taste, there are way too many inconclusive/irrelevant details in
>this description. a more layer-oriented approach
On Fri, Jan 13, 2017 at 01:58:45AM +, Stottlemyer, Brett (B.S.) wrote:
> On 12 January 2017 at 08:39, Lars Knoll wrote:
> >* 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
a
rather common thing.
Simon
From: Lars Knoll
Sent: Jan 13, 2017 08:25
To: Stottlemyer, Brett (B.S.)
Cc: Qt development mailing list
Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9
Hi Brett,
> On 13 Jan 2017, at 02:58, Stott
ng.
Simon
From: Lars Knoll
Sent: Jan 13, 2017 08:25
To: Stottlemyer, Brett (B.S.)
Cc: Qt development mailing list
Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9
Hi Brett,
> On 13 Jan 2017, at 02:58, Stottlemyer, Brett (B.S.) <bstot...
Hi Brett,
> On 13 Jan 2017, at 02:58, Stottlemyer, Brett (B.S.) wrote:
>
> On 12 January 2017 at 08:39, Lars Knoll wrote:
>
>> 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
On 12 January 2017 at 08:39, Lars Knoll wrote:
>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
> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Stottlemyer,
> Brett (B.S.)
> Sent: torstaina 12. tammikuuta 2017 3.19
> To: development@qt-project.org
> Subject: Re: [Development] Swi
On 12 January 2017 at 08:39, Lars Knoll wrote:
> Here are the criteria I think we should have (and that we IMO implicitly used
> in the past):
This smells like something we should be turning into a QUIP.
Eddy.
___
Development mailing list
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
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
> -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 Rem
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
>
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
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
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
On 1/10/17, 7:11 AM, "Development on behalf of Oswald Buddenhagen"
wrote:
>On Tue, Jan 10, 2017 at 01:42:12AM +, Stottlemyer, Brett (B.S.) wrote:
>> The processing of QObject code by repc to
On Tue, Jan 10, 2017 at 01:42:12AM +, Stottlemyer, Brett (B.S.) wrote:
> The processing of QObject code by repc to generate the .rep input file
> format was added afterwards. It allows existing Qt header files to be
> used with QtRO with compile time checks. We don’t use that feature much
>
On 1/9/17, 10:54 AM, "Development on behalf of Oswald Buddenhagen"
wrote:
>i had a quick look at the repo:
>- there is still copy of moc's c++ parser in there. not much to do about
> it at this
On Mon, Jan 09, 2017 at 02:50:52PM +, Stottlemyer, Brett (B.S.) wrote:
> As the maintainer for the Qt Remote Objects (QtRO) playground project,
> I would like to officially request moving it from a playground project
> to a Qt project.
>
i had a quick look at the repo:
- there is still copy
28 matches
Mail list logo