Re: [Development] A simple analysis of apps using qtbase's private headers

[Sune Vuorela]

On 2016-02-02, Liang Qi  wrote:
> Above three are not applications, they must be input context plugin of Qt,
> just like ibus in
> https://github.com/qtproject/qtbase/tree/5.5/src/plugins/platforminputconte=
> xts/ibus
> . Normally every input method software could/should have one of this kind
> of plugin for Qt 5, so there is no question when they use private headers.

There is two ways to fix the usage of private headers in external
things.

1) is to stop using them
2) is to promote more private api to public api.

I do think that one should consider it for the bits needed to make input
methods.

Really. Public private api is bad. It should really not exist. It harms
our "We promise source and binary compatibility" promises, because it is
full of 'except ...' .

We should head towards not have any public private api.

/Sune

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

Re: [Development] RFC: lambda or lambda return from lambda?

[Jędrzej Nowacki]

On Monday 01 of February 2016 15:16:33 you wrote:
> I am a great fanboy of algorithms and the STL, as should be clear by now
You are excused ;-) But seriously I do not think there is anything wrong about 
it, STL is a bit obscure, but fast and sometimes a code needs to be fast. 

> But I find the inlined lambda worse than an explicit loop. This is
> write-only  code, imo. Esp. since we can't (yet) use auto in the parameter
> list, but even then, I'd always give a lambda a name (cf. my mail in
> response to Christian).
Hmmm, In my opinion you do not like the most cool feature of lambdas :-) Each 
time I was forced to define a functor somewhere, in a completely different 
place then my code lived, I was sad and jealous of python lambda syntax. I 
value a code that can be read from top to down without major jumps. Naming 
lambdas causes my eyes to jump ("so for each element it calls a function 
FooBar... Ah which does that") and it also suggests that the lambda will be 
re-used ("ok, so now remember FooBar, as it will be used again..."). I would 
much prefer a simple inline comment before sequence of std::remove_if 
std::erase and others then named lambda.

Anyway I guess we are again hitting a "C++11 syntax that we were not used to" 
issue. So please do not create any policy about that, at least not for now. 

Btw. when you are taking an address of a function you force a compiler to de-
inline the function, I hope such de-optimization doesn't happen while naming 
lambdas.

> > For a bigger code we would actually require named functions. What do you 
> > think?
> 
> Named functions have two problems: a) that many compilers don't inline the 
> code. So at a minimum, you'd write a forwarding lambda, or the function
> would  be an auto variable holding a stateless lambda (the difference
> between the two is almost non-existent, anyway). And b) that they cannot
> carry state. Lambdas can.
Sorry I used wrong wording, by named function I meant, assigned lambda, a 
functor or a declared function.  In general a callable with a name, defined in 
a different place then used.

A propos inline'ing of functions, have you tried anonymous namespaces? That 
should help.  At least once I forced gcc to inline the code...

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A simple analysis of apps using qtbase's private headers

[Liang Qi]

On 22 January 2016 at 04:15, Lisandro Damián Nicanor Pérez <
perezme...@gmail.com> wrote:

> The following three have something in common: they are all apps coded for
> Chinese people. I've been told that they need QPA's private stuff in order
> to
> have proper input systems, but I haven't checked.
>
> * fcitx-qt5 1.0.5
> * gcin 2.8.4
> * hime 0.9.10
>

Above three are not applications, they must be input context plugin of Qt,
just like ibus in
https://github.com/qtproject/qtbase/tree/5.5/src/plugins/platforminputcontexts/ibus
. Normally every input method software could/should have one of this kind
of plugin for Qt 5, so there is no question when they use private headers.

Regards,
Liang

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

Re: [Development] HEADS UP: Qt 5.6.0 branching ongoing

[mark diener]

Jani:

I submitted a message a week ago about the blocker list criterion and
could not find a QT FAQ on what are the critierion.

For example: https://bugreports.qt.io/browse/QTBUG-50374 is NOT a
blocker for 5.6.0 RC.

It is P2: Important.

Likely I am missing something about how the blocker list is
constructed and interpreted.

But should 5.6.0 release with QTBUG-50374 still present, Qt is
effectively saying, we have cut back support for IOS.

And that would be big news.

Please educate me.

md

On Tue, Feb 2, 2016 at 6:51 AM, Heikkinen Jani
 wrote:
> Hi,
>
> Final downmerge is now done and branching is complete. From now on '5.6' is 
> for Qt 5.6.1 and '5.6.0' for Qt 5.6.0. Staging in '5.6.0' is restricted and 
> we in the release team will stage needed changes in '5.6.0' from now on. We 
> will check approved changes automatically so no need for any special actions 
> from you; just take care that your changes will be approved.
>
> And please remember: We will take in only really important changes so please 
> don't add any nice-to-haves in '5.6.0' anymore! If we can live with issue in 
> Qt 5.6.0 then please use '5.6' instead.
>
> And as usual please send re-targeting request to Ossi if there is some change 
> open in '5.6' and which must be in Qt 5.6.0
>
> br,
> Jani
>
> 
> Lähettäjä: Heikkinen Jani
> Lähetetty: 25. tammikuuta 2016 13:39
> Vastaanottaja: development@qt-project.org
> Kopio: releas...@qt-project.org
> Aihe: HEADS UP: Qt 5.6.0 branching ongoing
>
> ‘5.6.0’ branch is now available, please start using it for the changes 
> targeted to Qt5.6.0 release.
>
> We will merge ‘5.6’ branch to ‘5.6.0’ Monday 1st February so there should be 
> enough time to finalize ongoing changes in ‘5.6’ and start using '5.6.0'. All 
> new changes for Qt5.6.0 should be done in ‘5.6.0’ branch from now on.
>
> Target is to release Qt5.6.0 RC quite soon so please make sure all blockers 
> will be fixed as soon as possible. Blocker list here: 
> https://bugreports.qt.io/issues/?filter=17225
> Please make sure all Qt 5.6.0 blockers are found from blocker list (== set 
> 5.6.0 RC as fix version(s)): We should fix all blockers before RC & minimize 
> changes between RC and final.
>
> And please remember: Do not add any 'nice to have' -changes in anymore (P0 & 
> P1 bug fixes mostly, in some special cases p2 fixes might be ok as well).
>
> Best regards,
> Jani Heikkinen
> Release Manager | The Qt Company
>
> The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland
> Email: jani.heikki...@theqtcompany.com | Mobile: + 358 50 48 73 735
> www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
> @Qtproject Facebook: www.facebook.com/qt
>
> ___
> 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] QCameraViewfinderSettingsControl2 for Android

[Ruslan Baratov via Development]

Hi,

I'm planning to try to implement QCameraViewfinderSettingsControl2 for 
Android and want to check that nobody has some related work-in-progress 
patches already.


So from my understanding most of the work already done in 
qtmultimedia/src/plugins/android/src/wrapper/jni/androidcamera.cpp, like 
getSupportedPreviewSizes or setPreviewSize and only wrapper with 
QCameraViewfinderSettingsControl2 API need to be introduced, right?


Any hints/implementation directions welcome.

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

Re: [Development] HEADS UP: Qt 5.6.0 branching ongoing

[Heikkinen Jani]

Hi,

Final downmerge is now done and branching is complete. From now on '5.6' is for 
Qt 5.6.1 and '5.6.0' for Qt 5.6.0. Staging in '5.6.0' is restricted and we in 
the release team will stage needed changes in '5.6.0' from now on. We will 
check approved changes automatically so no need for any special actions from 
you; just take care that your changes will be approved.

And please remember: We will take in only really important changes so please 
don't add any nice-to-haves in '5.6.0' anymore! If we can live with issue in Qt 
5.6.0 then please use '5.6' instead.

And as usual please send re-targeting request to Ossi if there is some change 
open in '5.6' and which must be in Qt 5.6.0

br,
Jani


Lähettäjä: Heikkinen Jani
Lähetetty: 25. tammikuuta 2016 13:39
Vastaanottaja: development@qt-project.org
Kopio: releas...@qt-project.org
Aihe: HEADS UP: Qt 5.6.0 branching ongoing

‘5.6.0’ branch is now available, please start using it for the changes targeted 
to Qt5.6.0 release.

We will merge ‘5.6’ branch to ‘5.6.0’ Monday 1st February so there should be 
enough time to finalize ongoing changes in ‘5.6’ and start using '5.6.0'. All 
new changes for Qt5.6.0 should be done in ‘5.6.0’ branch from now on.

Target is to release Qt5.6.0 RC quite soon so please make sure all blockers 
will be fixed as soon as possible. Blocker list here: 
https://bugreports.qt.io/issues/?filter=17225
Please make sure all Qt 5.6.0 blockers are found from blocker list (== set 
5.6.0 RC as fix version(s)): We should fix all blockers before RC & minimize 
changes between RC and final.

And please remember: Do not add any 'nice to have' -changes in anymore (P0 & P1 
bug fixes mostly, in some special cases p2 fixes might be ok as well).

Best regards,
Jani Heikkinen
Release Manager | The Qt Company

The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland
Email: jani.heikki...@theqtcompany.com | Mobile: + 358 50 48 73 735
www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject 
Facebook: www.facebook.com/qt

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