Re: [Development] MSVC2012 in CI

[Blasche Alexander]

Nevermind. It is MSVC2015 where it fails. 

--
Alex


From: Development 
 on 
behalf of Blasche Alexander 
Sent: Wednesday, April 6, 2016 09:34
To: Gladhorn Frederik; development@qt-project.org
Subject: Re: [Development] MSVC2012 in CI

> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=theqtcompany@qt-project.org] On Behalf Of


> On Sunday, March 20, 2016 12:07:01 PM Sean Harmer wrote:
> > Hi,
> >
> > Can MSVC 2012 configurations be removed from the CI please? My
> understanding
> > is that this compiler was only kept around to support Windows EC but that
> > this is now removed from 5.7.
>
> I'd love to remove it, but it's blocked by https://bugreports.qt.io/browse/
> QTBUG-51934
> We cannot just remove test coverage without testing some of the features on
> more modern platforms.
> In this case msvc 2012 is the platform where we test "DeveloperBuild, Release,
> QtNamespace, QtLibInfix" and I'd like to keep a windows build with these
> features. It seems to consistently fail on windows 10 though.

The removal should not reduce test coverage under any case. Why don't we simply 
setup a new system that is MSVC2015 with the above features? You have to 
replace the MSVC 2012 test platform with a new compiler but the same config 
features anyway, no?

Or are you saying that the failure is MSVC 2012 specific...

--
Alex
___
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] MSVC2012 in CI

[Blasche Alexander]

> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=theqtcompany@qt-project.org] On Behalf Of


> On Sunday, March 20, 2016 12:07:01 PM Sean Harmer wrote:
> > Hi,
> >
> > Can MSVC 2012 configurations be removed from the CI please? My
> understanding
> > is that this compiler was only kept around to support Windows EC but that
> > this is now removed from 5.7.
> 
> I'd love to remove it, but it's blocked by https://bugreports.qt.io/browse/
> QTBUG-51934
> We cannot just remove test coverage without testing some of the features on
> more modern platforms.
> In this case msvc 2012 is the platform where we test "DeveloperBuild, Release,
> QtNamespace, QtLibInfix" and I'd like to keep a windows build with these
> features. It seems to consistently fail on windows 10 though.

The removal should not reduce test coverage under any case. Why don't we simply 
setup a new system that is MSVC2015 with the above features? You have to 
replace the MSVC 2012 test platform with a new compiler but the same config 
features anyway, no?

Or are you saying that the failure is MSVC 2012 specific...

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

Re: [Development] qtfeedback and qtdocgallery: status?

[Blasche Alexander]

The problem seem purely license related (other failures currently not visible). 
I would argue that we should fix integrations errors due to such issues.

I would favor another option though. We should disable the license check for 
modules which are ignored by .gitmodules.


--
Alex


From: Development 
 on 
behalf of Robin Burchell 
Sent: Tuesday, March 22, 2016 10:50
To: development@qt-project.org
Subject: Re: [Development] qtfeedback and qtdocgallery: status?

On Tue, Mar 22, 2016, at 10:37 AM, Hausmann Simon wrote:
> I'm not sure what you'd like me to answer at this point. I think that it
> is possible to fix the
> build of these modules, the CI system is in place for that. However it
> requires a fair bit of
> work (ask Robin about qtmessagingframework ;-).

Assuming that the problems are *just* limited to license tests, and the
tests in the package itself are in good shape, then it's probably not
*too* hard. It'll still require playing a few rounds of CI ping-pong,
and mass-staging changes (and headdesking when it fails again).

I'll readily admit that it's an annoying process, but it was a
manageable one. I'm not sure it's a productive use of time in the case
of these "smaller"/pseudo-abandonware codebases, but it's certainly
possible.

For the practicalities of how to do it (Simon or someone, please correct
me if I'm wrong here):

* You'll want to edit sync.profile in the module and make sure they
don't have "stale" dependencies (I see for instance that qtfeedback is
pointing to refs/heads/stable, which is probably not a good idea at this
point). I forget what the default is (no specific version listed) -- I
believe it points to the origin branch (e.g. 5.6 branch of module -> 5.6
of dependency), or dev if there's not a direct match.
* You can run the license test locally (from qtqa, see
./tests/prebuild/license/tst_licenses.pl) to check that it will be
satisfied with a given module

Robin
___
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] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98

[Blasche Alexander]

>Because you also need to reject some older Clang versions. Did you add the
>check for them too?

clang 3.4 is rejected by requires(c++11) already.

>Please think of Clang on Linux and FreeBSD, plus the older XCode that we still
>support on OS X. This is LTS and the last version before we require C++11, so
>expect people will try to build it with older versions.

>Why do we insist on testing for something that proxies the real need? We need
>X and we know that Y provides X, so we test for Y. Why can't we just test for
>X?

Effort and speed. The compile test should not delay the 5.6.0 release and such 
a test would take much more time. After all we would have to go through the 
entire code base and identify all C++11 features we are using. That's bound to 
have the same gaps too. 

I want to emphasize qtserialbus is not the first module to do such a compiler 
based rejection pattern. For 5.6.0 this is good enough.

Nevertheless I filed https://bugreports.qt.io/browse/QTBUG-51655 and we might 
have a better solution for 5.6.1.

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

Re: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98

[Blasche Alexander]

--
Alex


> On quinta-feira, 3 de março de 2016 08:12:25 PST Thiago Macieira wrote:
> > Please add a test for each of the specific C++11 features, not for the
> > compiler  version. My email with the build errors lists them all, in
> > addition to NSDMI.
> 
> To be clear: one config.test that happens to test each of the specific C++11
> features used.

Anything below gcc 4.7 is excluded now. I see little point in making such 
fine-grained test. IMO the result is not worth the effort. The module declares 
it requires C++11 and new modules do not necessarily have to comply with Qt 
base line requirements. That's why I see little point in making it anything 
worse than C++11 compliant. This is a conscious decision that accepts the 
exclusion of certain targets for the module. qtwebengine does the same thing 
already. 

> Note that this may still disable the module in even in Qt 5.7, since things
> like delegating constructors are not yet permitted. I'd like the module to
> remove the tests and comply with Qt coding requirements before it leaves "tech
> preview" state.

It is going to be TP in 5.6 and 5.7. There is simply not enough time between 
the two releases to evaluate the TP proposal.
5.8 will easily full the requirements.

--
Alex

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

Re: [Development] INTEGRITY changes for 5.7

[Blasche Alexander]

It never worked in the Qt5.x releases so far. For what it's worth I'd argue 
this is bugfixing for a non-working platform. 

Your gerrit reviews would have to be retargeted to 5.7 (A Gerrit admin can do 
that if that's the conclusion we come to in this thread). 

--
Alex


> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=theqtcompany@qt-project.org] On Behalf Of
> Rolland Dudemaine
> Sent: Wednesday, 2 March 2016 9:07
> To: Liang Qi 
> Cc: development@qt-project.org
> Subject: Re: [Development] INTEGRITY changes for 5.7
> 
> Ideally i'd like to get those also in 5.7 indeed.
> 
> For 5.8/dev, there is no need for asking for an exception i guess, just 
> following
> the regular merge procedure would do just fine.
> 
> --Rolland
> 
> From: Liang Qi 
> Sent: Mar 2, 2016 08:28
> To: Rolland Dudemaine
> Cc: development@qt-project.org
> Subject: Re: [Development] INTEGRITY changes for 5.7
> 
> 
> 
>   Do you plan to have them in 5.7 release? Current dev branch means 5.8...
> 
>   On 2 March 2016 at 08:24, Rolland Dudemaine   > wrote:
> 
> 
>   Hi,
> 
>   I understand that 5.7 has now reached feature freeze, but I
> would like
>   to ask for an exception for patches that have been pushed a few
> months
>   ago already but never got merged (partially because of the CI
> woes).
> 
>   This would cover all the patches with a positive code review
> status at
>   https://codereview.qt-
> project.org/#/q/owner:rolland%2540ghs.com+status:open,n,z
> 
>   Thanks,
>   Best regards,
> 
>   --
>   --
>   Rolland Dudemaine   tel direct:+33 143 143 702
> 
>   Green Hills Software   tel:+33 143 143 700
> 
>   4 rue de la Pierre Leveemailto:roll...@ghs.com
> 
>   75011 Paris   fax: +33 143 143 707
> 
>   France web: http://www.ghs.com
> 
>   --
> 
>   ___
>   Development mailing list
>   Development@qt-project.org  project.org>
>   http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> 
> 
> 
>   --
> 
>   http://www.qiliang.net

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

Re: [Development] Approver status for Michal Klocek

[Blasche Alexander]

Approver rights have been granted. Congratulations to Michal.

--

Alex


From: Blasche Alexander
Sent: Monday, February 8, 2016 15:18
To: development@qt-project.org
Subject: Approver status for Michal Klocek

Hello,

I would like to nominate Michal Klocek for Approver status in the Qt Project. 
Throughout the last year he has been working on QtLocation and QtWebEngine:

https://codereview.qt-project.org/#/q/owner:michal.klocek,n,z

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

Re: [Development] Supported platforms for Qt 5.8

[Blasche Alexander]

> -Original Message-
> From Marc Mutz
> On Friday 19 February 2016 22:01:02 Knoll Lars wrote:
> > * We continue to support QNX 6.6
> 
> Does someone here know (Rafael) when we can expect a QNX that supports
> C++11
> at the library level?

During Embedded World, a person at the QNX booth told me that QNX 7.0 is what 
will fix this gap. Please don't nail me down on the timeline but I believe it 
was 2H 2017 (2017 for sure).

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

Re: [Development] Supported platforms for Qt 5.8

[Blasche Alexander]

> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=theqtcompany@qt-project.org] On Behalf Of
> Andreas Holzammer
...
> Am 22.02.2016 um 23:52 schrieb Thiago Macieira:
> > On segunda-feira, 22 de fevereiro de 2016 21:08:12 PST Knoll Lars wrote:
> >> I can see the reasoning here, just as well as I see the reasoning of the
> >> people that would like to get rid of VS2012 as quickly as possible.
> >
> > Why do we need to get rid of it? What are the problems with it, aside from
> > lack of certain C++11 support?
> >
> 
> Mostly yes we see a demand in getting new c++ features into Qt. As far
> as my knowlege goes is that WEC2013 bundles they compiler with the SDK
> which is produced by the Platform Builder. As of now I did not see any
> indication that this bundled compiler will be updated(right now they
> bundle the VS2012 compiler). All websites which I did read say if you
> read closely that they are supporting the new Visual Studio IDE, but
> will take the toolchain of the SDK which is provided.
> 
> Basically it means we are stuck with Visual Studio 2012 c++ featureset
> for Windows Embedded Compact 2013.

I spoke to the Microsoft guys on Embedded World today. They confirmed that it 
is 2012 and there are no plans to update this. In fact that went as far as 
saying that the relevant development team behind WEC2013 has been abandoned to 
the point that the essential support is barely possible. 

> If we want to support newer C++ with Qt 5.8 we would need to drop the
> complete platform.

And this is the main reason behind this push.

> On terça-feira, 23 de fevereiro de 2016 19:16:48 PST Andreas Holzammer wrote:
> > As of problems to support it in newer Qt Versions, I can say the market
> > share right now is not very big, as also already indicated by someone
> > else. Hardware vendors do release right now more experimental support
> > for WEC2013, which means there might be years until they reach a decent
> > market share.
> 
> To be clear: are you expecting WEC2013 market share to increase?

Those projects which would grow this market would have to have acquired their 
license already as I have heard that new WEC2013 licenses are not handed out 
anymore. At the very least you have to "twist" Microsoft's arms to get hold of 
one. That's not a good starting point for a growing market. This is a firm 
Micosoft management decision despite the mentioned offering gaps.

>On Tuesday, 23 February 2016 13:09:10 WET Thiago Macieira wrote:
> > But you cannot commit major refactorings to improve stability in an patch
> > release, especially not the LTS release. Remember that 5.6 is also the last
> > release to support WEC7, so you cannot risk its stability for a platform
> > that's only experimental.

> But are we going to need major refactorings ? We need to know the state of
> wec2013 before discussing further, no point in speculating on what was meant
> by "experimental".

The answer is no. The principle feature set is working. There are some gaps 
related to device debugging but those gaps are due to non-open protocols. The 
term "Experimental" is a rather bad choice of word.

The commitment towards WEC2013 in Qt 5.6 is what really matters due to its LTS 
character. By the time 5.6 support runs out Qt 5.8 support has been ancient 
history.

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.

There simply is no justification for such a move on the business and technical 
side.

--
Alex

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

Re: [Development] How to find the most appropriate "Fix Version" tag in Jira

[Blasche Alexander]

> -Original Message-
> From: Giuseppe D'Angelo [mailto:dange...@gmail.com]

> On Wed, Feb 17, 2016 at 8:29 AM, Blasche Alexander
>  wrote:
> >
> > The verion tag 5.5 is not a proper version tag. A bug consumer would not 
> > know
> where to find the fix. Issues should always be set to the most appropriate fix
> version tag. If you know that git's 5.x branch will later be branched off 
> into 5.x.y
> then you should set it Jira to 5.x.y. The only case where the 5.x tag makes 
> sense is
> in a scenario were you don't know whether the 5.x branch will still generate
> another patch level release. Once it is certain where the a 5.x branch ends 
> up I go
> through the 5.x release tags and they become the next 5.(x+1).0
> (RC|Beta|Alpha)  or 5.x.y release.
> 
> I'm sorry, but this reasoning makes very little sense to me.
> 
> The decision whether a given version will or will not be released from
> a branch belongs to the release team, and it's (99% of the time) just
> a bandwidth and packaging problem, i.e. "do we have enough resources
> to put 5.x.y out". A developer fixing a bug has no influence nor
> knowledge over that process; it's already enough of a burden to make
> patches target the right branch (*), as versioned branches come and
> go, overloading Oswald with "please move this patch" requests.

I disagree. Sure you may not know whether there will be a 5.6.3 but you do know 
today that the following will happen:

- git5.6.0 will be 5.6.0
- git5.6 will be 5.6.1 (sure 5.6.2 will be harder to guess and by all means use 
5.6 for it)
so far we always had a .1 patch release and I cannot see this changing. On top 
of that you know it is an LTS.

- git5.7 will be 5.7.0 Alpha (unless we will never have 5.7 as a release 
version)
- dev will be 5.8 Alpha

Where is the open question in your mind about the above 4 cases?

 
> Think of a bugfix landing in 5.6 right now. What's the tag I'm
> supposed to use? 5.6.1? What if there won't be one, and how am I
> supposed to know that (which by the way was exactly the case with
> bugfixes landed in 5.5 after 5.5.1)? Should I be conservative and use
> 5.7.0 then? So what happens if there is indeed a 5.6.1, people will
> think that it won't contain the bug fix?

Use 5.6.1, there is no harm. We are 99% sure it will exist and even if it never 
comes about I will rewrite it to 5.7.0 when it is certain and I see the merge. 
After all the 5.5.3 release tag did exist as well till yesterday and they all 
got rewritten to 5.6.0RC because we had the last 5.5->5.6 merge. In fact Jira 
enforces this as we have to shift Jira release version tags into the "released" 
state.

> On the other hand, marking it as "5.6" is meaningful – whoever uses
> 5.6 from git knows they'll have the bug fixed. There are many
> downstreams which use specific branches from git (as for various
> reasons they can't "just upgrade"). If you think that "5.6" is
> confusing or not accurate, we could rename them, perhaps to "5.6
> branch" or "5.6 git" or something like that (or use a different field
> on the report for this purpose).

5.6 is a temporary release tag. During the entire history of Qt in Jira it has 
been this way.
Sure, if you aren't sure then by all means use it but be prepared that we might 
end up with a situation where it ends up with the wrong tag. An excellent 
example for this is https://bugreports.qt.io/browse/QTBUG-40060 . And yes, I 
could have tracked this case down but doing so for hundreds of Jira items is 
unreasonable. 

What matters when a Qt user looks at a bug is the ultimate release version for 
the Qt at hand. Do I need to upgrade from 5.6.2 to 5.6.3 or not? Just stating 
5.6 is meaningless once the bug is in a released Qt version as the meaning of 
5.6 shifts over time. 5.6.0 does not change its meaning ever. Also it is 
unreasonable to expect that customers have to dive through gerrit and git to 
figure out which release got the patch eventually. I certainly don't want to do 
that for gcc versions or the linux kernel releases.

> Next to that branch tag, you could add a specific version tag of the
> first released version of Qt that contains that bugfix. For the
> reasons above, it should be the job of the release team to do this,
> and luckily should be easily scriptable – for instance, by taking the
> SHA1 in the bug report and checking if the new release contains that
> SHA1, then tagging the report accordingly.

We all agree that a lot of things can be automated. Right now they are not and 
unless you volunteer to do this it won't get done. We all have priorities 
(including the release team which currently tries to manage 2 concurrent 
releases). Similar cases ar

Re: [Development] New Qt 5.6.0 RC snapshot available, please test

[Blasche Alexander]

Fix: https://codereview.qt-project.org/#/c/149611/

--
Alex


From: Development 
 on 
behalf of Tim Blechmann 
Sent: Wednesday, February 17, 2016 08:38
To: development@qt-project.org
Subject: Re: [Development] New Qt 5.6.0 RC snapshot available, please test

> We have finally packages for testing,
>
>
> Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/335/
>
> Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/331/
>
> Mac:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/271/
>
> src:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/latest_src
>
>
> Unfortunately these packages are from a bit old qt5.git integration
> (https://codereview.qt-project.org/#/c/147715/) so latest changes from
> '5.6.0' (https://codereview.qt-project.org/#/c/148570/) are missing from
> the packages, sorry about that!
>
>
> We are trying to release RC as soon as possible so it is really
> important to test these packages now to see if there is still something
> to be fixed before we can release the RC. Current RC blockers are here:
> https://bugreports.qt.io/issues/?filter=17225 .Please make sure all
> blocker are visible here (but remember, just a real blockers anymore!).
>
>
> And please start creating changelogs for final release now if not
> already started.

>seems that building statically linked qt is broken:

windows:

>   link /NOLOGO /DYNAMICBASE /NXCOMPAT /DEBUG /OPT:REF 
> /INCREMENTAL:NO /SUBSYSTEM:CONSOLE "/MANIFESTDEPENDENCY:type='win32' 
> name='Microsoft.Windows.Common-Controls' version='6.0.0.0' 
> publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*'" 
> /MANIFEST:embed /OUT:..\..\..\bin\canbusutil.exe 
> @C:\Users\developer\AppData\Local\Temp\canbusutil.exe.3388.3853.jom
> 16-Feb-2016 14:24:02  canbusutil_plugin_import.obj : error LNK2019: 
> unresolved external symbol "struct QStaticPlugin const __cdecl 
> qt_static_plugin_PeakCanBusPlugin(void)" 
> (?qt_static_plugin_PeakCanBusPlugin@@YA?BUQStaticPlugin@@XZ) referenced in 
> function "public: __cdecl 
> StaticPeakCanBusPluginPluginInstance::StaticPeakCanBusPluginPluginInstance(void)"
>  (??0StaticPeakCanBusPluginPluginInstance@@QEAA@XZ)
> 16-Feb-2016 14:24:02  canbusutil_plugin_import.obj : error LNK2019: 
> unresolved external symbol "struct QStaticPlugin const __cdecl 
> qt_static_plugin_TinyCanBusPlugin(void)" 
> (?qt_static_plugin_TinyCanBusPlugin@@YA?BUQStaticPlugin@@XZ) referenced in 
> function "public: __cdecl 
> StaticTinyCanBusPluginPluginInstance::StaticTinyCanBusPluginPluginInstance(void)"
>  (??0StaticTinyCanBusPluginPluginInstance@@QEAA@XZ)

osx:
>   Undefined symbols for architecture x86_64:
> 16-Feb-2016 13:38:21"qt_static_plugin_PeakCanBusPlugin()", referenced 
> from:
> 16-Feb-2016 13:38:21__GLOBAL__sub_I_canbusutil_plugin_import.cpp in 
> canbusutil_plugin_import.o
> 16-Feb-2016 13:38:21  ld: symbol(s) not found for architecture x86_64
> 16-Feb-2016 13:38:21  clang: error: linker command failed with exit code 1 
> (use -v to see invocation)
> 16-Feb-2016 13:38:21  make[4]: *** [../../../bin/canbusutil] Error 1
> 16-Feb-2016 13:38:21  make[3]: *** [sub-canbusutil-make_first] Error 2
> 16-Feb-2016 13:38:21  make[2]: *** [sub-tools-make_first] Error 2

would be great if statically linked qt could somehow be compiled
regularly ... it breaks way too often :(

cheers,
tim


___
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] New Qt 5.6.0 RC snapshot available, please test

[Blasche Alexander]

Thank you for pointing this out. I am working on it.

--
Alex


From: Development 
 on 
behalf of Tim Blechmann 
Sent: Wednesday, February 17, 2016 08:38
To: development@qt-project.org
Subject: Re: [Development] New Qt 5.6.0 RC snapshot available, please test

> We have finally packages for testing,
>
>
> Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/335/
>
> Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/331/
>
> Mac:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/271/
>
> src:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/latest_src
>
>
> Unfortunately these packages are from a bit old qt5.git integration
> (https://codereview.qt-project.org/#/c/147715/) so latest changes from
> '5.6.0' (https://codereview.qt-project.org/#/c/148570/) are missing from
> the packages, sorry about that!
>
>
> We are trying to release RC as soon as possible so it is really
> important to test these packages now to see if there is still something
> to be fixed before we can release the RC. Current RC blockers are here:
> https://bugreports.qt.io/issues/?filter=17225 .Please make sure all
> blocker are visible here (but remember, just a real blockers anymore!).
>
>
> And please start creating changelogs for final release now if not
> already started.

seems that building statically linked qt is broken:

windows:

>   link /NOLOGO /DYNAMICBASE /NXCOMPAT /DEBUG /OPT:REF 
> /INCREMENTAL:NO /SUBSYSTEM:CONSOLE "/MANIFESTDEPENDENCY:type='win32' 
> name='Microsoft.Windows.Common-Controls' version='6.0.0.0' 
> publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*'" 
> /MANIFEST:embed /OUT:..\..\..\bin\canbusutil.exe 
> @C:\Users\developer\AppData\Local\Temp\canbusutil.exe.3388.3853.jom
> 16-Feb-2016 14:24:02  canbusutil_plugin_import.obj : error LNK2019: 
> unresolved external symbol "struct QStaticPlugin const __cdecl 
> qt_static_plugin_PeakCanBusPlugin(void)" 
> (?qt_static_plugin_PeakCanBusPlugin@@YA?BUQStaticPlugin@@XZ) referenced in 
> function "public: __cdecl 
> StaticPeakCanBusPluginPluginInstance::StaticPeakCanBusPluginPluginInstance(void)"
>  (??0StaticPeakCanBusPluginPluginInstance@@QEAA@XZ)
> 16-Feb-2016 14:24:02  canbusutil_plugin_import.obj : error LNK2019: 
> unresolved external symbol "struct QStaticPlugin const __cdecl 
> qt_static_plugin_TinyCanBusPlugin(void)" 
> (?qt_static_plugin_TinyCanBusPlugin@@YA?BUQStaticPlugin@@XZ) referenced in 
> function "public: __cdecl 
> StaticTinyCanBusPluginPluginInstance::StaticTinyCanBusPluginPluginInstance(void)"
>  (??0StaticTinyCanBusPluginPluginInstance@@QEAA@XZ)

osx:
>   Undefined symbols for architecture x86_64:
> 16-Feb-2016 13:38:21"qt_static_plugin_PeakCanBusPlugin()", referenced 
> from:
> 16-Feb-2016 13:38:21__GLOBAL__sub_I_canbusutil_plugin_import.cpp in 
> canbusutil_plugin_import.o
> 16-Feb-2016 13:38:21  ld: symbol(s) not found for architecture x86_64
> 16-Feb-2016 13:38:21  clang: error: linker command failed with exit code 1 
> (use -v to see invocation)
> 16-Feb-2016 13:38:21  make[4]: *** [../../../bin/canbusutil] Error 1
> 16-Feb-2016 13:38:21  make[3]: *** [sub-canbusutil-make_first] Error 2
> 16-Feb-2016 13:38:21  make[2]: *** [sub-tools-make_first] Error 2

would be great if statically linked qt could somehow be compiled
regularly ... it breaks way too often :(

cheers,
tim


___
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] How to find the most appropriate "Fix Version" tag in Jira

[Blasche Alexander]

Hi,

Some of you might have noticed that I did some global release version clean-ups 
in Jira. Several people asked me about the rationale behind the changes I did. 
There is a long explanation below and there is a short recommendation I'd like 
to give (in case you don't read the entire mail):

Please always use the most appropriate/precise version tag you can find. This 
means it should be a 5.x.y tag. Only use the 5.x tags when you are not 100% 
certain. If you miss a 5.x.y Jira tag (where one should exist), please let me 
know and I'll add it.

---

The verion tag 5.5 is not a proper version tag. A bug consumer would not know 
where to find the fix. Issues should always be set to the most appropriate fix 
version tag. If you know that git's 5.x branch will later be branched off into 
5.x.y then you should set it Jira to 5.x.y. The only case where the 5.x tag 
makes sense is in a scenario were you don't know whether the 5.x branch will 
still generate another patch level release. Once it is certain where the a 5.x 
branch ends up I go through the 5.x release tags and they become the next 
5.(x+1).0  (RC|Beta|Alpha)  or 5.x.y release.

This is what happened during the last two day. 5.5 is no more (and meaningless 
as fixForVersion) and the 5.5->5.6 merge took place. Since the 5.6 branch at 
the time of the merge results in the 5.6.0RC that's what I set the FixVersion 
to. There were hundreds of such issues. It is impossible to check and validate 
each individual issue but the cleanup was necessary. Moving the version to 
5.6.0RC may not be the most appropriate release tag but one that is not wrong. 
It was a compromise between accuracy and the sheer volume of tasks witch such 
tags.

To avoid this in the future please set a precise patch level tag (5.x.y) if 
deducible from the current branching situation. For example today's situation 
would be like this:

git branch 5.6.0 -> next 5.6.0RC -> 5.6.0 (after RC is out)
git branch 5.6 -> 5.6.1
git branch 5.7 -> 5.7.0 Alpha
git branch dev -> 5.7.0 Alpha (as long as Ossi still merges backwards) -> 
5.8.0 Alpha (after last backmerge)

Only if it is not possible then you can set 5.x which will be converted by me 
once the situation is more obvious. If my bulk change is incorrect and you have 
better more precise information please feel free to change it.

I hope this helps and thank you for your help.
--
Alex


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

Re: [Development] [Proposal] Future QtSerialPort with plugins architecture

[Blasche Alexander]

> -Original Message-
> From: Denis Shienkov [mailto:denis.shien...@gmail.com]

> I would like to discuss new idea of transition of QtSerialPort to
> an architecture with the plug-ins/backends.
> The user can use/change desired plugin, e.g. via the
> QT_SERIALPORTINFO_PLUGIN environment, or via command line e.g.:
> 
> {code}
> set QT_SERIALPORTINFO_PLUGIN=wmi // on windows
> myapp.exe
> {code}
> 
> {code}
> export QT_SERIALPORTINFO_PLUGIN=sysfs // on linux
> myapp
> {code}
> 
> {code}
> myapp -qspi sysfs // on linux
> {code}

In principle I have no problem. Maybe you forgot to mention it in your mail but 
choosing the plugin via env or app parameter is not sufficient. The system must 
support the concept of a default plugin for the current platform. 

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

Re: [Development] Qt 5.7 new features: MAINTAINERS, your input needed!

[Blasche Alexander]

The full list based on changelog is in the dist/changes-5.x.y

The aforementioned list is a much much higher level overview. We are talking 
major feature points. Because we are talking about such high level points it 
should not be difficult to indentify them when reviewing your personal work 
history.

A change log system would be overkill and is geared towards the above mentioned 
changes files.

--
Alex


From: Development  on behalf of Allan 
Sandfeld Jensen 
Sent: Saturday, February 13, 2016 12:22
To: development@qt-project.org
Cc: releas...@qt-project.org
Subject: Re: [Development] Qt 5.7 new features: MAINTAINERS,your input 
needed!

On Saturday 13 February 2016, Turunen Tuukka wrote:
> Hi,
>
> Idea is the same as with earlier releases, i.e. to mention only the most
> important features from user's viewpoint. Automatically generated list of
> all commits typically does not work even for the full change log, because
> it contains also unnecessary items. For the high level feature list it is
> often a large number of commits that together build a new feature.
>
But maybe we could still have the full automatically generated changelog
posted somewhere. It is better than nothing, and could be used by non-
maintainers to fill out the hand-edited changelog.

Best reagards
`Allan
___
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] Closing the 5.5 branch

[Blasche Alexander]

> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf
> Of Nikita Krupenko
> 2016-02-08 15:03 GMT+02:00 Frederik Gladhorn
> :
> > Hi all,
> >
> > due to the strain that we put on the VMs that are supposed to get the 
> > releases
> > out and do the testing, we decided to "shut down" the CI for Qt 5.5 
> > branches.
> > This means literally that we shut down the VMs but we'll keep them around in
> > case we ever need to make a 5.5 release.
> > The goal is to free capacity to let us finally get 5.6 and just after 5.7 
> > out
> > of the door.
> 
> If I have change on 5.5 branch, that is waiting for review, should I
> ask to retarget it to 5.6?

That's the correct course of action.

> Or there will be one more merge 5.5 -> 5.6?

This question is irrelevant since the branch is closed. Only already committed 
patched would be covered with merges and you cannot commit anything anymore.

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

[Development] Approver status for Michal Klocek

[Blasche Alexander]

Hello,
 
I would like to nominate Michal Klocek for Approver status in the Qt Project. 
Throughout the last year he has been working on QtLocation and QtWebEngine:

https://codereview.qt-project.org/#/q/owner:michal.klocek,n,z

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

Re: [Development] Proposal to include qtscxml as Qt add-on module

[Blasche Alexander]

The module is now available under git clone 
https://codereview.qt-project.org/qt/qtscxml.

There is still some refactoring ongoing as the very recent API review created 
good suggestions and revealed some issues. Therefore stay tuned.

--
Alex


From: Development  on behalf of Blasche 
Alexander 
Sent: Monday, January 25, 2016 15:55
To: development@qt-project.org
Subject: [Development] Proposal to include qtscxml as Qt add-on module

Hi,

As part of the renewed publishing process following the new KDE Free Qt 
foundation agreement,  we'd like to publish the source of the new Qt SCXML 
module.

I'd like to propose the module to be accepted as part of the Qt add-on modules. 
The module itself is brand new as well (target is a 5.7 TP). Initially it would 
have been part of our Qt Automotive effort. It permits the definition of state 
machines using SCXML and generates relevant Qt C++ state machines at compile 
time or runtime.

As maintainer I'd like to propose Erik Verbruggen.

--
Alex
___
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] Proposal to include qtscxml as Qt add-on module

[Blasche Alexander]

Hi,

As part of the renewed publishing process following the new KDE Free Qt 
foundation agreement,  we'd like to publish the source of the new Qt SCXML 
module.

I'd like to propose the module to be accepted as part of the Qt add-on modules. 
The module itself is brand new as well (target is a 5.7 TP). Initially it would 
have been part of our Qt Automotive effort. It permits the definition of state 
machines using SCXML and generates relevant Qt C++ state machines at compile 
time or runtime.

As maintainer I'd like to propose Erik Verbruggen.

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

Re: [Development] Nominating Samuli Pippo for Approver status

[Blasche Alexander]

Congrats to Samuli. The Jira/Gerrit rights have been set.


--

Alex



From: Development  on behalf of Agocs 
Laszlo 
Sent: Wednesday, December 2, 2015 15:13
To: development@qt-project.org
Subject: [Development] Nominating Samuli Pippo for Approver status


Hello,

I would like to nominate Samuli Piippo for Approver status in the Qt Project. 
Samuli has been working on Qt's Embedded Linux support and Qt for Device 
Creation during the past few years. He is our resident Yocto expert and is 
contributing to meta-qt5 as well.

Public Gerrit dashboard: 
https://codereview.qt-project.org/#/q/owner:samuli.piippo,n,z

meta-qt5 contributions: 
https://github.com/meta-qt5/meta-qt5/commits/master?author=sapiippo

Best regards,
Laszlo

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

Re: [Development] Nominating Pasi Petäjäjärvi for Approver status

[Blasche Alexander]

Congratulations to Pasi. Jira and Gerrit rights have been set.


--

Alex



From: Development  on behalf of Agocs 
Laszlo 
Sent: Tuesday, November 24, 2015 10:04
To: development@qt-project.org
Subject: [Development] Nominating Pasi Petäjäjärvi for Approver status


Hello,



I would like to nominate Pasi Petäjäjärvi for Approver status in the Qt Project.



Pasi is the maintainer of the VxWorks port and has also been contributing a lot 
for other embedded platforms over the years.



Public Gerrit dashboard: 
https://codereview.qt-project.org/#/q/owner:pasi.petajajarvi,n,z

[https://codereview.qt-project.org/static/logo_open_gov.png]

Gerrit Code 
Review
codereview.qt-project.org
Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet 
Qt; Qt Repository Browser




Best regards,

Laszlo


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

Re: [Development] Nominating Pasi Keränen for Approver status

[Blasche Alexander]

>I'd like to nominate Pasi Keränen as Approver in the Qt Project. He is

Congratulation. The Gerrit and Jira rights have been updated.

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

Re: [Development] RFC: more liberal 'auto' rules?

[Blasche Alexander]

> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf
> Of Thiago Macieira
> Sent: Friday, 4 December 2015 9:14
> To: development@qt-project.org
> Subject: Re: [Development] RFC: more liberal 'auto' rules?
> 
> On Friday 04 December 2015 08:49:14 Marc Mutz wrote:
> > > Qt has enough market share by itself that we can choose our own direction
> > > and still be relevant. We are allowed to disagree with what others do.
> >
> > Yes, but only if we know *better*.
> >
> > I very much doubt that more than very few people in Qt development have the
> > knowledge to objectively overrule the accepted C++ authorities.
> 
> That's why we use the mailing list and discuss the issue. Our collective minds
> together are quite powerful.

First of all I'd like to point out that I agree with Thiago and Randall. In 
fact, I added the auto policy to the Qt coding conventions.

This policy has been in place for much longer in Qt Creator (and therefore the 
Qt version  just an adoption). I had my fair share of arguing over what is 
better or worse readability wise. At the end of the day it's subjective which 
makes argumentation about right or wrong harder. For me the point is that if I 
have to look up a function signature to figure out what type is behind the 
return values auto type then that's bad. An always auto policy is just asking 
for such situations. 

> You're calling for "opt-in by default" approach, while I am calling for an
> "opt-out by default" approach.

+1
--
Alex


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

Re: [Development] Suggestion for change on how blockers are marked in Jira

[Blasche Alexander]

> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf
> Of Christian Kandeler
...
> Sounds sensible, but what about all the existing bugs that have a "Fix
> version" assigned? Won't they all become blockers now? Or can a script
> wipe this field before the new semantics are announced?

I would suggest that when release management sets Qt 5.x.y to released in Jira, 
every unresolved bug with a fix for tag of 5.x.y is shifted out. After all, 
after a release there should be no further unresolved issues for that 
particular release.

>So we could define it like this: If a bug report is open and has "Fix 
>version: Qt X.Y", then it will be considered a blocker for Qt X.Y.

There is a small point missing here. Priorities still play a role here. P1 is 
blocker, every other priority is not a blocker but still targets 5.x.y. Of 
course depending on how close the release is the P4 fix may ot get accepted 
anymore and its fix for tag may have to be shifted eventually.

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

Re: [Development] QML import versions

[Blasche Alexander]

>Your "solution" to have all the minor version number of all modules the same
>as Qt would not work with third party libraries that have different releasing
>cycle.

In this thread we have almost exclusively talked about QML API's which are not 
released at a different time. Let's not talk about those 3rdparty possibilities 
which (to my knowledge) haven't even happened. Even if it does happen, it still 
doesn't mean that the modules which get released in step with Qt releases 
couldn't follow the same version schema. After all the upside is rather 
significant as we can avoid this version hell we have and intermodule 
dependency issues are easily solved.

>(And remember that the whole reason behind modularisation and the different
>version number comes from the wish to release QtQuick with a different release
>cycle than Qt itself)

Modularization serves a lot of other reasons as well. Please don't use this as 
a reason not to unify the versions.

--
Alex


P.S. For the record I am a fan of QML API's being versioned the same way as the 
related Qt release. Positioning, Location, Sensors, Bluetooth and Nfc have 
managed to do that for years.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.6.0 header diff: QtBluetooth.diff

[Blasche Alexander]

From: Knoll Lars


>void setPreferredSecurityFlags(QBluetooth::SecurityFlags flags);
>QBluetooth::SecurityFlags preferredSecurityFlags() const;

It would be a behavior change. Prior to this API we used one default way to 
connect. On all platforms this happened to be secure but on Bluez it was not. 
Existing apps my get pairing issues if we set it to secure.

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

Re: [Development] Qt 5.6.0 header diff: QtLocation.diff

[Blasche Alexander]

All clean.

The API is in TP at this stage. Hence any change would be permitted anyway.

--

Alex


From: development-bounces+alexander.blasche=theqtcompany@qt-project.org 
 on 
behalf of Frederik Gladhorn 
Sent: Thursday, September 17, 2015 12:54
To: development@qt-project.org
Subject: [Development] Qt 5.6.0 header diff: QtLocation.diff
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Sérgio Martins for Approver status

[Blasche Alexander]

Rights have been set. Congratulations.

--

Alex


From: development-bounces+alexander.blasche=theqtcompany@qt-project.org 
 on 
behalf of Milian Wolff 
Sent: Tuesday, July 21, 2015 16:38
To: development@qt-project.org
Subject: Re: [Development]  Nominating Sérgio Martins for Approver status

On Tuesday 21 July 2015 14:43:49 Marc Mutz wrote:
> On Tuesday 21 July 2015 13:27:51 Giuseppe D'Angelo wrote:
> > Hi,
> >
> > I'd like to nominate Sérgio Martins for the Approver status in the Qt
> > project.
>
> Oh, he's not an approver, yet? And here I was wondering why I only ever got
> +1 from him :)
>
> +1
>
> > (Disclaimer: he's a colleague of mine at KDAB.)
>
> Same disclaimer applies to me.

+1 to both statements above.

--
Milian Wolff | milian.wo...@kdab.com | 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

Re: [Development] Nominating Pier Luigi Fiorini (plfiorini) as an Approver

[Blasche Alexander]

Rights have been set. Congratulations.

--
Alex


From: development-bounces+alexander.blasche=theqtcompany@qt-project.org 
 on 
behalf of Robin Burchell 
Sent: Tuesday, July 14, 2015 16:37
To: development@qt-project.org
Subject: [Development] Nominating Pier Luigi Fiorini (plfiorini) as an  Approver

Hi,

I would like to nominate plfiorini for Approver status.

He's been quite helpful in working on Wayland (client & compositor) side
things in conjunction with the Hawaii desktop (http://hawaiios.org/),
and offering review on related patches. He also has knowledge of QPA
thanks to this work, and best of all, is easy to get in touch with (and
very friendly on) IRC :).

His dashboard:
https://codereview.qt-project.org/#/q/owner:%22Pier+Luigi+Fiorini+%253Cpierluigi.fiorini%2540gmail.com%253E%22,n,z

And his reviews:
https://codereview.qt-project.org/#/q/reviewer:%22Pier+Luigi+Fiorini+%253Cpierluigi.fiorini%2540gmail.com%253E%22,n,z

Would anyone like to second?

Robin
___
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] Found wince info in Gerrit ,which makes me panic

[Blasche Alexander]

>I agree that the commit message looks a bit uninformed, given that Qt
>should still support WEC (if only 2013+) in Qt 5.7 and beyond. The new
>CI has a WEC7 stage, so one would expect that this gets replaced by a
>WEC2013 stage at some point in the future.

This assessment is spot on. It's a change driven by getting the integration for 
the serialbus module into the new CI and the module doesn't care for VS2008 
based wince.

If you want to add wince for VS2008 feel free to fix the problem. There was not 
meant to be a hidden WEC2013 comment in there beyond the fact that the module 
doesn't support this either at this stage.

--
Alex



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

Re: [Development] Relevant industrial buses

[Blasche Alexander]

> -Original Message-
> From: development-bounces+alexander.blasche=theqtcompany.com@qt-
> project.org [mailto:development-
> bounces+alexander.blasche=theqtcompany@qt-project.org] On Behalf Of
> Tom Isaacson
> Sent: Friday, 10 July 2015 11:13
> To: development@qt-project.org
> Subject: Re: [Development] Relevant industrial buses
> 
> Not sure this counts as industrial but NMEA2000 for marine would be good.

http://doc.qt.io/qt-5/qnmeapositioninfosource.html

Even if this is not sufficient, I would not put it into the category of 
industrial buses.

--
Alex

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

[Development] Jira component rename ActiveQt -> update filters

[Blasche Alexander]

It seems the term "ActiveQt" is too generic as a Jira component name. Not 
everybody seems to associate this with Windows and ActiveX. In addition, it is 
the first component in the list and therefore a large number of bugs seem to 
end up in this component bucket (without justification). To alleviate the 
problem somewhat I renamed it from:

ActiveQt -> Qt For ActiveX

If you have a Jira filter that names this component please update it now.

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

Re: [Development] New Qt5.5.0-RC snapshot available

[Blasche Alexander]

 
> I just went through the git log to confirm. There is nothing of
> interest to put in the changelog for QtQuick1 or QtScript (I'd be
> surprised if I found otherwise). Do you really need an empty file
> there?

I'd say yes. It is information for our customers. No file doesn't tell the 
difference between "no difference worthwhile mentioning" and "we forgot to 
provide the information".
Unfotunately our track record would be an indication for the latter.

I suggest to add a changelog with the usual header and as actual content "No 
changes" or sth similar.

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

Re: [Development] Qt 5.5.0 header diff: QtPositioning.diff

[Blasche Alexander]

> -Original Message-
> Thiago Macieira
> On Friday 05 June 2015 10:10:50 Frederik Gladhorn wrote:
> > -qreal distanceTo(const QGeoCoordinate &other) const;
> > -qreal azimuthTo(const QGeoCoordinate &other) const;
> > +Q_INVOKABLE qreal distanceTo(const QGeoCoordinate &other) const;
> > +Q_INVOKABLE qreal azimuthTo(const QGeoCoordinate &other) const;
> >
> 
> >From C++, the module looks good.
> 
> >From QML, should there be some Q_REVISION above?

It is not required. The above two functions existed in Qt 5.4 already. We 
merely swap the C++ object handling the QML representation for QGeoCoordinate. 
QGeoCoordinate is the new C++ handler and it needs to make the functionality 
available via Q_INVOKABLE.

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

Re: [Development] Switching remote url for qt5 git clone

[Blasche Alexander]

It is an oversight. I fixed it. Thank you for pointing it out.

--
Alex


From: development-bounces+alexander.blasche=theqtcompany@qt-project.org 
 on 
behalf of Harri Porten 
Sent: Monday, March 30, 2015 18:31
To: 
Subject: Re: [Development] Switching remote url for qt5 git clone

On Thu, 26 Mar 2015, Adam Light wrote:

> I'd like to move my checkout to git://code.io.qt.

I got reminded of your mail when I just did a new clone:

http://wiki.qt.io/Building_Qt_5_from_Git suggests the usage of:

   git clone git://code.qt.io/git/qt/qt5.git

but the /git/ part is probably just an oversight?

Harri.
___
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] Marking BB10 unsupported

[Blasche Alexander]

The BB10 code in Qt is not just the platform plugin. Does this statement apply 
to all other BB10 code throughout other Qt modules? To mind comes sensors, 
qtlocation, bluetooth, nfc and maybe multimedia.

And just out of curiosity, how do I distinguish QNX from BB10.The line is often 
very blurry. 

--
Alex


From: development-bounces+alexander.blasche=theqtcompany@qt-project.org 
 on 
behalf of Rafael Roquetto 
Sent: Monday, March 23, 2015 17:59
To: Qt Project Development Mailing-List
Subject: [Development] Marking BB10 unsupported

Hello,

After discussing this with Bernd, who maintains the QNX platform together with
myself, we have decided to mark the BlackBerry 10 platform unsupported.

According to BlackBerry, they are still committed to Qt4 releases, but have no
plans for Qt5. With that in mind, and given the fact that we have limited
resources, maintaining the BB10 port becomes an unfeasible task, and we prefer
to focus on stock QNX, which remains unaffected by this announcement.

The plan is to keep the BB10 plugin around for now (just that we will no longer 
be
officially supporting it), but eventually we plan to remove it completely from
the Qt codebase in case no one looks after it. We will keep it around while it
still works, but there will be no committment on keeping it working.

Kind regards,
Rafael
--
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] C++11 for Examples

[Blasche Alexander]

Hi,

the astute readers who have followed and endured some of the long C++11 related 
threads on this mailing list may have noticed that one important suggestion was 
made with regards to future C++11 usage in Qt.

The suggestion was/is to permit the usage of C++11 in Qt examples. Here is a 
concrete set of suggestions to address the open issues and consequences:

1.) Use C++11 for examples starting with Qt 5.6

2.) Coding convention for C++11 constructs and set of permitted features: 
https://wiki.qt.io/index.php?title=Coding_Conventions#Conventions_for_C.2B.2B11_usage

3.) The coding conventions above imply a set of base line compilers for Qt 
examples (gcc 4.5+, VS2010+, OSX 10.7+)

4.) Don't use any of the macros such as Q_DECL_OVERRIDE (assuming that override 
would be part of the accepted set of features). The examples should be clean 
C++11 code.

The suggestions 2 & 3 above are based on current Qt Creator policy.

You might ask why just lambda and auto as suggestion? The biggest problem is 
that various compilers have differing support for C++11. Therefore each new 
C++11 feature is likely to enforce even stricter/newer example compilers. If 
you want your pet C++11 feature please ensure that the compilers in item 3 
support this feature. Alternatively we may discuss whether the suggested list 
of "example base line" compilers is correct. 

Since

contains(QT_CONFIG, c++11)

is a very coarse qmake check for a given set of C++11 features it is unlikely 
to be useful to serve as enabler for converted examples. Workarounds might be 
to not compile examples on unsupported platforms in the CI anymore or we define 
a new qmake flag that precisely covers the required set of C++ features. The 
latter would certainly be more user friendly.

Comments, suggestions and desires?

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

Re: [Development] OSX 10.7 dropped from Qt?

[Blasche Alexander]

It's definitely gone for 5.5 too:

http://qt-ci.digia.com/view/All/job/QtBase_5.5_Integration/

--
Alex


From: development-bounces+alexander.blasche=theqtcompany@qt-project.org 
 on 
behalf of Rutledge Shawn 
Sent: Monday, March 2, 2015 14:03
To: Sorvig Morten
Cc: development@qt-project.org
Subject: Re: [Development] OSX 10.7 dropped from Qt?

On 2 Mar 2015, at 13:59, Sorvig Morten  wrote:

>> On 27 Feb 2015, at 14:34, Blasche Alexander 
>>  wrote:
>>
>> If 10.7 is required then it should be added back to main CI targets. If it 
>> is not added back then I will remove consequently remove every trace of it.
>
> I don’t think it will be added back. You should remove it from your branch as 
> well.

But only for 5.6, right?

___
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] OSX 10.7 dropped from Qt?

[Blasche Alexander]

Almost all 10.7 targets were dropped from the CI. Only some very obscure 
feature branches didn't get this treatment. Well, it turns out that one of my 
feature branches still runs 10.7 as a target and qtbase/dev doesn't compile 
anymore on 10.7:

https://codereview.qt-project.org/#/c/107381/

The same probably applies to qtbase/5.5 as well as the offending QDateTime 
operator code is the same there too.

Personally I don't care about 10.7 and I have the option to just remove 10.7 
from the branch configuration but is that what we want? Related discussions on 
this mailing went nowhere.

If 10.7 is required then it should be added back to main CI targets. If it is 
not added back then I will remove consequently remove every trace of it.

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

Re: [Development] Nominating Timur Pocheptsov as approver

[Blasche Alexander]

Approver rights have been granted. Congratulations.

--
Alex


From: development-bounces+alexander.blasche=theqtcompany@qt-project.org 
 on 
behalf of Blasche Alexander 
Sent: Thursday, January 22, 2015 07:52
To: development@qt-project.org
Subject: [Development] Nominating Timur Pocheptsov as approver

Hi,

I'd like to nominate Timur Pocheptsov for approver status. He wrote the OSX and 
iOS implementations for QtBluetooth and lately has been increasing his 
footprint in other modules for the same platforms.

https://codereview.qt-project.org/#/q/owner:tpochep,n,z
https://codereview.qt-project.org/#/q/reviewer:tpochep,n,z

A big thank you from me to Timur.
--
Alex
___
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] Nominating Timur Pocheptsov as approver

[Blasche Alexander]

Hi,

I'd like to nominate Timur Pocheptsov for approver status. He wrote the OSX and 
iOS implementations for QtBluetooth and lately has been increasing his 
footprint in other modules for the same platforms.

https://codereview.qt-project.org/#/q/owner:tpochep,n,z
https://codereview.qt-project.org/#/q/reviewer:tpochep,n,z

A big thank you from me to Timur.
--
Alex
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] JIRA broken

[Blasche Alexander]

Everything is back to normal.
--
Alex


From: development-bounces+alexander.blasche=theqtcompany@qt-project.org 
 on 
behalf of Blasche Alexander 
Sent: Monday, January 19, 2015 09:25
To: development@qt-project.org
Subject: Re: [Development] JIRA broken

I can confirm there is a problem with Jira. We'll investigate.

--
Alex


From: development-bounces+alexander.blasche=theqtcompany@qt-project.org 
 on 
behalf of Guido Seifert 
Sent: Sunday, January 18, 2015 13:22
To: development@qt-project.org
Subject: [Development] JIRA broken

when I add:

> Project: Qt

> Issue Type: Bug

> Summary: Ninja for qtwebengine out-of-source build not possible

> Affects Version/s: 5.5

> Component/s: Build System

> Description:

> When I do an out-of-source build, e.g. sources in 'qt5' and a
> '../qt5/configure' in a separate 'qt5-build' folder, ninja for the 
> qtwebengine is
> still build within qt5/qtwebengine/src/3rdparty/ninja/ and not in the 
> qt5-build tree.

> Apart from the pure cosmetic ugliness to have created code in a folder
> below 'src', it is ugly because it taints the sources, which prevents
> to move the source tree easily to a different machine, or have the
> sources read-only.

> Environment: Apparently all

I get:
 Error creating issue: Indexing completed with 1 errors

Guido
___
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] JIRA broken

[Blasche Alexander]

I can confirm there is a problem with Jira. We'll investigate.

--
Alex


From: development-bounces+alexander.blasche=theqtcompany@qt-project.org 
 on 
behalf of Guido Seifert 
Sent: Sunday, January 18, 2015 13:22
To: development@qt-project.org
Subject: [Development] JIRA broken

when I add:

> Project: Qt

> Issue Type: Bug

> Summary: Ninja for qtwebengine out-of-source build not possible

> Affects Version/s: 5.5

> Component/s: Build System

> Description:

> When I do an out-of-source build, e.g. sources in 'qt5' and a
> '../qt5/configure' in a separate 'qt5-build' folder, ninja for the 
> qtwebengine is
> still build within qt5/qtwebengine/src/3rdparty/ninja/ and not in the 
> qt5-build tree.

> Apart from the pure cosmetic ugliness to have created code in a folder
> below 'src', it is ugly because it taints the sources, which prevents
> to move the source tree easily to a different machine, or have the
> sources read-only.

> Environment: Apparently all

I get:
 Error creating issue: Indexing completed with 1 errors

Guido
___
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 Bugtracker update and new URL

[Blasche Alexander]

Just a quick reminder that this is going to happen today. 

--
Alex


From: development-bounces+alexander.blasche=theqtcompany@qt-project.org 
 on 
behalf of Blasche Alexander 
Sent: Monday, December 15, 2014 15:10
To: development@qt-project.org; inter...@qt-project.org; 
qt-crea...@qt-project.org
Subject: [Development] Qt Bugtracker update and new URL

Hi,

It is time to move the Qt bug tracker to its new home under qt.io. The new URL 
is going to be:

https://bugreports.qt.io

The change is going to happen on Wed, 7. January 2015. To facilitate the change 
the old server will be taken offline at 18:00 CET (GMT+1) and the latest 
changes will be copied to the new server. If everything goes well, the new 
server will be online at 20:00 CET (GMT+1). This implies that the Qt bug 
tracker is going to be down for about 2hrs. We are sorry for the inconvenience.

Redirects will be in place following the move and all existing user accounts 
will continue to work.

At the same time, Jira will be updated from 5.x to 6.3. The user interface 
style looks a bit different and you might find some minor new features here and 
there.

As always, if you encounter any problems when using the new Jira instance, 
please file a report against the QTJIRA project 
(http://bugreports.qt.io/browse/QTJIRA) and if you are not even able to login 
you may use jira-admin (at) qt-project.org.

--
Alex
___
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] Qt Bugtracker update and new URL

[Blasche Alexander]

Hi,

It is time to move the Qt bug tracker to its new home under qt.io. The new URL 
is going to be:

https://bugreports.qt.io

The change is going to happen on Wed, 7. January 2015. To facilitate the change 
the old server will be taken offline at 18:00 CET (GMT+1) and the latest 
changes will be copied to the new server. If everything goes well, the new 
server will be online at 20:00 CET (GMT+1). This implies that the Qt bug 
tracker is going to be down for about 2hrs. We are sorry for the inconvenience. 

Redirects will be in place following the move and all existing user accounts 
will continue to work. 

At the same time, Jira will be updated from 5.x to 6.3. The user interface 
style looks a bit different and you might find some minor new features here and 
there. 

As always, if you encounter any problems when using the new Jira instance, 
please file a report against the QTJIRA project 
(http://bugreports.qt.io/browse/QTJIRA) and if you are not even able to login 
you may use jira-admin (at) qt-project.org.

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

Re: [Development] Enabling of QtDBus in Qt 5.4 and 5.5

[Blasche Alexander]

From: development-bounces+alexander.blasche=theqtcompany@qt-project.org 
 on 
behalf of Thiago Macieira 

>Clarifying after question on IRC: will be enabled by default for all builds on
>all OS. Unless you pass -no-dbus, of course.

What's the runtime call that let's me determine what the state of the dbus 
union is on the system?

So far there are two cases:

1.) no dbus (nice qmake check to cut for Windows, Android and some other 
platforms)
2.) dbus available but no daemon or permission issues 
(QDbusConnection::connectToBus(...).isConnected())
3.) all working and enabled

Consequences of eventual 5.5 changes:

- Now I cannot use point 1. above anymore to compile dbus backends out on 
platforms where DBus is useless anyway. That's doable by emulating your 
platform specific enabler in my own modules of course. I guess this is just 
convenience which I lost.

- Case 2 above is even further overloaded. How do I distinguish the no-daemon 
case from permission issues from dlopen failures. Any new API calls for that? 
This is especially important when you don't want to do the "compile dbus out on 
win" checks in qmake. Do I have to duplicate your dlopen() attempt to figure 
that out? How about a "QDBusConnection::platformSupportsDbus()" call?

Personally, I think it is rather useless to enable QtDBus on for example 
Windows. Yes, its better cross-platform programming and there are some esoteric 
guys/projects who use dbus at this stage on Windows. However the default 
setting to enable it for the esoteric use case means you ship tons more code 
for nothing. Alternatives might have been to only enable it when specifically 
requested only (aka change your configure2 option to disabled on windows if no 
dbus option passed) or even compile the lib against some no-op code (which 
would satisfy the true cross platform development use case). I guess you might 
argue that QtDBus is not that large but without more strict qmake changes you 
may create more code to be shipped in other modules/projects too.

What were your reasons/motivation?


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

Re: [Development] Nominating Paul Lemire as Approver

[Blasche Alexander]

Hi,

Congratulations to Paul. Jira and Gerrit rights have been amended accordingly.

--
Alex

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

Re: [Development] Dropping win32-mingw47 from the CI system, adding win32-mingw491 one

[Blasche Alexander]

Hi,

I agree with Kai's assessment. The CI should use the same mingw version as the 
release system.

To not let this task sit forever please speak up if you care about mingw 4.7.x 
rather than using 4.9.x going forward. No negative comment about the plan 
implies universal acceptance after one week :)

--
Alex


From: development-bounces+alexander.blasche=theqtcompany@qt-project.org 
 on 
behalf of Koehne Kai 
Sent: Tuesday, November 25, 2014 09:52
To: development@qt-project.org
Subject: [Development] Dropping win32-mingw47 from the CI system,   adding 
win32-mingw491 one

Hi,

I suggest we drop the win32-mingw47_developer-build-qtlibinfix-Windows 
configuration from the CI, and replace it by one utilizing mingw-builds 
i686-4.9.1-release-posix-dwarf-rt_v3-rev2 . This is in addition with the two 
win32-mingw48 configurations we already have in the CI system.

We've been releasing Qt 5.0 with mingw-builds 
x32-4.7.2-release-posix-sjlj-rev8, and at this time also defined it as a 
'reference' configuration. However, we've long since upgraded our binary 
packages to newer mingw-builds packages, for 5.1 with 
x32-4.8.0-release-posix-dwarf-rev2 , for 5.2 and 5.3 with 
i686-4.8.2-release-posix-dwarf-rt_v3-rev3 , and finally Qt 5.4 will be packaged 
with i686-4.9.1-release-posix-dwarf-rt_v3-rev2.

I'd claim that support for mingw-builds x32-4.7.2-release-posix-sjlj-rev8 isn't 
all that relevant anymore. It also does break already in configurations that we 
don't test (namely ANGLE). The outdated mingw-w64 headers in this package do 
however cause problems, as seen in 
https://codereview.qt-project.org/#/c/100301/ .

Regards

Kai


Kai Köhne, Senior Software Engineer | The Qt Company

Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

Email: kai.koe...@theqtcompany.com | Mobile: + 49 151 55155601 | Phone: +49 30 
63 92 3255 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

Re: [Development] Nominating Louai Al-Khanji as approver

[Blasche Alexander]

Congratulations. The Approver rights have been set in Jira and Gerrit.


--

Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
 on behalf of 
Friedemann Kleint 
Sent: Friday, September 19, 2014 10:31
To: development@qt-project.org
Subject: [Development] Nominating Louai Al-Khanji as approver

Hi,
I'd like to nominate Louai Al-Khanji as approver in the Qt Project:
https://codereview.qt-project.org/#/q/owner:louai.al-khanji,n,z
https://codereview.qt-project.org/#/q/reviewer:louai.al-khanji,n,z
He implemented the Windows Direct2D platform plugin (which works well beyond 
expectations) and has also done significant work in other areas (Qt3D, Wayland).
Regards,
Friedemann

--
Friedemann Kleint
Digia, Qt

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

Re: [Development] Nominating Venugopal Shivashankar and Nico Vertriest as approvers

[Blasche Alexander]

OG Approver rights have been set for Nico and Venugopal. Congratulations.

--
Alex


> -Original Message-
> From: development-bounces+alexander.blasche=digia@qt-project.org
> [mailto:development-bounces+alexander.blasche=digia@qt-project.org]
> On Behalf Of Reinio Topi
> Sent: Tuesday, 16 September 2014 9:31
> To: development@qt-project.org
> Subject: [Development] Nominating Venugopal Shivashankar and Nico Vertriest
> as approvers
> 
> I'd like to nominate Venugopal Shivashankar and Nico Vertriest as approvers in
> 
> the Qt Project. They are both documentation engineers and integral part of
> 
> the of Qt documentation team.
> 
> 
> 
> Venugopal Shivashankar:
> 
> https://codereview.qt-project.org/#/q/owner:veshivas,n,z
> 
> https://codereview.qt-project.org/#/q/reviewer:veshivas,n,z
> 
> 
> 
> Nico Vertriest:
> 
> https://codereview.qt-project.org/#/q/owner:vertries,n,z
> 
> https://codereview.qt-project.org/#/q/reviewer:vertries,n,z
> 
> 
> 
> Both Venu and Nico have been working on Qt for a long time (pre-Qt 5.0)
> 
> already, contributing numerous improvements to Qt documentation. Many
> people
> 
> rely on them for documentation and language reviews, and having them as
> 
> approvers would speed up documentation work and ease the review-burden on
> 
> other team members.
> 
> 
> 
> -Topi

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

Re: [Development] Nominating Antti Kokko and Heikki Halmet as approvers

[Blasche Alexander]

OG Approver rights have been set for Antti and Heikki. Congratulations.

--
Alex

> -Original Message-
> From: development-bounces+alexander.blasche=digia@qt-project.org
> [mailto:development-bounces+alexander.blasche=digia@qt-project.org]
> On Behalf Of Knoll Lars
> Sent: Monday, 15 September 2014 16:29
> To: Curtis Mitch; Salovaara Akseli; development@qt-project.org
> Subject: Re: [Development] Nominating Antti Kokko and Heikki Halmet as
> approvers
> 
> And another +1 from me.
> 
> Cheers,
> Lars
> 
> On 15/09/14 08:46, "Mitch Curtis"  wrote:
> 
> >
> >On 12/09/14 14:55, Salovaara Akseli wrote:
> >
> >
> >Hi,
> >
> >I’d like to nominate Antti Kokko and Heikki Halmet for approver status.
> >
> >They both are essential part of Qt release & CI teams and although only
> >some of their contributions are visible in Gerrit
> >
> >Antti Kokko
> >https://codereview.qt-project.org/#/q/owner:ankokko,n,z
> >https://codereview.qt-project.org/#/q/reviewer:ankokko,n,z
> >
> >Heikki Halmet
> >https://codereview.qt-project.org/#/q/owner:hehalmet,n,z
> >https://codereview.qt-project.org/#/q/reviewer:hehalmet,n,z
> >
> >they are highly important to the project. They both know Qt Project
> >process well and them being Approvers will also make it easier to get
> >releases out in the future.
> >
> >Br,
> >Akseli
> >
> >
> >
> >
> >___
> >Development mailing list
> >Development@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/dev
> >elopment
> >
> >
> >+1
> 
> ___
> 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] Proposal: Rename Qt WebSockets QML import

[Blasche Alexander]

--
Alex


> -Original Message-
> From: development-bounces+alexander.blasche=digia@qt-project.org
> [mailto:development-bounces+alexander.blasche=digia@qt-project.org]
> On Behalf Of Sze Howe Koh

> To bring the WebSocket QML import name in line with other modules
> (e.g. "QtWebEngine 1.0", "QtQuick 2.x", "QtWebKit 3.x", "QtSensors
> 5.x"), I propose changing the import:
> 
> - From "import Qt.WebSockets 1.0"
> - To "import QtWebSockets 1.1" (no dot between "Qt" and "WebSockets")

I was considering to do the same a couple of days ago when I fixed the docs for 
it. If/when you do this please don't forgot to update the docs too.

However why bumping the version?  It would be just a rename while retaining the 
old name.

If you must bump it it should rather be a bump it to 5.x. This forest of 
versions is just confusion without no purpose.

> Ideally, the old import name + version number would still be available
> for compatibility, while newer versions would use the new name. Is
> this supported?

Yes this can be done. It's just a matter of testing for both strings in the 
plug-ins type registrations.

> What does everyone think?
+10 ;)

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

Re: [Development] call for comments/review QSystemInfo::NetworkInfo API

[Blasche Alexander]

> >From a 1 feet Qt as a product point of view, it's not evident why this 
> >API
> belongs into a separate module instead of simply into the Qt network module.

That's a historical reason and Qt's inability to accept such a contribution at 
the time when such changes were needed. This doesn't mean those reasons weren't 
valid at the time. In some cases it is desirable to have QML interfaces for 
those classes and when you move those classes into qtbase the dependencies are 
not correct. I guess one could add them to qtdeclarative as well. After all the 
same has happened for other qtbase classes too.

On the positive side there are quite a few cases in more recent Qt history 
where such moves did happen. The QStorageInfo is an excellent example. The 
QtSystemInfo class with the same name is pretty much obsolete now. As more such 
moves happen I am sure that the content in QSystemInfo diminishes further. I 
would encourage Lorn to consider a merge the network related QNetworkInfo API's 
into QtNetwork. 


> In regards to the publish/subscribe and serviceframework bits, I wonder what
> the plan is with those.  How much overlap between them and Replicant is there?

Potentially there is a significant overlap. The principle is the same and no 
there are no immediate plans for them. It's no different than the jsondb repo 
except that the principle applications are probably somewhat more in demand 
than jsondb.

I wish a day had more than 24hrs 

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

Re: [Development] Qt Location module

[Blasche Alexander]

> -Original Message-
> From: development-bounces+alexander.blasche=digia@qt-project.org
> On Behalf Of Kate Alhola

> The map component for QtQuick2 is part or qtlocation sources but to
> be enabled it requires to fetch qt3d from git, compile and install and then
> compiling qtlocation again and you get maps. For desktop the maps compiles and
> installs without problems but for Android and IOS small tweaking is required.

The Qt3D dependency was removed in the 5.4 branch.


> On Behalf Of Chris Adams
> My understanding is that the QtLocation module from QtMobility got split into
> separate modules: QtPositioning and QtLocation (although they're located 
> within
> the same source repo in qt5 still, if memory serves).

Same repo, two modules, QtPositioning has been released and is supported, 
QtLocation hasn't been released.

> Aaron McCarthy has been actively maintaining the QtPositioning module, but
> QtLocation still needs some work until it can be released, from what I 
> understand.
> Obviously, the more people who are able to contribute to the effort, the 
> quicker
> that can happen :-)  Aaron is on holiday at the moment, but no doubt he'll
> respond to this thread shortly.

Indeed. The main problem is time/manpower.


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

Re: [Development] Jira bug cleanup

[Blasche Alexander]

> -Original Message-
> From: Konstantin Ritt [mailto:ritt...@gmail.com]
> Sent: Wednesday, 17 September 2014 0:41
> To: Blasche Alexander
> Cc: inter...@qt-project.org; development@qt-project.org
> Subject: Re: [Development] Jira bug cleanup
> 
> Hi,
> 
> How about task assigned to wrong persons (i.e. inactive people, people who are
> not a Nokia/Digia employee anymore, etc.)? Do we still have such ones?

That's certainly a worthy goal but not in scope for this week. There is no way 
to actually filter by inactive assignees. I am only aware of the "inactive" 
flag in the user management interface and when trying to assign something to 
inactive users. I'll happily agree if somebody proves me otherwise.

In any case because you cannot filter tasks by this flag such changes would 
have to be done on an individual base only.  Therefore this is more like a long 
term task which I might pursue every now and then.

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

[Development] Jira bug cleanup

[Blasche Alexander]

Hi,

One of the topics discussed during the last Qt contributor summit was the 
cleanup of our bug database. If you are interested in the outcomes check out:

https://qt-project.org/groups/qt-contributors-summit-2014/wiki/Expiring_Bugs

Finally I got some time to take care of the results. My plan is to perform 
these expiries on Friday this week.

The first step will be the closure of all bugs (and only bugs) in the "Need 
more info" state which have not seen any activity for the last year. An 
appropriate comment will be added to each Jira bug explaining the action and 
advising people how to react to it depending on their circumstances.

The second step is the transition of Unassigned bugs to the "Need more info" 
state if they have not seen any update during the last year. A comment will go 
along with the transition. 

You can avoid this happening to "your" important bugs by means of touching 
them. Also, feel free to revert some transitions as you may see fit in your 
work area.

Going forward I will repeat this in regular intervals (3 months) and reduce the 
"no update received" timeout to six and later three month in the case of of 
tasks in the "Need more info" state. This should result in a eventual setup 
whereby Unassiged/reported bugs expire after 12 months and "Need more info" 
bugs expire after 3 months.

If there are major objections to the proposed target for this week please raise 
them now.
--
Alex
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Bluetooth Headset Profile

[Blasche Alexander]

> -Original Message-
> From: development-bounces+alexander.blasche=digia@qt-project.org
> [mailto:development-bounces+alexander.blasche=digia@qt-project.org]
> On Behalf Of Ahmet Dogan


> I have written forum and mail lists but I haven't got any answer about
> my problem if you answer me I will be more than happy.
> 
> I just want to connect headset or handsfree service which are provided
> by a mobile phone.To do this I am doing this steps:
> 
> 1)open/check local bluetooth with QBluetoothLocalDevice
> 2)scan devices with QBluetoothDeviceDiscoveryAgent
> 3)choose devices and scan services with QBluetoothServiceDiscoveryAgent
> 4)create a rfcomm protocol with QBluetoothSocket than connect service on
> the phone

I am not the media expert with regards to Bluetooth but it is my understanding 
that you need a SCO socket to connect media devices. AFAIK an rfcomm socket is 
required but for the audio sream you need a SCO socket. Unfortunately SCO is 
not supported by QBluetoothSocket.

In general there is no Headset support in Qt Bluetooth.

--
Alex


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

Re: [Development] Linux release binaries too old

[Blasche Alexander]

--
Alex


> -Original Message-
> From: development-bounces+alexander.blasche=digia@qt-project.org
> [mailto:development-bounces+alexander.blasche=digia@qt-project.org]
> On Behalf Of Thiago Macieira


> That would mean these are the minimum versions the popular distros (release
> month in parentheses):
>   Arch (rolling release)
>   CentOS 7.0 (7/2014)
>   Debian testing (no release!)
>   Fedora 17 (5/2012)
>   Mageia 3 (5/2013)
>   Mint 13 (5/2012)
>   OpenSUSE 12.2 (9/2012)
>   Ubuntu 12.04 (4/2012)

Ok, I agree that we cannot leave stable Debian behind. 

However I'd like to clarify how and where we formalize which of the distros 
above we care about and/or what condition must be fulfilled when doing an 
upgrade. Not every case is as clear cut as the Debian one.  There is no 
formalization or reference page that I can find. Our docs only talk about 
11.10, 12.04 and occasional 11.04 tests. 
 
> In other words, by upgrading our Ubuntu 11.10 build, we'll drop support for
> any released Debian. I don't think we can do it.

This leaves me with only one option. We have to deploy Bluez 4.101 headers to 
11.10 machines.  It doesn't even have to be a full backport as the dependency 
is a compile time dependency.  My tests have shown that calling ::connect() 
with an extended sockaddr_l2 struct doesn't seem to cause any trouble on those 
older distros. 

Can we agree on that?

--
Alex

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

Re: [Development] Linux release binaries too old

[Blasche Alexander]

> -Original Message-
> From: development-bounces+alexander.blasche=digia@qt-project.org
> [mailto:development-bounces+alexander.blasche=digia@qt-project.org]
> On Behalf Of Alejandro Exojo


> How feasable is to backport a newer BlueZ to that old distro, on the machines
> that build the binaries? I managed to do a quick and dirty BlueZ 5 backport to
> Debian stable quite easily (where "easy" means I got the backported kernel
> already on the distro, so that's done). I can give it a try if needed, since
> BlueZ 4 should be easier. I don't remember any kernel requirements.

The Bt LE feature requires 3.5 kernel or above. My guess would be that a kernel 
below that version (although maybe Bluez support it) won't enable the feature.

In theory we should be able to deploy newer headers to old 11.10. The 
dependency is "just" a compile time one. After that it's just interaction 
between Qt and the kernel.
 
> > Bluetooth requires the newer headers only at build time. I tested binaries
> > on 12.04 by faking the new symbols and it still seemed to work.
> >
> > The question is how many old distros do we leave behind? Bluez 4.101 was
> > released in June 2012. If distros update Qt they are likely to recompile
> > anyway.
> 
> Release dates are a bit misleading here. ;-)
> 
> Compare the popularity of Qt4 vs Qt5 applications on distributions. With BlueZ
> is worse, since is a complete rewrite of the API. Even the most recent Ubuntu
> is still on BlueZ 4.

Bluez 4 or 5 doesn't matter. Qt 5.4 supports both and uses whichever Bluez 
version it can find at runtime.

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

[Development] Linux release binaries too old

[Blasche Alexander]

Hi,

It is my understanding that the current Linux release binary packages are built 
on Ubuntu 11.10 machines. This is very ancient. In fact for Bluetooth Low 
Energy (new feature in 5.4) this is too ancient.

What's needed is a machine that has Bluez 4.101 or newer. This means even the 
fairly old 12.04 is too old unless we retrofit those newer headers. If we don't 
want to retrofit and assuming we want to stay with Ubuntu we'd require 14.04.

Bluetooth requires the newer headers only at build time. I tested binaries on 
12.04 by faking the new symbols and it still seemed to work. 

The question is how many old distros do we leave behind? Bluez 4.101 was 
released in June 2012. If distros update Qt they are likely to recompile anyway.


--

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

Re: [Development] QtLocation in Qt 5.4?

[Blasche Alexander]

Hi Martin,

I just returned from holiday and the feature freeze did happen while I was gone.

On the positive side the branching has happened. On the negative side I have 
not yet made a decision on whether there is going to be any type of release. I 
need to consult with the relevant stack holders to start with. 

Considering that a full release would require a significant maintenance effort 
afterwards, I think the most you can expect (if any) is some form of tech 
preview. It also depends on what kind of commitments I get from developers 
working on it.

--
Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
martin.kro...@ehrhardt-partner.com [martin.kro...@ehrhardt-partner.com]
Sent: Thursday, July 31, 2014 15:39
To: development@qt-project.org
Subject: [Development] QtLocation in Qt 5.4?

Hi,
is it planned to release QtLocation with Qt 5.4 as Alex mentioned in
http://article.gmane.org/gmane.comp.lib.qt.devel/16238 ?
There is nothing about in the "feature list" on
http://qt-project.org/wiki/New-Features-in-Qt-5.4
What is the state of development?

Best regards
Martin Kröll

___
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] Bluetooth LE

[Blasche Alexander]

Hi Andrew,

Happy to add you. I just setup qtconnectivity.git wip/win branch up for this 
purpose.


--

Alex


From: Knight Andrew
Sent: Tuesday, July 15, 2014 14:38
To: Denis Shienkov; Blasche Alexander; development@qt-project.org
Subject: RE: [Development] Bluetooth LE

Hi Denis/Alex,

I can't promise much development time, but I'd be happy to participate in 
reviews/testing for the Windows backends. The WinRT/WinPhone port might also 
benefit from these and so we should try to share code there if possible.

-Andrew

From: Denis Shienkov<mailto:denis.shien...@gmail.com>
Sent: ‎15/‎07/‎2014 13:23
To: Blasche Alexander<mailto:alexander.blas...@digia.com>; 
development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] Bluetooth LE

Alex,

> is that Windows could potentially support the entire QtBluetooth stack 
> (classic and low energy)

Yes. But Windows also has restrictions for BLE (I mean, the MS BT stack has 
restrictions):

1. BLE is supported from Windows 8 and newest
2. BLE in Windows do not support discovery (has no public Win32 API for it).

> If you have the time to help out on iOS or Windows (or even in general) 
> please let me know and I happily sort the details out with you.

Yes. I have a few free time to help with Windows (Win32)  (classic && low 
energy).

BR,
Denis



2014-07-15 14:05 GMT+04:00 Blasche Alexander 
mailto:alexander.blas...@digia.com>>:
Hi Denis,

> -Original Message-
> From: Denis Shienkov 
> [mailto:denis.shien...@gmail.com<mailto:denis.shien...@gmail.com>]

> and what plans for support of BLE in  Windows?
>
>
> PS: E.g. I'm currently can help with Windows (MS BLE stack). I have an some 
> BLE
> devices..

It' pretty much the same situation as on iOS. It depends on the kind of support 
from other developers.

The only "minor?" difference between the two platforms is that Windows could 
potentially support the entire QtBluetooth stack (classic and low energy) 
whereas iOS can only ever support BLE.

If you have the time to help out on iOS or Windows (or even in general) please 
let me know and I happily sort the details out with you.

--
Alex
___
Development mailing list
Development@qt-project.org<mailto: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] Bluetooth LE

[Blasche Alexander]

Hi Denis,

> -Original Message-
> From: Denis Shienkov [mailto:denis.shien...@gmail.com]

> and what plans for support of BLE in  Windows?
> 
> 
> PS: E.g. I'm currently can help with Windows (MS BLE stack). I have an some 
> BLE
> devices..

It' pretty much the same situation as on iOS. It depends on the kind of support 
from other developers.

The only "minor?" difference between the two platforms is that Windows could 
potentially support the entire QtBluetooth stack (classic and low energy) 
whereas iOS can only ever support BLE.

If you have the time to help out on iOS or Windows (or even in general) please 
let me know and I happily sort the details out with you.

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

Re: [Development] Bluetooth LE

[Blasche Alexander]

Hi,

It is being worked on and there will likely be some elements of it in 5.4. 
Whether it will be a tech preview or a regular release is yet to be determined 
as that depends on whether it will be done in time.

Current target platforms are Linux and Android. I am fairly certain that there 
won't be any iOS support unless somebody is willing to help out on that front.

--
Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Karl Beecher [k...@endocode.com]
Sent: Friday, July 11, 2014 14:32
To: development@qt-project.org
Subject: [Development] Bluetooth LE

Hi,

I’m currently looking to build a Qt-based app for Android and iOS. One
of the requirements for the app is that it connects to a device using
Bluetooth LE.

I’ve been told that Bluetooth LE support is planned for a future Qt
release. Could I ask what the current status of this is for both Android
and iOS?

Many thanks.

Karl
___
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] Gerrit dropping CI failure mails?

[Blasche Alexander]

From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Oswald Buddenhagen >
>i tried to reduce the flood somewhat by denying the bots (including CI)
>the right to mail reviewers, so only the owner now gets the emails.
>on the downside, you now need to pay more attention in case you adopt a
>change from someone else, as you are still a reviewer as far as gerrit
>is concerned ...


Please revert this "feature". Why is this important?

1. ) I don't have to frequently poll all the changes which I review for their 
failures. I use gerrit via email push and not website poll. Why should I change 
to back to such less efficient method?

2.) I receive a significant number of patches from devs who don't have approver 
rights and need some considerable hand-holding. Now they have to constantly 
ping me when something fails. This is especially bad when it was me who was 
staging it on their behalf. If you have weired CI errors, license check 
failures or unintended platform side effects the amount of handholding goes up 
signficantly.

3.) I monitor progress in my code areas because I review the parts which are 
relevant. Subsequently I don't just want to monitor their success.

I can understand that some code lines are very buggy and require more attempts 
(hence more failure "spam"). Then again we should focus on stabilizing them. 

Also it is dead simple to filter those failures out of your mailbox. All you 
have to look for is "FAILURE" and check that "Gerrit-Owner:" is not you. This 
way you don't force a behavior change on everybody else. Right now I am feeling 
forced.

Is it just me or how much does everybody else rely on it?

--
Alex


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

Re: [Development] NOTE: Gerrit / Codereview upgrade – Service unavailable Friday June 13, 7:00 – 10:00 CEST

[Blasche Alexander]

Hi Ismo,

So far everything seems to be already.

Thank you very much for your work.


--

Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Haataja Ismo [ismo.haat...@digia.com]
Sent: Friday, June 13, 2014 09:44
To: development@qt-project.org
Subject: Re: [Development] NOTE: Gerrit / Codereview upgrade – Service 
unavailable Friday June 13, 7:00 – 10:00 CEST

Hi,

Deployment was successful, thanks for your patience.

If you find any problems, please let me know as soon as possible!

Best Regards,
Ismo

From: development-bounces+ismo.haataja=digia@qt-project.org 
[mailto:development-bounces+ismo.haataja=digia@qt-project.org] On Behalf Of 
Haataja Ismo
Sent: 12. kesäkuuta 2014 16:12
To: development@qt-project.org
Subject: [Development] NOTE: Gerrit / Codereview upgrade – Service unavailable 
Friday June 13, 7:00 – 10:00 CEST

Just to remind this will happen tomorrow morning.

Hi,

Gerrit (https://codereview.qt-project.org/) will be unavailable while we deploy 
a new version.

The upgrade takes the current v2.2.1 based version to v2.7 based. Most of our 
customized features stay: staging system for CI, one page review and deferred 
changes. The topic review feature, very little used and not functioning 
properly, is dropped. The user experience should stay pretty much the same. 
There are some UI improvements, though, and of course a lot of bug fixes.

Full history of how Gerrit itself has evolved between these versions can be 
read from Gerrit release notes 
(https://gerrit-documentation.storage.googleapis.com/ReleaseNotes/index.html). 
Some usability related picks here.
* search operators are suggested as the user types the query in the search panel
* commit message can be edited from the change screen
* patch sets having unpublished draft comments are highlighted with an icon
There is plenty of new stuff, one needs to read the documentation for deeper 
knowledge.

I’ll send out a follow-up once the service is online again.

Regards,

Ismo

--
Ismo Haataja
Senior Software Specialist - Digia, Qt

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

Re: [Development] Jira component re-arrangements

[Blasche Alexander]

Hi Gatis,

Thank you very much for stepping up. I have not seen any further volunteers and 
I think it is safe to assume that there won't be anybody else at the moment. I 
have set you up as the default assignee.

--
Alex


From: Paeglis Gatis
Sent: Monday, June 02, 2014 23:13
To: Gunnar Sletta; Blasche Alexander
Cc: development@qt-project.org
Subject: RE: [Development] Jira component re-arrangements

> I would not be terribly upset if somebody that actually did work on the xcb 
> plugin stepped up and took this one :)

 I would not say that I know all parts of the XCB plugin (yet), but I guess I 
feel comfortable enough to be the default
 assignee if nobody else is volunteering.

Gatis.

From: development-bounces+gatis.paeglis=digia@qt-project.org 
[development-bounces+gatis.paeglis=digia@qt-project.org] on behalf of 
Gunnar Sletta [gunnar.sle...@jolla.com]
Sent: Tuesday, May 13, 2014 12:29 PM
To: Blasche Alexander
Cc: development@qt-project.org
Subject: Re: [Development] Jira component re-arrangements

On 13 May 2014, at 11:18, Blasche Alexander  wrote:

> Hi,
>
> Following some discussions on this list and in Jira I have made changes to 
> Jira components. If you have a filter that explicitly mentions one of the 
> affected components, please adjust them now. Otherwise you filter may not 
> return the correct results going forward.
>
> 1.)
> - "Core: Gesture Support" -> "Widget: Gesture Support" (rename)
> - New owner for above component: Marc Mutz
>
> For more details see QTJIRA-255
>
> 2.)
> Following new components have been created:
> "GUI: Windows integration" -> owner: Friedemann Kleint
> "GUI: X11 (xcb) integration" -> owner: Gunnar Sletta

I would not be terribly upset if somebody that actually did work on the xcb 
plugin stepped up and took this one :)

> "GUI: OS X (cocoa) integration" -> owner: Morton Sorvig
>
> For more details see QTJIRA-256
>
> 3.)
> - "Core: Event System" -> "Core: Event loop" (rename)
>
> For more details see QTJIRA-257
>
> 4.)
> - "GUI: Input methods" ->"GUI: Complex Input methods" (rename)
> - "GUI: Basic Input System (keyboard, mouse, touch)" (created)
> - New owner for "Basic Input System": Gunnar Sletta
>
> For more details see QTJIRA-258
>
> --
> Alex
>
> ___
> 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

[Development] Jira component re-arrangements

[Blasche Alexander]

Hi,

Following some discussions on this list and in Jira I have made changes to Jira 
components. If you have a filter that explicitly mentions one of the affected 
components, please adjust them now. Otherwise you filter may not return the 
correct results going forward.

1.)
- "Core: Gesture Support" -> "Widget: Gesture Support" (rename)
- New owner for above component: Marc Mutz

For more details see QTJIRA-255

2.)
Following new components have been created:
"GUI: Windows integration" -> owner: Friedemann Kleint
"GUI: X11 (xcb) integration" -> owner: Gunnar Sletta
"GUI: OS X (cocoa) integration" -> owner: Morton Sorvig

For more details see QTJIRA-256

3.)
- "Core: Event System" -> "Core: Event loop" (rename)

For more details see QTJIRA-257

4.) 
- "GUI: Input methods" ->"GUI: Complex Input methods" (rename)
- "GUI: Basic Input System (keyboard, mouse, touch)" (created)
- New owner for "Basic Input System": Gunnar Sletta

For more details see QTJIRA-258

--
Alex

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

Re: [Development] Qt5.3 / Location Maps

[Blasche Alexander]

Hi,

Not sure what kind of custom mods you have but a module "claims" plugin 
ownership via 

MODULE_PLUGIN_TYPES = geoservices (see qtloation.pro)

The plugin declares its type via 

PLUGIN_TYPE = geoservices (e.g. see src/plugins/geoservices/osm/osm.pro

And the system enforces this in mkspecs/features/create_cmake.pf

My guess is that your code doesn't do one of the above two steps.

--
Alex

> -Original Message-
> From: development-bounces+alexander.blasche=digia@qt-project.org
> [mailto:development-bounces+alexander.blasche=digia@qt-project.org]
> On Behalf Of Kate Alhola
> Sent: Sunday, 11 May 2014 12:54
> To: Aaron McCarthy
> Cc: development@qt-project.org
> Subject: Re: [Development] Qt5.3 / Location Maps
> 
> I just updated to Qt5.3RC and noticed that something has changed in modules
> build system since beta.
> I was able to compile QtQuick1 maps I ported form 4.8 with Beta but mo more
> with 5.3RC or least not for ios.
> 
> 
> There is issue that I got error
> Project ERROR: No module claims plugin type 'geoservices'
> 
> This error did not appear in 5.3beta
> 
> Reason is that in 5.3RC it requires mkspecs/modules/qt_lib_location.pri with 
> line
> QT.location.plugin_types = geoservices
> This file is created with new Qt5Location that requires qt3d and qt3d is not
> compiling as static lib required for ios
> I got QtQuick1 maps compiled for Linux/OSX/Android when I first compiled and
> installed qt3d and then rebuild location with new maps even the QtQuick1 maps
> does not require either of them.
> 
> I have tried find out where this mkspecs//modules/qt_lib_location.pri ic 
> created
> but I have not yet find out that. Least it was not required in Beta to compile
> Qtquick1 maps.
> 
> Any hints to documents how to create  mkspecs/modules/qt_lib_location.pri
> and any hint how to compile qt3d for ios
> 
> Kate
> 
> 
> 

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

Re: [Development] Nominating Jake Petroules as approver

[Blasche Alexander]

The waiting period is over. I welcome Jake on the list of approvers. Jira and 
Gerrit modifications were done.

--
Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Thiago Macieira [thiago.macie...@intel.com]
Sent: Tuesday, April 15, 2014 19:13
To: development@qt-project.org
Subject: [Development] Nominating Jake Petroules as approver

Hello

I'd like to nominate Jake Petroules as approver. He's been very active in the
Mac port in the recent months, helping out with issues like adding support for
the CoreFoundation types in QtCore, among other tasks. He's located in the US
West Coast, which helps me with reviews in late afternoons.

Here's a link to his submissions
 https://codereview.qt-project.org/#q,owner:jake.petrou...@petroules.com,n,z

Reviews:
 https://codereview.qt-project.org/#q,reviewer:jake.petrou...@petroules.com,n,z

And dashboard:
 https://codereview.qt-project.org/#dashboard,1000530

--
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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Updating JIRA components relating to events.

[Blasche Alexander]

Hi,

I renamed it on request. It was such a minor change that I didn't see an issue 
especially since the component doesn't have a default assignee. Obviously that 
is not the case. 

Paul, you have to rename your filter again. Filtering on the name string is 
rather stupid but that's what jira does. It should really filter on component 
ID which does internally exist. Not Paul's fault though but I need to remember 
this.

On Friday 25 April 2014 17:27:23 Thiago Macieira wrote:
> I've been reassigning to that component anything that is related to *any*
> input method, especially mouse, keyboard and touch, which bug reporters
> often  submit to "Core: Event System".

I hope you reassigned it to another person? Otherwise they just end up in a 
virtual dead end considering that their is no ownership in the component.

I changed it back for now. Before we create any new components I would like to 
see some ownership. Otherwise this is just an exercise in moving from one 
bucket to the next without any purpose.

--
Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Paul Olav Tvete [paul.tv...@digia.com]
Sent: Monday, April 28, 2014 10:19
To: development@qt-project.org
Subject: Re: [Development] Updating JIRA components relating to events.

On Friday 25 April 2014 17:27:23 Thiago Macieira wrote:
> I've just noticed that the "GUI: Input methods" component in JIRA has got
> an  update now saying "(Non-Latin languages)". That is, it seems the
> purpose of that component has changed to mean complex input methods only.
>
> I've been reassigning to that component anything that is related to *any*
> input method, especially mouse, keyboard and touch, which bug reporters
> often  submit to "Core: Event System".
>
> Can I ask that we create a "GUI: Basic Input Method (keyboard, mouse,
> touch)"  component? Does anyone feel like being the default assignee?
> Please reply in QTJIRA-258.

As I commented in the task, I would like to request a reversal of the "Non-
Latin languages" renaming. On Android, we use exactly the same infrastructure
for input of Latin-based languages. (Also, there are several non-Latin scripts
that can use simple keyboard input on a desktop computer.) If we have to
rename, I support Thiago's suggestion of "Complex input methods", possibly
with a "text" or "language" thrown in.

[Apology in advance for small rant.]

In the future, could we please not rename components silently without warning?
This renaming effectively edited several of my tasks, making them misleading.
As a bonus it also messed up my filters.

- Paul
___
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.3 header diff: QtPositioning

[Blasche Alexander]

>
>Sent: Wednesday, April 23, 2014 01:35
>To: development@qt-project.org
>Subject: Re: [Development] Qt 5.3 header diff: QtPositioning

>Why do we need two sets of macros?

Excellent question.

https://codereview.qt-project.org/#change,83875

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

Re: [Development] Changelogs for 5.3.0

[Blasche Alexander]

qtconnectivity and qtlocation were taken care of by me.

--
Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Thiago Macieira [thiago.macie...@intel.com]
Sent: Wednesday, April 23, 2014 00:13
To: development@qt-project.org
Subject: [Development] Changelogs for 5.3.0

Please find attached the raw logs for each of the modules that had any
[ChangeLog] in the v5.2.1..origin/release range.

I'm taking responsibility of editing the one for qtbase.

For all other modules, I'd like someone to reply to this email saying they'll
be the editor. Otherwise, there will be no changelog for the module at all,
because I won't do it.
--
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] Nominating Giulio Camuffo (giucam) as an Approver

[Blasche Alexander]

Congratulations,

Approver rights have been set in Gerrit and Jira.

--
Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Nichols Andy [andy.nich...@digia.com]
Sent: Tuesday, April 01, 2014 12:58
To: development@qt-project.org
Subject: [Development] Nominating Giulio Camuffo (giucam) as an Approver

Hello fellow Qt developers,

I would like to nominate Giulio Camuffo for Qt Project approver status.
Giulio has been contributing to the QtWayland module for over a year now with 
both quality code submissions as well as code reviews.
He is easy to get in touch with on IRC, and is responsive when added as a 
reviewer on gerrit.
I am confident that Giulio's knowledge of and passion for QtWayland will make 
him a responsible approver.

irc: giucam
https://codereview.qt-project.org/#q,owner:giucam,n,z
https://codereview.qt-project.org/#q,reviewer:giucam,n,z

Regards,
Andy Nichols
___
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] Nominating Bernd Weimer as approver

[Blasche Alexander]

Hi Thiago,

I did that already:

http://lists.qt-project.org/pipermail/development/2014-April/016378.html

I think you just doubled up on Gerrit later on :).

--
Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Thiago Macieira [thiago.macie...@intel.com]
Sent: Wednesday, April 16, 2014 16:59
To: development@qt-project.org
Subject: Re: [Development] Nominating Bernd Weimer as approver

Em qua 16 abr 2014, às 07:51:50, Blasche Alexander escreveu:
> >15 working days have passed, so Bernd is now an approver of the Qt Project.
> >
> >I've added him to the Approvers group on Gerrit, but somebody else would
> >need to grant him rights in JIRA.
>
> Done.

Hi Alex

Can you do the same for Sze? I didn't do that.
--
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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Bernd Weimer as approver

[Blasche Alexander]

>15 working days have passed, so Bernd is now an approver of the Qt Project.
>
>I've added him to the Approvers group on Gerrit, but somebody else would
>need to grant him rights in JIRA.

Done.

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

Re: [Development] Nominating Sze Howe Koh as approver

[Blasche Alexander]

Approver rights have been set in Jira and Gerrit. Congratulations to Sze-Howe.

--
Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Thiago Macieira [thiago.macie...@intel.com]
Sent: Sunday, March 23, 2014 00:50
To: development@qt-project.org
Subject: [Development] Nominating Sze Howe Koh as approver

Hello

I'd like to nominate Sze Howe Koh as approver. You must have seen the number
of contributions already done in the mailing list discussions, but you may not
have seen the contributions done to Qt documentation.

Here's the link to the submissions made:
https://codereview.qt-project.org/#q,owner:szehowe@gmail.com,n,z

And reviews made:
https://codereview.qt-project.org/#q,reviewer:szehowe@gmail.com,n,z

And here are Sze's dashboard:
https://codereview.qt-project.org/#dashboard,1002192

--
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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtlocation failed to compile during qt5.git release integration

[Blasche Alexander]

I pushed a temporary fix.

https://codereview.qt-project.org/#change,83254

I'd like to ask why only the qt5.git integration uses static CI configurations 
(for Ubuntu and OSX 10.7). If qt5 integration would use the same targets as any 
other repo build we wouldn't have this kind of hickup and mistakes would be 
caught much earlier.

--

Alex




From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Heikkinen Jani [jani.heikki...@digia.com]
Sent: Friday, April 11, 2014 07:00
To: development@qt-project.org
Subject: [Development] qtlocation failed to compile during qt5.git release 
integration

Hi,
qtlocation failed to compile :(

ld: library not found for -lqtposition_positionpoll
make[4]: *** [positioning_cppsnippet.app/Contents/MacOS/positioning_cppsnippet] 
Error 1
make[3]: *** [sub-cpp-make_first] Error 2
make[2]: *** [sub-positioning-doc-snippets-make_first] Error 2
make[1]: *** [sub-src-make_first] Error 2
make: *** [module-qtlocation-make_first] Error 2

Build log: 
http://testresults.qt-project.org/ci/Qt5_release_Integration/build_00313/macx-clang_static_OSX_10.7/log.txt.gz

Can someone fix this, thanks!

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

Re: [Development] Nominating Ulf Hermann as approver

[Blasche Alexander]

Congratulations to Ulf. Gerrit and Jira details have been adjusted.

--
Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Simon Hausmann [simon.hausm...@digia.com]
Sent: Tuesday, March 04, 2014 13:51
To: development@qt-project.org
Subject: [Development] Nominating Ulf Hermann as approver

Hi,

I'd like to nominate Ulf for approvership. He's been hacking on various bits
and pieces in the profiler support in Qml and he also implemented a brand new
profiler for the JavaScript engine.

I'm convinced that he would make a careful and responsible approver.

Patches:

https://codereview.qt-project.org/#q,owner:ulf.hermann%2540digia.com,n,z
(don't forget the "next" button ;)

And here's a list of him as a reviewer:

https://codereview.qt-project.org/#q,reviewer:ulf.hermann%2540digia.com,n,z



Any seconds? :)


Simon
___
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] QtLocation in Qt5

[Blasche Alexander]

Hi,

It is possible to display maps in QtLocation 5.2 and 5.3. I would recommend 5.3 
though as it has a lot more fixes. There isn't much of a feature difference 
between the two versions of QtLocation. 

You have to use QML for the map logic. There is no equivalent C++ API at this 
stage. The reason is the shift away from GraphicsView in QtMobility to 
Qt3D/QML/Declarative in Qt 5.x.  

However I would like to point out that the QtLocation API is not yet released. 
The main reason for the delay are some missing architectural changes (removal 
of Qt3D). On the positive side, the QML API for QtLocation 5.3  will commit on 
its API (despite the missing release). That's another reason why I'd recommend 
5.3. 

The most likely official release target is going to be Qt 5.4 considering that 
Gunnar just wrote a patch removing Qt3D.

--
Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
martin.kro...@ehrhardt-partner.com [martin.kro...@ehrhardt-partner.com]
Sent: Monday, March 24, 2014 10:32
To: development@qt-project.org
Subject: [Development] QtLocation in Qt5

Hi,
I've a question about the current development state of the QtLocation
module.
We are currently porting our application to Qt5 and we used QtMobility for
displaying a map in Qt4.8.
I checked the qt/qtlocation repository but it seems that all sources for
displaying map in a c++ application are missing.

So, do we have no chance to display maps in Qt5.2? What are the plans for
Qt5.3?

Best regards
Martin Kröll

___
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 Bluetooth iOS

[Blasche Alexander]

Hi,

It doesn't matter by what Qt module the feature is provided, the profile is not 
supported by iOS/Apple. For details on supported profiles see:

http://support.apple.com/kb/ht3647


--

Alex


From: Pau Garcia i Quiles [pgqui...@elpauer.org]
Sent: Friday, March 14, 2014 21:21
To: Blasche Alexander
Cc: development@qt-project.org; Laszlo Papp
Subject: Re: [Development] Qt Bluetooth iOS

Hello,

Actually I am mostly interested in Serial Port Profile over Bluetooth. Maybe 
this should be implemented as part of Qt Serial Port insted of Qt Bluetooth?


On Fri, Mar 14, 2014 at 10:50 AM, Blasche Alexander 
mailto:alexander.blas...@digia.com>> wrote:
Hi,

One more update on this topic. After some investigations yesterday it turns out 
that iOS doesn't actually have a classic Bluetooth API. There is a Bluetooth 
Low Energy API since iOS 6 but this would require the Bluetooth Low Energy 
(BtLE) feature first. While BtLE is currently in the works, there is no firm 
target release yet (ready when it's ready).

The only other Bluetooth related API I could find was related to the External 
Accessory Framework. An accessory may happen to be a Bluetooth device but 
that's not really the same.

Of course MacOSX and the windows flavours have some Bluetooth opportunities.


--

Alex


From: 
development-bounces+alexander.blasche=digia@qt-project.org<mailto:digia@qt-project.org>
 
[development-bounces+alexander.blasche=digia@qt-project.org<mailto:digia....@qt-project.org>]
 on behalf of Blasche Alexander 
[alexander.blas...@digia.com<mailto:alexander.blas...@digia.com>]
Sent: Monday, March 10, 2014 10:01
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] Qt Bluetooth iOS

Hi,

Sorry to disappoint, but to the best of my knowledge there is no ongoing port 
for iOS at this point in time.


--

Alex


From: 
development-bounces+alexander.blasche=digia@qt-project.org<mailto:digia@qt-project.org>
 
[development-bounces+alexander.blasche=digia@qt-project.org<mailto:digia@qt-project.org>]
 on behalf of Pau Garcia i Quiles 
[pgqui...@elpauer.org<mailto:pgqui...@elpauer.org>]
Sent: Sunday, March 09, 2014 01:10
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: [Development] Qt Bluetooth iOS

Hello,

Is anyone working on an iOS backend of Qt Bluetooth? I could use it but I 
cannot find any information at all.

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

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




--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Bluetooth iOS

[Blasche Alexander]

Hi,

One more update on this topic. After some investigations yesterday it turns out 
that iOS doesn't actually have a classic Bluetooth API. There is a Bluetooth 
Low Energy API since iOS 6 but this would require the Bluetooth Low Energy 
(BtLE) feature first. While BtLE is currently in the works, there is no firm 
target release yet (ready when it's ready).

The only other Bluetooth related API I could find was related to the External 
Accessory Framework. An accessory may happen to be a Bluetooth device but 
that's not really the same.

Of course MacOSX and the windows flavours have some Bluetooth opportunities.


--

Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Blasche Alexander [alexander.blas...@digia.com]
Sent: Monday, March 10, 2014 10:01
To: development@qt-project.org
Subject: Re: [Development] Qt Bluetooth iOS

Hi,

Sorry to disappoint, but to the best of my knowledge there is no ongoing port 
for iOS at this point in time.


--

Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Pau Garcia i Quiles [pgqui...@elpauer.org]
Sent: Sunday, March 09, 2014 01:10
To: development@qt-project.org
Subject: [Development] Qt Bluetooth iOS

Hello,

Is anyone working on an iOS backend of Qt Bluetooth? I could use it but I 
cannot find any information at all.

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Bluetooth support for windows

[Blasche Alexander]

Hi,

Unfortunately the QtBluetooth module doesn't support Windows at this stage. The 
officially supported 5.3 platforms for this module are Linux/Bluez 4.x, QNX and 
Android.


--

Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
iMath [2281570...@qq.com]
Sent: Wednesday, March 12, 2014 16:46
To: development
Subject: [Development] Bluetooth support for  windows

will qt 5.3 has Bluetooth support for

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

Re: [Development] Qt Bluetooth iOS

[Blasche Alexander]

Hi,

Sorry to disappoint, but to the best of my knowledge there is no ongoing port 
for iOS at this point in time.


--

Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Pau Garcia i Quiles [pgqui...@elpauer.org]
Sent: Sunday, March 09, 2014 01:10
To: development@qt-project.org
Subject: [Development] Qt Bluetooth iOS

Hello,

Is anyone working on an iOS backend of Qt Bluetooth? I could use it but I 
cannot find any information at all.

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Ulf Hermann as approver

[Blasche Alexander]

+1
--
Alex


From: development-bounces+kai.koehne=digia@qt-project.org 
[development-bounces+kai.koehne=digia@qt-project.org] on behalf of Simon 
Hausmann [simon.hausm...@digia.com]
Sent: 04 March 2014 13:51
To: development@qt-project.org
Subject: [Development] Nominating Ulf Hermann as approver

Hi,

I'd like to nominate Ulf for approvership. He's been hacking on various bits
and pieces in the profiler support in Qml and he also implemented a brand new
profiler for the JavaScript engine.

I'm convinced that he would make a careful and responsible approver.

Patches:

https://codereview.qt-project.org/#q,owner:ulf.hermann%2540digia.com,n,z
(don't forget the "next" button ;)

And here's a list of him as a reviewer:

https://codereview.qt-project.org/#q,reviewer:ulf.hermann%2540digia.com,n,z



Any seconds? :)


Simon
___
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] Best practice for defining an integer constant

[Blasche Alexander]

Hi.

An enum has the advantage that you have a certain level of type safety and in 
my opinion it makes the API much more readable.

foo(int x)

is far less certain on what to pass then

foo(ErrorCode x)

I immediately see what the range of possible values is (based on the enum 
definition) while the int could be any arbitrary int constant you came along. 
QtCreator and its predictive input/tab completion will thank you for it.


--

Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Mandeep Sandhu [mandeepsandhu@gmail.com]
Sent: Friday, February 14, 2014 11:29
To: development@qt-project.org
Subject: [Development] Best practice for defining an integer constant

I have a need for defining an integer constant that'll be used for initializing 
a member variable of a private class.

The Qt coding conventions (http://qt-project.org/wiki/Coding-Conventions) 
recommend using an enum over 'const int'.

The rationale given there is that an enum will be replaced at compile-time 
resulting in 'faster code'. Won't that be the case with 'const int' as well? I 
think a 'const int' will be inlined in the code. CMIIW.

Also, there are a couple of instances in our current code where such (static 
and non-static) constants are used. Whats the recommended way?

Thanks,
-mandeep

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

Re: [Development] frozen tickets on bugreports.qt-project.org in qt-mobility and qt-components

[Blasche Alexander]

> -Original Message-
> From: development-bounces+alexander.blasche=digia@qt-project.org
> [mailto:development-bounces+alexander.blasche=digia@qt-project.org]
> On Behalf Of Alan Ezust

> Exactly my point. Why does someone need superpowers in order to edit these
> tickets?
> Shouldn't it be possible for developers to reorganize or close or add info to 
> these
> things?
> It doesn't serve any purpose to keep them open and frozen like this.
> 
> Anyway, I am requesting said superpowers so I can help organize and triage
> these tickets.
> But I think they should be granted to all devs :-)

I don't know why I didn't mention this yesterday, but QTCOMPONENTS and 
QTMOBILITY are frozen/read-only projects. You cannot edit them anymore. Nobody 
can.

It does serve a purpose. It reflects the exact state when those projects were 
abandoned and therefore are a point of reference. 

In addition I see little point in moving a bug from one project to the next as 
they are close to never applicable. If you do happen to find one then please 
file a new QTBUG task and link to the task in the closed project.

--
Alex

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

Re: [Development] How to write a ChangeLog entry

[Blasche Alexander]

--
Alex


> -Original Message-
> From: development-bounces+alexander.blasche=digia@qt-project.org
> [mailto:development-bounces+alexander.blasche=digia@qt-project.org]
> On Behalf Of Thiago Macieira
> Sent: Tuesday, 21 January 2014 17:58
> To: development@qt-project.org
> Subject: Re: [Development] How to write a ChangeLog entry
> 
> On terça-feira, 21 de janeiro de 2014 08:09:43, Blasche Alexander wrote:
> > Why are you pushing change log items for modules outside of qtbase to
> > qtbase?

> I'm editing everything in one file so it's easier for me, but I'll split them
> to each module after we're done.

Ok good to know for the next time.


> > >> QtBluetooth
> > >> ---
> > >>
> > >>  - Documentation:
> > >>* Fix cases where device and service discovery classes emitted an
> > >>error
> > >>
> > >>  signal but the human readable error string was not adjusted.
> > >
> > >How is this a documentation issue? If it's a minor documentation fix, it
> > >probably isn't relevant for the changelog.
> >
> > The release branch of the git repo for this module has had the relevant fix
> > for the above issue for some time.
> 
> You mean in the changes file?

It's the first time that I had to provide a changes file for my modules.  
Obviously I was a bit too ambitious ;)
but yes:

qt.gitorious.org/qt/qtconnectivity/blobs/release/dist/changes-5.2.1

--
Alex

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

Re: [Development] frozen tickets on bugreports.qt-project.org in qt-mobility and qt-components

[Blasche Alexander]

--
Alex


> -Original Message-
> From: development-bounces+alexander.blasche=digia@qt-project.org
> [mailto:development-bounces+alexander.blasche=digia@qt-project.org]
> On Behalf Of Alan Ezust
> Sent: Monday, 20 January 2014 23:33
> To: deDietrich Gabriel
> Cc: development@qt-project.org
> Subject: Re: [Development] frozen tickets on bugreports.qt-project.org in qt-
> mobility and qt-components
> 
> 
> In the case of https://bugreports.qt-project.org/browse/QTCOMPONENTS-930
> Qt-Components has a gallery example, as does Qt Quick Controls.
> I had just reported a related ticket against the gallery example of qt quick 
> controls,
> so i was going to add a comment "see related ticket:"
> Meego is still a "supported" platform, with Jolla and all, right?
> 
> On a related note, in the case of many open qt mobility/multimediakit bugs, 
> they
> should be moved to qtmultimedia. Perhaps a group search/replacement is in
> order there?

Please feel free to shift them to Qt5 as you see fit. However please check that 
they still apply before you move them.
For some of my former Mobility modules I shifted applicable issues but left 
other issues as open inside the Mobility project. After all there are 
occasional users of old Mobility API's and they might have a use of those bugs. 

I might mark the QtMobility project as deprecated in Jira.

> On Mon, Jan 20, 2014 at 12:43 PM, deDietrich Gabriel
>  wrote:

>   As the header says on that page, QTCOMPONENTS is deprecated. Those
> tickets relate to an old set of components from the Nokia times. We keep them
> around for reference (although I don’t think any of that code is in Qt 5), 
> and we
> should definitely close them (and by “we,” I mean anyone with the right
> superpowers).

I will close them tomorrow to give ppl time to reject today.

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

Re: [Development] How to write a ChangeLog entry

[Blasche Alexander]

> -Original Message-
> From: development-bounces+alexander.blasche=digia@qt-project.org
> [mailto:development-bounces+alexander.blasche=digia@qt-project.org]
> On Behalf Of Thiago Macieira

> Here's the edited changelog. Please re-read it. You can also find it here:
>   https://codereview.qt-project.org/76094
> 
> If you have updates, please reply to this email or leave a comment in the
> change above. I'll update the changelog file.

I hope I am not rehashing something old with this question but at least I am 
not aware of it.

Why are you pushing change log items for modules outside of qtbase to qtbase? 

http://qt-project.org/wiki/Change-files-in-Qt-5.2

clearly accumulates the various files from the various git repos.

>> QtBluetooth
>> ---
>> 
>>  - Documentation:
>>* Fix cases where device and service discovery classes emitted an error
>>  signal but the human readable error string was not adjusted.
>
>How is this a documentation issue? If it's a minor documentation fix, it 
>probably isn't relevant for the changelog.

The release branch of the git repo for this module has had the relevant fix for 
the above issue for some time.

If you want to put the change files for all modules into qtbase then I suggest 
you grab them from the relevant module. I cannot modify already committed 
changelog entries but I do maintain a sane changes file for the module. 
Nevertheless I maintain my believe that it's wrong to put them all into qtbase 
which would also raises the question why the modules still have them.

--
Alex

P.S. I do use you change log script as well but I tend to cut the irrelevant 
stuff out and then push to the module repo.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.3 Feature freeze is coming quite soon...

[Blasche Alexander]

--
Alex

> On Fri, Jan 17, 2014 at 10:49 AM, Pau Garcia i Quiles 
> wrote:
> 
> 
>   Hello,
> 
>   If it's currently a separate module, which compiles by itself and can be
> used by itself, why not adding it as an add-on?
> 
>   I have started to use Qt on mobile and while 200 more KB is nothing on
> desktop, on mobile, 200 KB here and 200 KB there is a lot on mobile.
> 
>   I think it's best if a pattern is created: the more functionality that 
> can be
> provided as add-ons, the better (which is in fact what KDE has been doing with
> the split of kdelibs in KF5: define the dependencies of search add-on, and 
> you are
> fine to use only this or that).

I agree with this statement. I fail to see a good reason why it must be joined. 
Sure there I is a spiritual one but is that really sufficient argument? We have 
to "burden" just about every Qt user with it. In my opinion it is common if you 
do something related to browser development but I can also think of plenty of 
apps which would never require it. Over time these things tend to add up as 
well (200k here and another 50k and viola you have a lib that's 0.5MB larger).
 
>   Yes, I know, I can use the QT_NO_WEBSOCKETS as Simon suggested but
> wouldn't it be easier if nobody has to care about that? Don't want websockets?
> Don't use the add-on. Or is there anything fundamental that will be gained by
> having QtWebsockets be part of QtNetwork and I have missed it?

Qt's past has shown that such defines have a very short lifetime as virtually 
nobody compiles the myriads of define combinations.

Apart from that we create two incompatible versions of the same library. This 
may work if you have obscure features which really only a minority of users 
requires but that cannot be said either in this case. 

If you have your own module you don't have to split the QML code out into a 
totally different git repo/module either. LBNL the code is already separate. 
You safe doing the merge and it proved that it doesn't require some deep hidden 
internals from QtNetwork .

--
Alex

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

Re: [Development] new Jira Network assignees

[Blasche Alexander]

> -Original Message-
> From: development-bounces+alexander.blasche=digia@qt-project.org
> To: development@qt-project.org
> Subject: Re: [Development] new Jira Network assignees
> 
> On sexta-feira, 10 de janeiro de 2014 11:31:47, Peter Hartmann wrote:
> > * Thiago is the default assignee for URL bugs, as QUrl is part of QtCore
> > (I guess it was like this already)
> 
> Either this should be renamed to Core: URL handling or to Network: Access
> Manager.

Renamed to Core: Url Handling

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

Re: [Development] Loading moc plugins when running tests in CI system

[Blasche Alexander]

Aaron is referring to "mock" plug-ins

http://en.wikipedia.org/wiki/Mock_object

--

Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Olivier Goffart [oliv...@woboq.com]
Sent: Tuesday, January 07, 2014 09:54
To: development@qt-project.org
Subject: Re: [Development] Loading moc plugins when running tests in CI system

On Tuesday 07 January 2014 14:12:22 Aaron McCarthy wrote:
> Hi,
>
> Qt Positioning and Qt Location use moc plugins in various test cases. These
> tests run fine locally with a developer build of Qt but fail when run in the
> CI system. From what it looks like this is because the moc plugins are not
> installed and cannot be loaded, see integration failure in [1].
>
> The moc plugins are built under the top-level tests project which is not
> installed by default. My question is what is the recommended approach to
> ensure that moc plugins are loadable when running tests in the CI system?
>
> [1] https://codereview.qt-project.org/73984


What do you mean by moc plugin?  moc does not have a plugin system (it is not
loading any plugin) AFAIK.

--
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.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] Multimedia maintainer

[Blasche Alexander]

+1

--
Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Knoll Lars [lars.kn...@digia.com]
Sent: Tuesday, December 17, 2013 10:24
To: development@qt-project.org
Subject: [Development] Multimedia maintainer

Hi,

the first maintainer I’d like to nominate is Yoann Lopes for multimedia.
Yoann has been taking care of multimedia for the last year, and done lots
of work on the different backends.

https://codereview.qt-project.org/#q,owner:yoann.lopes%2540digia.com,p,0028
cb2200011062

Cheers,
Lars

___
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] Nominating Nikolai Kosjar for Maintainer

[Blasche Alexander]

Hi,

Gerrit has been set and http://qt-project.org/wiki/Maintainers updated.

Nothing to do in Jira. 
--
Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Erik Verbruggen [erik.verbrug...@digia.com]
Sent: Thursday, December 12, 2013 10:11
To: development@qt-project.org; qt-crea...@qt-project.org
Subject: Re: [Development] Nominating Nikolai Kosjar for Maintainer

15 work days have passed, congrats Nikolai!

Could someone with more Jira/Gerrit powers than me do the necessary
changes to have this take effect?

-- Erik.

On 19-11-2013 14:37, Erik Verbruggen wrote:
> Hello everyone,
>
> I would like to nominate Nikolai Kosjar for Maintainer of the C/C++
> support in Qt Creator. He has been doing work on it for quite some time,
> and handling most maintainer tasks for most of this year. So I think we
> should make it official.
>
> Cheers,
> Erik.

___
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] Nominating Fabian Bumberger for Approver Status

[Blasche Alexander]

Hi,

It has been 15 days and Fabian received strong support. Congratulations to 
Fabian!

Jira and Gerrit have been updated.

--
Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Blasche Alexander [alexander.blas...@digia.com]
Sent: Tuesday, November 19, 2013 11:41
To: development@qt-project.org
Subject: [Development] Nominating Fabian Bumberger for Approver Status

Hello everybody,

I'd like to nominate Fabian Bumberger for approver status in the Qt Project.

Fabian has been contributing to QtNfc, QtBluetooth, QtLocation and many more 
Blackberry specific topics such as the platform plug-ins. His track record can 
be found under:

https://codereview.qt-project.org/#q,owner:fbumberger,n,z
https://codereview.qt-project.org/#q,reviewer:fbumberger,n,z

>From my perspective QtBluetooth and QtNfc wouldn't be the same without his 
>help.

I am convinced he will make en excellent approver.

With regards,
--
Alex
___
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] Nominating Gatis Paeglis as approver

[Blasche Alexander]

--

Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Sergio Ahumada [sergio.ahum...@digia.com]
Sent: Wednesday, November 20, 2013 15:29
To: development@qt-project.org
Subject: Re: [Development] Nominating Gatis Paeglis as approver

Done. Congratulations.

--
Alex


On 11/20/2013 03:29 PM, Frederik Gladhorn wrote:
> More than 15 days have passed, so I'm happy to welcome Gatis as approver :)
>
> Sergio, could you flip the switch?
>
>

Hi,

Added him to the Approvers group. Congratulations !

I guess Alex could fix the access rights in JIRA.

Cheers,
--
Sergio Ahumada
Release Engineer - Digia, 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] Nominating Fabian Bumberger for Approver Status

[Blasche Alexander]

Hello everybody,

I'd like to nominate Fabian Bumberger for approver status in the Qt Project.

Fabian has been contributing to QtNfc, QtBluetooth, QtLocation and many more 
Blackberry specific topics such as the platform plug-ins. His track record can 
be found under:

https://codereview.qt-project.org/#q,owner:fbumberger,n,z
https://codereview.qt-project.org/#q,reviewer:fbumberger,n,z

>From my perspective QtBluetooth and QtNfc wouldn't be the same without his 
>help.

I am convinced he will make en excellent approver.

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

Re: [Development] [Announce] Qt 5.2 Beta released

[Blasche Alexander]

It's exactly this bug. It's a regression from 5.1 and marked as P1 for the 
final release.

--
Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Mitch Curtis [mitch.cur...@digia.com]
Sent: Tuesday, October 29, 2013 14:49
To: Aleksey Sidorov; development@qt-project.org
Subject: Re: [Development] [Announce] Qt 5.2 Beta released

On 10/29/2013 02:41 PM, Aleksey Sidorov wrote:
> Hi all! In new v4 engine i found an strange bug. In arrays, which are 
> obtained from QList such as QStringList disappeared method indexOf.

Might be https://bugreports.qt-project.org/browse/QTBUG-33542
___
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] QtLocation offline Navigation support

[Blasche Alexander]

Hi,

In principle there is nothing that speaks against it and in particular for OSM 
I can easily see this to happen. However there are no concrete plans for a 
particular Qt version at this stage.

There are a few prerequisites for it though. For a start I'd like to have a 
QtLocation release and the Qt3D situation is somewhat unresolved as well. 
Before this hasn't happened I see little point in starting such a project.

--

Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Ramakanthreddy Kesireddy [ramakanthreddy.kesire...@techmahindra.com]
Sent: Friday, October 25, 2013 15:55
To: development@qt-project.org
Subject: [Development] QtLocation offline Navigation support


Hi,



Please let me know if there is a plan to enable support for offline Navigation 
and Map in QtLocation module.



Thanks and Regards,

Ramakanth



DISCLAIMER:
This email (including any attachments) is intended for the sole use of the 
intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE 
COMPANY INFORMATION. Any review or reliance by others or copying or 
distribution or forwarding of any or all of the contents in this message is 
STRICTLY PROHIBITED. If you are not the intended recipient, please contact the 
sender by email and delete all copies; your cooperation in this regard is 
appreciated.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development