Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-17 Thread Shawn Rutledge 

> On 17 Jan 2017, at 14:29, Edward Welbourne  wrote:
> One branch is dead but should perhaps be archived (i.e. moved to an
> out-of-sight namespace): wip/tizen (qtdeclarative, qtsensors,
> qtquickcontrols, qtbase).

This was brought up before… Tizen still exists and Qt should still be able to 
run on it, IMO, supported or not.  So if the work was not finished, why kill it 
and have to start over later on?

Otherwise someone had better archive it.  Ideally the archive should be 
accessible too.

>  wip/qt5-nativetext (qtquickcontrols) 2012/Jul, Eskil Abrahamsen Blomfeldt
>  wip/animation-refactor (qtdeclarative) 2012/Jan, Michael Brasser
> 
>  wip/qa (qtlocation) 2011/Aug, shubinba 
>  wip/v8 (qtscript) 2011/Jul, Peter Varga
>  wip/experimental_scenegraphing (qtlocation) 2011/Jun, juhvu 
> 
>  wip/statemachine (qtdeclarative) 2011/Jun, Michael Brasser 
> 
>  wip/textng (qtdeclarative) 2011/Jun, Yann Bodson 
>  wip/visuallistmodel (qtdeclarative) 2011/Jun, Andrew den Exter 
> 

Yeah sounds like I’d better look at a few of those.

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

[Development] [SUGGESTION] (QTIFW-916) Distribute CMake tools as part of the QtSDK

2017-01-17 Thread Konstantin Podsvirov 
Maybe it's someone who is interesting, or someone wants to help with the implementation.Link:https://bugreports.qt.io/browse/QTIFW-916--Best Regards,Konstantin Podsvirov
___
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

2017-01-17 Thread Tuukka Turunen 


> -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 4.52
> To: Oswald Buddenhagen ;
> development@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 
> idl.
> 

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


> Regards,
> 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] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

2017-01-17 Thread Stottlemyer, Brett (B.S.) 
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 plausible
>approach. i think this is actually what we already do with activeqt.
>but then the question forces itself why you had to create *yet another*
>distributed object system instead of wrapping an existing one. yes, easy
>type handling. see below.

The crux of the matter, in my opinion, boils down to a couple of things.

1) Creating a wire-format that works with other languages is a much bigger
undertaking, and one that would need to be integrated into Qt itself, not
QtRO.  Based on the (lack of) response from others, it seems this is not
a palatable change at this time.

2) A Qt-to-Qt distributed object system can provide a rich set of features
leveraging Qt’s existing capabilities, without requiring a lot of additional
code by the user.  Such a system doesn’t currently exist in Qt, would
provide value, and thus the request to move QtRO out of the playground.
*yet another* isn’t relevant unless you want to delve back into the wire-
format side of this discussion (#1).

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
idl.

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

Re: [Development] Qt 5.8: ICU vs. iconv

2017-01-17 Thread René J . V . Bertin 
Thiago Macieira wrote:

> It should have been possible to enable Iconv for QTextCodec and let ICU be
> used for QCollator and QTimeZone. Looks like we forgot. But no, please use ICU
> instead of iconv anyway.

OK, one external dependency to handle everything, makes sense, thanks.

R.

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

Re: [Development] Qt 5.8: ICU vs. iconv

2017-01-17 Thread Thiago Macieira 
On terça-feira, 17 de janeiro de 2017 22:02:12 PST René J.V. Bertin wrote:
> Hi,
> 
> Another quick question: I understand it is no longer possible to configure
> Qt to use both iconv and ICU as I've always done (possible without
> effect?). Given that neither of the 3 supported iconv variants is accepted
> when ICU is used I take it that ICU is the preferred alternative.
> 
> Is that correct, across all platforms?

Yes, ICU is preferred.

It should have been possible to enable Iconv for QTextCodec and let ICU be 
used for QCollator and QTimeZone. Looks like we forgot. But no, please use ICU 
instead of iconv anyway.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

[Development] Qt 5.8: ICU vs. iconv

2017-01-17 Thread René J . V . Bertin 
Hi,

Another quick question: I understand it is no longer possible to configure Qt 
to use both iconv and ICU as I've always done (possible without effect?).
Given that neither of the 3 supported iconv variants is accepted when ICU is 
used I take it that ICU is the preferred alternative.

Is that correct, across all platforms?

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

[Development] QWidget::setWindowState(Qt::WindowStates) vs QWindow::setWindowState(Qt::WindowState)

2017-01-17 Thread Thomas Søndergaard 
Hi,

I'm looking at the Qt code with intention to fix it so this code

QWidget widget;
widget.setWindowState(Qt::WindowMaximized);
widget.showMinized();

will show the window iconified and when the user (or program) unminimize
the window it pops up maximized. This is currently not possible (QTBUG-57882
).

I've been trying to read the Qt code and it seems to me the problem is that
QWindow::setWindowState(Qt::WindowState) and
QPlatformWindow::setWindowState(Qt::WindowState) only take a
Qt::WindowState argument not a Qt::WindowStates argument. This seems to
make it impossible to set the correct state on the windows-system window.

Is this intentional or a known issue?

I would be happy to get suggestions for how this is best fixed.

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

Re: [Development] config.summary in Qt 5.8?

2017-01-17 Thread René J . V . Bertin 
Kevin Funk wrote:

> -> https://bugreports.qt.io/browse/QTBUG-56225
> -> https://codereview.qt-project.org/#/c/180823/

> Apply the patch and check, I'd say.
> 
> Hope that helps :)

Yep, it did, thanks :)

R.

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

Re: [Development] config.summary in Qt 5.8?

2017-01-17 Thread Kevin Funk 
On Tuesday, 17 January 2017 18:49:40 CET René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > No, only for 5.8.1.
> > 
> > For 5.8.0, config.log will have to do.
> 
> Hmmm, I saw the buildsystem got quite a bit of an overhaul so I'm not
> surprised. (I *will* be surprised if all my little hacks continue to
> work...)
> 
> Maybe the patch to reintroduce config.summary is already available somewhere
> for local backporting?

In Google: '"config.summary" qtbase 5.8'

-> https://bugreports.qt.io/browse/QTBUG-56225
-> https://codereview.qt-project.org/#/c/180823/

> Either way I suppose that the new config.summary will have to same layout as
> what configure prints at the end, so won't compare side-by-side to the
> summaries of previous versions?

Apply the patch and check, I'd say.

Hope that helps :)

Cheers,
Kevin

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


-- 
Kevin Funk | kf...@kde.org | http://kfunk.org

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] config.summary in Qt 5.8?

2017-01-17 Thread Thiago Macieira 
Em terça-feira, 17 de janeiro de 2017, às 18:49:40 PST, René J. V. Bertin 
escreveu:
> Thiago Macieira wrote:
> > No, only for 5.8.1.
> > 
> > For 5.8.0, config.log will have to do.
> 
> Hmmm, I saw the buildsystem got quite a bit of an overhaul so I'm not
> surprised. (I *will* be surprised if all my little hacks continue to
> work...)
> 
> Maybe the patch to reintroduce config.summary is already available somewhere
> for local backporting?

Yes, 47784b4352351f042d1e3b61e7151cdcc7c0bac1.

> Either way I suppose that the new config.summary will have to same layout as
> what configure prints at the end, so won't compare side-by-side to the
> summaries of previous versions?

No, I don't think so.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] config.summary in Qt 5.8?

2017-01-17 Thread René J . V . Bertin 
Thiago Macieira wrote:

> No, only for 5.8.1.
> 
> For 5.8.0, config.log will have to do.

Hmmm, I saw the buildsystem got quite a bit of an overhaul so I'm not 
surprised. 
(I *will* be surprised if all my little hacks continue to work...)

Maybe the patch to reintroduce config.summary is already available somewhere 
for 
local backporting?

Either way I suppose that the new config.summary will have to same layout as 
what configure prints at the end, so won't compare side-by-side to the 
summaries 
of previous versions?

R.

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

Re: [Development] config.summary in Qt 5.8?

2017-01-17 Thread Thiago Macieira 
Em terça-feira, 17 de janeiro de 2017, às 17:40:17 PST, René J.V. Bertin 
escreveu:
> Hi,
> 
> Trying the current 5.8.0-rc tarball I notice that the configure step no
> longer creates a config.summary file, while it still prints out the
> summary.
> 
> Will this be brought back in the final release? I found it very handy...

No, only for 5.8.1.

For 5.8.0, config.log will have to do.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Calendar Systems proposal

2017-01-17 Thread Thiago Macieira 
Em terça-feira, 17 de janeiro de 2017, às 10:22:57 PST, Edward Welbourne 
escreveu:
> Jake Petroules
> 
> > Eddy, "draft" does not do what you think it does. This is why no one can
> > see the change.
> I think you are addressing the wrong person.
> Soroush created the review (as a draft) and added me as a reviewer.
> That enabled me to add Frederic.
> 
> > Please remove "draft" status and add "WIP: " at the front of the commit
> > message instead so we can all take a look.
> It already has WIP: on its commit message.
> 
> Soroush: please push your next patch set to refs/for/dev, to make the review
> public. Subsequent pushes can be to refs/drafts/dev if you like, to make
> clear it's all still a draft.

People not added to the reviews will not see them.

Don't use refs/drafts for anything you want other people to see.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] invokeMethod() with function pointers

2017-01-17 Thread Thiago Macieira 
Em terça-feira, 17 de janeiro de 2017, às 11:21:56 PST, Grégoire Barbier 
escreveu:
> And maybe lambdas too, if there was a way to choose the thread/eventloop
> in which we want the lambda to be executed (but christmas was a few
> weeks ago, I should not dream ;-)).

If we do this, it should be possible to write:

QMetaObject::invokeMethod(object, [=]() { 
doSomething(); return something; },
Qt::BlockingQueuedConnection,
Q_RETURN_ARG(foo));

Since we have lambdas and std::bind, I don't see the point of supporting 
passing arguments. The return value is interesting still.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

[Development] config.summary in Qt 5.8?

2017-01-17 Thread René J . V . Bertin 
Hi,

Trying the current 5.8.0-rc tarball I notice that the configure step no longer 
creates a config.summary file, while it still prints out the summary.

Will this be brought back in the final release? I found it very handy...

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

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-17 Thread Edward Welbourne 
I wrote:
> Which reminds me, back in August I investigated then-current wip/s:
> http://lists.qt-project.org/pipermail/development/2016-August/026859.html

and Ossi brought git fetch's -p option to my attention.
Most of those mentioned before are still here, but:

> Two branches (only in qtbase) are done with and can be killed:
> wip/qstring-utf8
> wip/lite

wip/qstring-utf8 is already gone.

> I also observe wip/qtquickintergration in qt3d, which is clearly a typo
> for wip/qtquickintegration (which contains every commit of the typo-ed
> version).

This one has already been removed.

> Here's the list of all (other) currently live wip/s (in which modules)
> with date and author of the tip commit (on whichever module that's most
> recent):
[...]
>  wip/44-based (qtwebengine) 2015/Jul, Allan Sandfeld Jensen

This one is also gone.
All others are as described ...

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

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-17 Thread Pierre-Yves Siret 
Not really related to all the branch business going on, but I want to say
i'd gladly help and participate in this WIP, wherever that takes place.

2017-01-14 17:06 GMT+01:00 J-P Nurmi :

> Hi,
>
> Nice, looks great! It would be a very welcome contribution. We could
> polish and add the missing bits in the WIP branch if you’re interested? I
> haven’t thought about the exact details and requirements for
> SortFilterProxyModel yet, but we probably need to support multiple model
> columns. The plan is to make the new TableView support both, “proper” table
> models with multiple columns, and the old way of (ab)using roles as
> columns. :)
>
> --
> J-P Nurmi
>
> On 14 Jan 2017, at 14:06, Pierre-Yves Siret  wrote:
>
> Hi,
> I started implementing SortFilterProxyModel cause we needed it and
> published it here : https://github.com/oKcerG/SortFilterProxyModel
> For the moment it is not really documented or tested enough.
> I left it kinda alone for the past couple months but I plan to do more
> work on it, documenting, testing, adding some features and doing some
> refactoring.
> I also wanted to nominate it as a TP for 5.10.
> I guess it needs to be reworked before a potential inclusion in Qt (pimpl,
> using private headers from QAIM and ItemViews, etc.).
>
> I think what's interesting in my library is the ability to have multiple
> filters and sorters declaratively (as shown in the 2nd more advanced
> usecase of the readme), I also have a branch that I haven't pushed yet
> where you could define new roles defined from existing source roles.
>
> Where you thinking of that for the SortFilterProxyModel you wanted ?
>
> One of the shortcoming of my SFPM is that it is not really meant to be
> used for multiple columns, only roles, and it doesn't support tree models.
>
> Pierre-Yves Siret
>
> 2017-01-14 13:37 GMT+01:00 J-P Nurmi :
>
>> Hi,
>>
>> I'd like to request a WIP branch for the Qt Quick item views. There are
>> plenty of items on the roadmap/wishlist:
>>
>> - refactor QQuickItemView
>>   - add support for multiple delegate types (QTBUG-26681)
>>   - add support for multi-selection
>>   - add support for multiple columns
>> - implement TableView (QTBUG-51710)
>> - implement HeaderView
>> - implement SortFilterProxyModel
>> - productize TreeModelAdaptor (QTBUG-54390)
>>
>> Early feedback from the CI system would be invaluable.
>>
>> --
>> J-P Nurmi
>>
>>
>> ___
>> 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] Branch request: wip/itemviews in qtdeclarative

2017-01-17 Thread Edward Welbourne 
Oswald Buddenhagen:
> speaking of how hard is to get branches: the policy is quite clear that
> done (and abandoned) branches should be deleted (or moved to a hidden
> namespace, if you insist on archiving your throw-away branch). they
> aren't, they are piling up. what exactly do you expect in return?

Which reminds me, back in August I investigated then-current wip/s:
http://lists.qt-project.org/pipermail/development/2016-August/026859.html

Two branches (only in qtbase) are done with and can be killed:
wip/qstring-utf8
wip/lite

One branch is dead but should perhaps be archived (i.e. moved to an
out-of-sight namespace): wip/tizen (qtdeclarative, qtsensors,
qtquickcontrols, qtbase).

I also observe wip/qtquickintergration in qt3d, which is clearly a typo
for wip/qtquickintegration (which contains every commit of the typo-ed
version).

Ossi, would you take care of those ?


Here's the list of all (other) currently live wip/s (in which modules)
with date and author of the tip commit (on whichever module that's most
recent):

  wip/animation (qt3d) 2017/Jan, Sean Harmer
  wip/pointerhandler (qtdeclarative) 2017/Jan, Shawn Rutledge
  wip/qtquickintegration (qt3d) 2017/Jan, Sean Harmer
  wip/scenegraphng (qtdeclarative) 2017/Jan, Laszlo Agocs

  wip/qbs (qtbase) 2016/Dec,  Christian Kandeler
  wip/qtwebkit/next (qt5) 2016/Oct, Konstantin Tokarev
  wip/particles (qt3d) 2016/Sep, Liang Qi
  wip/next (qtwebkit) 2016/Aug, Liang Qi
  wip/remac (qtbase) 2016/Aug, Jan Arve Saether
  wip/nacl (qtbase, qtdeclarative) 2016/Jul, Gabriel de Dietrich
  wip/speech-recognition (qtspeech) 2016/Apr, Frederik Gladhorn

  wip/win (qtconnectivity) 2015/Dec, Alex Blasche
  wip/network-test-server (qtbase) 2015/Oct, me
  wip/dbus (qtdeclarative) 2015/Oct, Sérgio Martins
  wip/47-based (qtwebengine) 2015/Oct, Allan Sandfeld Jensen
  wip/mir (qtbase) 2015/Aug, Paul Olav Tvete; Canonical wanted it in 2016/Aug
  wip/highdpi (qtbase) 2015/Jul, Paul Olav Tvete; probably dead ?
  wip/44-based (qtwebengine) 2015/Jul, Allan Sandfeld Jensen
  wip/threading (qtcanvas3d) 2015/Jul, Miikka Heikkinen

  wip/gc (qtdeclarative) 2014/Apr, Thiago Macieira
  wip/calendar (qtquickcontrols) 2014/Feb, Mitch Curtis

  winrt (qtbase) 2013/Sep,  Andrew Knight 
  wip/winrt (qttools) 2013/Aug, Andrew Knight 
  wip/android (qtscript, qtdoc, qtimageformats, qtquick1,
   qtgraphicaleffects) 2013/Feb, Eskil Abrahamsen Blomfeldt

  wip/qt5-nativetext (qtquickcontrols) 2012/Jul, Eskil Abrahamsen Blomfeldt
  wip/animation-refactor (qtdeclarative) 2012/Jan, Michael Brasser

  wip/qa (qtlocation) 2011/Aug, shubinba 
  wip/v8 (qtscript) 2011/Jul, Peter Varga
  wip/experimental_scenegraphing (qtlocation) 2011/Jun, juhvu 

  wip/statemachine (qtdeclarative) 2011/Jun, Michael Brasser 

  wip/textng (qtdeclarative) 2011/Jun, Yann Bodson 
  wip/visuallistmodel (qtdeclarative) 2011/Jun, Andrew den Exter 


and I am naturally suspicious of those whose last commit is from an
e-mail @nokia, all from 2011; these sound suspiciously dead.
Please review those you know anything about ... especially the old ones.

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

Re: [Development] invokeMethod() with function pointers

2017-01-17 Thread Edward Welbourne 
Grégoire Barbier:
> Kind of Qt::DirectOrBlockingQueuedConnection.

Blocking_DirectOrQueued_Connection, surely.

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

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-17 Thread Oswald Buddenhagen 
On Mon, Jan 16, 2017 at 09:59:42PM +, J-P Nurmi wrote:
> > On 16 Jan 2017, at 16:24, Oswald Buddenhagen  
> > wrote:
> > 
> > On Sat, Jan 14, 2017 at 12:37:06PM +, J-P Nurmi wrote:
> >> Early feedback from the CI system would be invaluable.
> >> 
> > note that nowadays you can explicitly schedule CI runs on arbitrary
> > pending changes.
> > of course, that's not the only _possible_ reason for wanting a branch,
> > but if it's the only _actual_ reason, then it may make sense to change
> > the plan.
> 
> 
> I’m expecting the refactoring work to generate quite a large amount of 
> commits. I’d prefer to do it in small steps to reduce the risk of breaking 
> things. This would be a throw-away branch. No merging to the mainline, but 
> ready features would be picked by hand and submitted for review.
> 
fair enough. note that you're adding to the CI load, so try to batch
your integrations in as far as reasonable. as always, actually.
you didn't specify the source, so i assumed dev.

speaking of how hard is to get branches: the policy is quite clear that
done (and abandoned) branches should be deleted (or moved to a hidden
namespace, if you insist on archiving your throw-away branch). they
aren't, they are piling up. what exactly do you expect in return?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Calendar Systems proposal

2017-01-17 Thread Edward Welbourne 
Allan Sandfeld Jensen asked:
> Are you aware of KCalenderSystem?

Yes - Sergio Martins helpfully brought it up a couple of weeks ago:
http://lists.qt-project.org/pipermail/development/2017-January/028241.html

Current plan is roughly to upstream it.  Debate remains as to whether it
should sit outside QDate (Lars) or be taken by overloads of QDate
methods to tweak their action (Soroush and I).

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

Re: [Development] Calendar Systems proposal

2017-01-17 Thread Edward Welbourne 
Jake Petroules
> Eddy, "draft" does not do what you think it does. This is why no one can see 
> the change.

I think you are addressing the wrong person.
Soroush created the review (as a draft) and added me as a reviewer.
That enabled me to add Frederic.

> Please remove "draft" status and add "WIP: " at the front of the commit 
> message instead so we can all take a look.

It already has WIP: on its commit message.

Soroush: please push your next patch set to refs/for/dev, to make the review 
public.
Subsequent pushes can be to refs/drafts/dev if you like, to make clear it's all 
still a draft.

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

Re: [Development] invokeMethod() with function pointers

2017-01-17 Thread Grégoire Barbier 

Le 16/01/2017 à 10:34, Olivier Goffart a écrit :

What's the use case for this function? For direct call you better of calling
the function directly,  and the equivalent of QueuedConnection can be achieved
with QTimer::singleShot.


Hi.

AFAIK there is no other way to call a method across threads *and wait 
for it result* than QMetaObject::invokeMethod() with 
Qt::BlockingQueuedConnection and Q_RETURN_ARG (apart, of course, making 
the called method thread-safe).


I would personally be happy if (like Benjamin proposes) there were some 
compile time check, IDE symbols following/renaming and no longer need to 
declare such methods as Q_INVOKABLE (or slot).
Therefore IMO methods pointers would be great in 
QMetaObject::invokeMethod() as they are in QObject::connect(). :-)


And maybe lambdas too, if there was a way to choose the thread/eventloop 
in which we want the lambda to be executed (but christmas was a few 
weeks ago, I should not dream ;-)).


Also (I still dream), if there was a way to make invokeMethod() 
automagically choose between a direct call and 
Qt::BlockingQueuedConnection, it would be possible to get rid of this idiom:

if (QThread::currentThread() == this->thread())
   foo = func();
else
   QMetaObject::invokeMethod(this, "func",
 Qt::BlockingQueuedConnection,
 Q_RETURN_ARG(foo));

Kind of Qt::DirectOrBlockingQueuedConnection.



--
Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development