Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Maurice Kalinowski via Development]

You are absolutely correct that this module started with a pure automotive 
focus, back then called Qt IVI.
However, we recognized that its functionality can also be utilized in a generic 
way, which was the reason for the rename and generalization efforts done in the 
past. There might still be some leftovers.

There are developers/customers using it in their production environment 
already, also outside of the automotive sector.

BR,
Maurice


From: Development  On Behalf Of Tor Arne 
Vestbø via Development
Sent: Thursday, 7 December 2023 18:37
To: Tuukka Turunen 
Cc: Macieira, Thiago ; development@qt-project.org
Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
Reference APIs

If it’s an option to rename this module we should take the opportunity to do so 
I think.

The problem of the generic naming came up in the past, but the understanding 
was that it was too late to change.

If that is not the case after all, we should strongly consider it.

The documentation at https://doc.qt.io/QtInterfaceFramework/ describes it as:

"The Qt Interface Framework module provides both the tools and the core APIs, 
for you to implement Middleware APIs, Middleware Back ends, and Middleware 
Services. “


So is this the Qt Middleware module?


On the other hand, the module seems to also provide a lot more than just core 
primitives. E.g. this set of classes for in-viechle infotainment systems:

https://doc.qt.io/QtInterfaceFramework/qtifmedia-module.html


So is this a Qt for Automotive specific module? These APIs seem to indicate 
that as well:

https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-vehiclefunctions-qmlmodule.html

If we do want to promote this to a Qt module, should the core functionality be 
split off, and the rest stay Qt for Automotive specific?

https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-module.html

Cheers,
Tor Arne


On 7 Dec 2023, at 17:02, Tuukka Turunen via Development 
mailto:development@qt-project.org>> wrote:

Hi,

Thiago is right, we can change the name as the module technically is not part 
of Qt release 
(https://download.qt.io/official_releases/qt/6.6/6.6.1/submodules/).

That said, we can also decide not to change the name. Like mentioned by 
Dominik, it has existing since a while with the current name 
(https://doc.qt.io/QtInterfaceFramework/) and repository 
(https://code.qt.io/cgit/qt/qtinterfaceframework.git/). Initially it had a 
different name, so the current one is already a new name, which is probably 
better than the initial at least.

So the question is what should this module be called, if it would be renamed? 
And another question, is it feasible to implement the renaming at this point?

Moving the proposed items out from it to labs modules makes sense to me. The 
naming of labs modules should then be aligned with the new naming of the module.

Yours,

Tuukka

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Thiago Macieira 
mailto:thiago.macie...@intel.com>>
Date: Tuesday, December 5, 2023 at 19:06
To: development@qt-project.org 
mailto:development@qt-project.org>>
Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
Reference APIs
On Tuesday, 5 December 2023 08:54:29 PST Thiago Macieira wrote:
> Then why are you asking for a repository if it's already there? When was
> that module approved by the Qt Project? I can't find anything in the email
> archives.
>
> The first commit in this repository is "First version of the QtGeniviExtras
> module". When was it renamed and who approved it?

This module was requested at
https://lists.qt-project.org/pipermail/development/2015-August/022859.html

There were no objections. Tuukka said it's a good idea to have the modules
even if they aren't part of the released packages:

> I think it is fine to create the requested repo for new module. Depending on
> the need it can then either be included or not be included in the release
> packages.

That would explain why this isn't in the qt5.git/.gitmodules.

But I said:

> I am, however, questioning the design of the API that Dominik presented.

There have been zero other discussions of "genivi" since then
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fsearch%3Fq%3Dgenivi%2Bsite%25253Ahttps%25253A%25252F%25252Flists.qt-project.org%25252Fpipermail%25252Fdevelopment%25252F=05%7C01%7Ctuukka.turunen%40qt.io%7Cc5d9d74e44014c5e22c308dbf5b48c59%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638373928019928582%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=r0fpIXCgLTyWGtC9bIJ9waV7QgvH6J%2FnwRLJ%2BZMPL9k%3D=0

I don't know what kind of API reviews have been done since. But there has been
no discussion about renaming this module. 

Re: [Development] Raising the minimum to C++20

[Maurice Kalinowski via Development]

 
> On 04.05.23 08:52, Maurice Kalinowski via Development wrote:
> [...]
> > This is the situation we experience in multiple industries still, with an
> increasing pressure from multiple angles to get those finally supporting Qt 6.
> Hence, things are getting better for C++17 _now_.
> [...]
> 
> This actually sounds like an argument for _earlier_ adoption. If Qt, as
> an important component in the ecosystem, slows the pace, then OEMs feel
> even less pressure to update their toolchains, making the problem worse
> for the industry at large.
> 
> The main problem I have with this line of reasoning is that I think it's
> the LTS's job to serve those customers that end up in these situations.
> So it's not like those customer's can't use Qt, they just can't use the
> latest features. But they can't, anyway, because they have such an old
> toolchain. I wonder how much of this is customer' requests and how much
> of it our desire to move customers off Qt 5?
> 
[Maurice Kalinowski] 
I don't agree that Qt is slowing it, we are one of the drivers to accelerate. 
As I said, there are multiple players in this context, Qt being one of them.
When we said that we are going to require C++17 for Qt 6, that caused a lot of 
concerns, as at the time of the announcement not all OS had support for it, the 
hardware vendors did not even start adding it, over players in this chain were 
unprepared as well. On the other end of the spectrum we had users, who wanted 
to use new functionality, but knew it is going to take time until they finally 
can.
Again, we as Qt have been pushing, but things move slowly.


> One way to skin this particular cat would be to keep non-core modules
> compatible with the last LTS to give users access to newer features in
> those modules without having to update tool-chains. Realistically, most
> of the bang we get from a C++20 requirement is in QtBase and, possibly,
> QtDeclarative. IIUC, we do this for some part of qtdeclarative and for
> qtwebengine already, and, while it's occasionally annoying, it lets us
> eat our own dog-food, too.
[Maurice Kalinowski] 
Compatibility of LTS to non-LTS, or how to do versioned released of individual 
modules is an orthogonal discussion. I think we should not mix those, even 
though I am a fan of that idea personally. But the release team (amongst 
others) would hate me for that :)


> 
> Speaking with the tongue of the Qt OSS project, I fail to see how all
> this isn't SEP. Users of such OEM boards have several ways to solve the
> problem:
> - pressure the OEM to support a six-year-old C++ standard
[Maurice Kalinowski] 
You might be mixing OEM with other players. OEMs (the people shipping devices 
in any shape or form) would love to use latest features as well. They get their 
BSPs from Tier1 who then get the base BSP from hardware/chipsetvendor who 
then...

> - pay someone (TQtC, KDAB) to build a newer toolchain on top of the old
> one, or do in-house
[Maurice Kalinowski] 
In non-regulated industries that is one option, yes. We also checked whether we 
could be shipping those in parallel. It works for prototyping and potentially 
development phase, but not for getting approval to ship your device.

> - vote with your feet and switch to an OEM that has a better customer
> service
[Maurice Kalinowski] 
Again, mixing terminology and unfortunately Qt is only one item in the whole 
decision process.


Maurice

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Raising the minimum to C++20

[Maurice Kalinowski via Development]

> 
> Can you provide more details on what the difficulties are and when relief 
> should
> be expected for this?
> 
> When you say "supply chain issues" for C++17, I am thinking that those
> customers are buying compilers in a DVD in a box and that is stuck in a
> container still sailing from China. That obviously can't be the case.
> 
[Maurice Kalinowski] 

I would not go that far, but in some industries you are somewhat in that 
situation.
When we prepared scoping for Qt 6, we were discussing with the OS vendors on 
the C++17 situation and when we can expect all RTOSes to have C++17 support. 
Most of them somewhat met their roadmaps and estimates.

However, there is the situation that OEMs rely on Tier1 suppliers and those 
Tier1s then provide the BSP including toolchain, OS version etc.
Unless those have an incentive to upgrade their toolchain, OS vendors can push 
updates as they want, those are stuck in between and do not reach device makers 
desks.

This is the situation we experience in multiple industries still, with an 
increasing pressure from multiple angles to get those finally supporting Qt 6. 
Hence, things are getting better for C++17 _now_.

To summarize, we learned to add a delta of at least 2-3 years between OS 
(especially RTOS) compiler and toolchain availability until those reach out to 
users and customers, who then start building Qt applications and devices on top.

BR,
Maurice


> My proposal was that C++20 wouldn't be required until March 2024 for non-LTS
> users. The first of your LTS to require it would be the one from October 2024,
> and it wouldn't become the oldest LTS until 3 years after 6.5 (March 2026).
> 

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Raising the minimum to C++20

[Maurice Kalinowski via Development]

As Marc already mentioned, we are having troubles with users not being able to 
upgrade on various platforms.

We even have customers who are not able to upgrade to C++17 yet due to supply 
chain issues.

Basically, the idea from our end has been to take a two-step approach by first 
enabling every developer to use C++20 in their projects and potentially add 
helpers/functionality where possible. Only at a later stage we can then start 
using it in Qt itself. Vladimir Minenko has all the details, as he has been 
laying out the rough plan with the foundation engineering.

This certainly is a good topic for a contributor summit, to which extend we 
want to establish fixed rules for those types of upgrades.

BR,
Maurice


> -Original Message-
> From: Development  On Behalf Of
> Marc Mutz via Development
> Sent: Wednesday, 3 May 2023 07:51
> To: development@qt-project.org
> Subject: Re: [Development] Raising the minimum to C++20
> 
> Hi Thiago,
> 
> While I'd rather sooner than later see us switch to C++20, ever since
> 5.7, we have dropped supported compilers only after an LTS release (5.6,
> in that case).
> 
> Since I agree the train for 6.6 has left the station, as Integrity (and
> possibly QNX?) don't have an official C++20 offering, yet
> (https://ghs.com/products/compiler.html, IIRC, they're going to release
> one this year, but I don't know what features they're shooting for), I
> was assuming that 6.9 would be the next option.
> 
> Personally, I would support a break after 6.8. That's scheduled for
> release in summer/autumn 2024, and has three years LTS, so gives
> affected customers until autumn 2027 to update their tool-chains. By
> that time, C++26 will be out already.
> 
> Even that, within TQtC, is seen as too early by some. After all, we
> still support 5.15 and therefore C++11, in 2023. That's only because
> 5.15 is a VLTS release, though. TQtC could decide to make 6.8 such a
> VLTS release, too, if sufficient numbers of customer won't be able to
> upgrade to C++20 by 2027.
> 
>  From a maintenance POV, it should be easier to support a C++17-based
> VLTS release than one that's still stuck on C++11 (and doesn't actually
> test for compatibility with that version in the CI...).
> 
> Thanks,
> Marc
> 
> On 03.05.23 02:39, Thiago Macieira wrote:
> > C++23 is on the way, so maybe it's time for us to raise our minimum to the
> one
> > version before that. Let's aim for Qt 6.7, because feature-freeze for 6.6 is
> > within one month, and lets us warn our users this is coming.
> >
> > By this, I mean to:
> > * modify our build system so Qt compiles with -std=c++20 or equivalent
> > * require that user code compiling Qt headers be similarly done
> > * remove the requirement for #if checks for C++17 Standard Library features
> > * make a couple of C++20 features mandatory (see below)
> >
> > Of the C++20 features I currently see a good reason to make mandatory:
> > * feature-test macros (no change: we're already using them)
> > * spaceship operator and  header
> > * char8_t
> > * std::is_constant_evaluated()
> > * constinit
> > *  header
> > * (maybe) designated initialisers
> > * (maybe) constexpr from  and 
> >
> > I'm not proposing modules, concepts or coroutines be allowed in our code
> just
> > yet. I think concepts will be the first of those, but we need to understand
> how
> > to use them first and how our code will change. I'd love to require
> std::format
> > and std::source_location, but those don't seem to be ready in the proposed
> > versions above.
> >
> > For this, I'd also like to request we raise our minimum compiler versions 
> > to:
> > * GCC 10 (released May 2020)
> > * Clang 10 (released March 2020)
> > * MSVC 2022 that is current today
> > * XCode that is current today
> >
> > Clang and GCC will be, at the time of Qt 6.7's release, just under 4 years
> > old. That should be enough to have been included in any long-term support
> > Linux distribution. Currently, both SLE 15.4 and RHEL/RockyLinux 9 have GCC
> > 13, while Ubuntu 22.04 and Debian 11 (current stable) have GCC 11. Debian
> will
> > probably release its next stable before Qt 6.7, though whether it'll still
> > upgrade from GCC 12 to 13 I don't know. When we released Qt 6.0, our
> minimum
> > of GCC 8 was of a lower age, at 2.5 years, so we could reasonably bump our
> > minimum GCC to 11 and still be 6 months more lenient. There are no new
> > features in GCC 11 that we could use without also requiring a more recent
> > Clang.
> >
> > Speaking of Clang, I simply chose a contemporaneous version and one that
> had a
> > similar feature list. FreeBSD 13-STABLE (13.2) comes with Clang 14, which is
> > much newer. We could raise the minimum if we wanted, but the intersection
> of
> > features with GCC 10 or 11 doesn't change much; we get std::bit_cast with
> > Clang/libc++ 14, but that's about it.
> >
> > This proposal also drops MSVC 2019 and assumes that users of 2022, like
> XCode,
> > keep their compilers reasonably 

Re: [Development] qt6 qml to c++ compilation

[Maurice Kalinowski]

Hi,


> Hi!
> 
> I installed qt6 to see what awaits now that Qt 5.15 always includes qml source
> code, even with quickcompiler https://bugreports.qt.io/browse/QTBUG-
> 88147
> 
> I created an example Qt6 application and tried with and without adding
> CONFIG += qtquickcompiler
> 
> The output of strings $binary includes the whole qml file like in Qt 5.15.
> My question is, Qt6 is supposed to compile this directly to c++ code.
> Will that still include the whole qml code?
[Maurice Kalinowski] 

You are right, that we are planning to have a QML to C++ conversion at the 
compile step within the Qt 6 cycle. However, it is not part of the initial 6.0 
release and will come at a later stage.

As of now, we have been focusing on creating the infrastructure for this as 
well as setting the guidelines to successfully handle this conversion in the 
future.

We'll certainly keep everyone updated on the progress of this project.


BR,
Maurice


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

Re: [Development] Feature freeze next Tuesday

[Maurice Kalinowski]

For better discussion, let's have a look at the existing patches:

> * QIM::multidata
https://codereview.qt-project.org/c/qt/qtbase/+/302905
Currently +2, waiting for integration

> * QKeyCombination + removal of operator+(QFlags, *)
https://codereview.qt-project.org/c/qt/qtbase/+/297566
Currently +1, TorArne commented it's ready for integration, misses +2 though.

> * (ideally) Qt::SingleShotConnection
https://codereview.qt-project.org/c/qt/qtbase/+/311098
Currently +1, with CI testrun failing

BR,
Maurice


> -Ursprüngliche Nachricht-
> Von: Development  Im Auftrag von
> Tuukka Turunen
> Gesendet: Dienstag, 1. September 2020 10:15
> An: Giuseppe D'Angelo ; development@qt-
> project.org
> Betreff: Re: [Development] Feature freeze next Tuesday
> 
> 
> Hi,
> 
> Do you have some estimate how long time is needed to get these in?
> 
> Also, do you foresee any issues these changes may cause to others?
> 
> Yours,
> 
>   Tuukka
> 
> On 1.9.2020, 11.01, "Development on behalf of Giuseppe D'Angelo via
> Development"  development@qt-project.org> wrote:
> 
> Il 26/08/20 08:46, Lars Knoll ha scritto:
> > I would hope that there are no other exceptions required. If something 
> is
> not done, but can easily be pushed to 6.1, you know what to do. If anybody
> knows about something else that can’t be pushed please talk to me, so we
> can figure out what to do about it.
> 
> I'd like to request an exception for a few patches of mine which have
> been around for a while now:
> 
> * QIM::multiData
> * QKeyCombination + removal of operator+(QFlags, *)
> * (ideally) Qt::SingleShotConnection
> 
> The first two have to go in 6.0.
> 
> Thanks,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software
> Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Untangling our platform plugins

[Maurice Kalinowski]

> >
> having a significant part of the plugin's implementation (if not most of
> it) linked into the parent library leads the concept of "plugin" ad absurdum.
> 
> >Or, in the case of platforms such as macOS where there’s only one
> >“platform”, the plugin is built directly into QtGui as a static plugin.
> >
> the logical consequence of the above would be statically linking the plugins
> on all platforms. or, for that matter, throwing out the pretense of plugins 
> and
> just make it a regular factory, to the degree it even makes sense at all.
> 
[Maurice Kalinowski] 
What about backends like WebGL, VNC etc.
It is rather beneficial to decide on runtime which backend to use compared to 
compile time decision. Especially given that you'd need two different builds 
then for just a "minimal aspect" of the build.

Maurice
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: more Jira states to track stages of the work on an issue

[Maurice Kalinowski]

Hi,

Just adding in another vote for introducing a “In Review/Integration” state.
As a disclaimer, I am working in the same team as Eddy.

The reason I see it beneficial is to have better visibility on the progress of 
working on a certain task. Eddy already made it clear that while something is 
“in review” or in the process of getting integrated or “waiting for other 
changes to merge”, there is no active work on this task happening. Defining 
that as “In Progress” is misleading.

Some people indicated that it feels like pressing a process into the workflow. 
I would like to highlight that this is absolutely not the case. Neither is this 
a PM decision or anything alike. It’s simply that recently we figured that with 
running sprints, the time spend on coding itself is only a fraction of time 
until a task gets resolved. We have had multiple (maybe even the majority) 
incidents of tasks running/sliding through multiple sprints, as we were not 
able to merge.
To repeat, the idea is to improve on the visibility of a state of a task.


Some might now say “Well, if integration (or CI) is the problem, then fix this 
rather than introduce another state”.
That’s a valid point. But only if there are evident indicators. Personally, I 
prefer to have metrics proving a point, and that might be one mean to achieve 
this. Heck, we might even get to a point that this is not needed anymore, as 
everything goes super smooth (ie 5 minutes from issue raised to integration 
done reference before). But first, I do not see this happening within the 
foreseeable future. Secondly, are we really that gridlocked to not change 
anything at all because it might be revisited at some point?


What I also miss in this thread is a suggestion on how this could be handled 
differently?
One idea which came up in discussions is to declare an issue as “blocked” while 
it is waiting for integration. But imho that does not make any sense either. 
First, because blocked is in the “Open” State, which indicates that no one is 
currently looking at it at all and the task is free to grab by anyone. 
Furthermore, “blocked” usually means other external factors to justify this 
state.

I’d also like to share the link to Atlassian’s workflow proposal on how to 
create an agile workflow in JIRA.
https://www.atlassian.com/agile/project-management/workflow

Note that this also includes two separate “active” states.

BR,
Maurice




> -Original Message-
> From: Development  On Behalf Of
> Edward Welbourne
> Sent: Thursday, February 20, 2020 2:37 PM
> To: Tobias Hunger 
> Cc: development@qt-project.org
> Subject: Re: [Development] Proposal: more Jira states to track stages of the
> work on an issue
> 
> On Mon, 2020-02-17 at 09:13 +, Edward Welbourne wrote:
> >> We currently have an "In Progress" state.  In practice when I work on
> >> an issue, I initially do the work, then put that up for review; the
> >> review phase takes up fragments of my time for a while, unlike the
> >> main work phase, which is closer to full-time.  I have more control
> >> over (and a better ability to estimate) how long the actual work
> >> takes, while review (and subsequent integration) depends on factors
> >> outside my control, that are harder to estimate.
> 
> Tobias Hunger (20 February 2020 10:00) replied:
> > If the review process does not ever result in a significant amount of
> > work (== no patch is ever rejected or significantly changed do to a
> > review process), then we should reevaluate the review process. If this
> > is indeed the case, then Gerrit has degenerated into a place to
> > discuss formatting -- something we could have clang-format take care
> > of automatically!
> >
> > If our review process is more than a formality then it might result in
> > a significant amount of work -- the patch can be rejected or you might
> > end up redoing significant parts of the code. In that case I do not
> > see how you can consider your original task done before the review is
> complete.
> >
> > In both cases, IMHO having a separate state in JIRA provides very
> > limited benefit.
> 
> I'm not suggesting or claiming either of those things, nor are they any part 
> of
> the case I'm making for having a separate state in Jira.
> 
> I'm better able to estimate how long I'll take to do the work before review
> than to estimate the time it'll take for that work to get through review; but,
> usually, the amount of *my* time that'll be taken up by the work during
> review is small compared to the amount of work I do before sending it for
> review.  So, when it comes to planning my work and communicating what I'm
> doing and when I expect it to be done, there is a vast difference between
> the work I do before review and the work I do in review.
> 
> * Before review: more or less full-time work, taking relatively
>   predictable large amounts of my time over a relatively predictable
>   calendar duration.
> 
> * In review: sporadic work, usually cumulatively smaller 

Re: [Development] Migrate QStateMachine from Qt Core

[Maurice Kalinowski]

Hi,

I think moving the implementations into one git repo would be a good move. In 
that case you could also move the qml state machine bindings from qtdeclarative 
(See src/imports folder).

I don’t think merging the implementations is a good idea, I find they serve 
different purposes. Just my two cents though:)
[Maurice Kalinowski]
Yup, we checked on this and also considered it to be… suboptimal to have one 
based on the other.
Maurice
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[Maurice Kalinowski]

> From: Development  On Behalf Of
> André Pönitz
> Sent: Wednesday, February 12, 2020 8:00 PM
> To: Allan Sandfeld Jensen 
> Cc: development@qt-project.org
> Subject: Re: [Development] The future of smart pointers in Qt API
> 
> On Wed, Feb 12, 2020 at 05:08:33PM +0100, Allan Sandfeld Jensen wrote:
> > > Allowing _both_ I have not seen actively endorsed by anyone, this
> > > only makes a messy incosnsistent API.
> >
> > I would allow both. It is the only way to remain source compatible,
> > while making it possible for those that wish to, to follow the
> > so-called Core guidelines for C++.
> 
> I'll rather have a uniform API than to have latest bells and whistles in some
> random places. 

I'd like to challenge the categorization of "latest bells and whistles" on 
something which is in the standard for 9 years now. Also considering that Qt 6 
is going to have at least the same lifetime as Qt 5, 8 years, this means that 
you propose to not adapt an item from the standard for 17 years?

What about new modules? There has been the proposal to at least enable them for 
those? Furthermore, we should not hinder/block external projects to adapting. 
As long as this is supported, that could be some middle-ground.

Maurice
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] QtCS2019 Notes: Qt for Python and beyond

[Maurice Kalinowski]

Hi,

Following the notes from the Qt for Python session

- Continuation of the plenary session
- Right now status is same as PyQt
- What can we do to make a difference and improve on QtfP
- Tooling
○ Around pyside and…
○ Make it easier to mix C++ and python
§ Currently a lot of black magic
§ Pyside2config etc…
- Using it from the outside it is too complicated
○ Xml descriptions unclear, even with documentation
○ Proposal: Create generators for type system
○ Going through widgets as an example
○ The code is the documentation right now
- What about editing the type-system, not only one-time generation?
○ Does it need to be a graphical solution?
○ Whatever it is, auto-completion is important/beneficial
○ Whatever happens, keeping C++ API and xml description in sync 
is troublesome and should be addressed
- Embed the export information into the cpp?
- Doesn't need to be xml, could be changed
- Adding annotations for all Qt classes is not what we want
○ Developers will not learn/use it, there needs to be automatism
- Proposal: Be not as verbose in the xml description
○ Use sane defaults and only annotate corrections
- What is the amount of changes needed
○ Ownership is a good example, needs to be read from the 
documentation and manually adapted in the xml
- We want to encourage users to start using Python extensions
- What about using the metaobject system for auto-exposing to Python?
○ Currently not the case
○ But what about adding items which can be introspected?
○ Basically re-use Q_PROPERTY, Q_INVOKABLE,…
- Tooling around python development?
○ Comparison to Rust: Cargo
○ Creates projects, manages compilation, deployment etc
○ Cookiecutter in python, which creates base templates
○ Idea: Add tools to create project templates
§ Potentially extract what Qt Creator does in the 
template
○ Have it create a folder structure including src/tests/….
○ What about creating a template for cookiecutter instead of 
writing a new tool?
○ Cookiecutter maintainer is in Berlin as well ,potentially meet
- Modules
○ Would there be any feedback on modules to add?
○ What about new pure python modules within the Qt context?
○ Example: Interaction with other python types, getting "python 
data" into QAbstractItemModel
○ Example: dataframes
○ Generally adaptors for existing python solutions
§ Does it have marketing reception impact? Qt moving 
"away" from C++?
○ Could be a separate solution, like Qt Lottie. Not part of the 
core product, but existent
○ Does this need to be associated with PySide?
§ If new modules are created which uses Qt/QtfP, why 
does it have to be in Pyside itself
§ And not standalone
○ Talking about the other way around
§ Qt Charts has its limitations
§ Use Qt / C++ for the heavy work and  Figure/Canvas 
from matplot to visualize
- Improvements to python itself
○ C++ components in Qt exposed to Python?
§ Generally a C++ module exposing a "pythonish" API 
using Qt to do the work
§ Integrate into PySide then
○ Why not improve Cpython?
§ It's open source after all
○ Getting sidetracked
§ Project based approach, if a project needs 
improvement let the project identify where to fix it
- Currently any python export requires manual shiboken compilation
○ We should improve here and make it easier
○ Idea: Some maintenance tool component which gets you latest 
shiboken and shiboken generator, etc…
§ Qt ships clang already, why not add the rest to the 
standard package?
○ Running out of time
- Deploying Python applications is a mess
- Python transpilers
○ Use-case: What about my python application which I need on a 
phone
○ Proposal: Wait for what others do and just use that
○ Beeware: Python VM in JS




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

[Development] QtCS19 Notes: Remote display of Qt applications in Qt 6

[Maurice Kalinowski]

Hi,

Following the notes taken on the remote display session:

- Qt5 has webgl and vnc
- Use-case duplicate displays
○ One local
○ One remote
- TQtC Hackathon project
○ Stream the scene graph to another machine
- Multi seat is problematic
○ Affect all current solutions
○ However, part of Wayland protocol
- Option: Being able to have multiple QPA backends at the same time
- use-cases
○ Remote mirror
○ Multiple displays
○ Virtual Keyboard and physical keyboard at the same time
○ …
○ Need to stay focused
- Current understanding is that this is not 6.0 content
○ WebGL etc might not be ready within timeframe
- "Multiplexing QPA" does help to shift any work beyond 6.0 and stay 
compatible with current API
- Again, multiple inputs should be handled via wayland
○ Moved details to be discussed to wayland session
- Proposal is to fix this based on specific project and not try to aim 
at an swiss army knife right from the beginning
- While it is not part of current 6.0 plans, we should try to get the 
basics available
○ Enable multiple inputs (keyboards, cursors, …)
- Where to draw a line?
○ Multiple cursors displayed?...
- Anything else but wayland?
○ X11 tried this, but never got around to have something to be 
used
○ Are there any other options? No one knows…
- Proposal Paul:
○ QPA API as a start
○ Then merges events to the application
- Action Points:
○ How and who drives multi seat?
○ Need to get started with a pilot project based on Wayland
○ Multiplex solution seems most viable
○ Get user story in JIRA



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

Re: [Development] Nominating Sona Kurazyan as approver

[Maurice Kalinowski]

+1

From: Development  On Behalf Of Ryan Chu
Sent: Friday, August 9, 2019 3:16 PM
To: development@qt-project.org
Subject: Re: [Development] Nominating Sona Kurazyan as approver

+1 from Ryan


Best regards,

Ryan


From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Shawn Rutledge mailto:shawn.rutle...@qt.io>>
Sent: Friday, August 9, 2019 2:51 PM
To: development@qt-project.org 
mailto:development@qt-project.org>>
Subject: Re: [Development] Nominating Sona Kurazyan as approver

+1

> On 9 Aug 2019, at 12:42, Alex Blasche 
> mailto:alexander.blas...@qt.io>> wrote:
>
> Hi all,
>
> I'd like to nominate Sona Kurazyan as approver for the Qt Project. Sona 
> ensured the release of QtCoap by bringing it to a releasable state and 
> lately, she has been all over Qt doing major cleanups related to deprecated 
> Qt APIs and Qt 6.
>
> Here is his list of contributions:
> https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io
> And reviews:
> https://codereview.qt-project.org/q/reviewer:sona.kurazyan%2540qt.io
>
> Cheers,
> --
> Alex
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] Qt wrapper for UPC UA Server stack (open62541)

[Maurice Kalinowski]

Hey Juan,

That certainly looks interesting. Are you aware of the Qt OpcUA module?
https://github.com/qt/qtopcua

Right now it focusses on the client side, but long term servers might become 
more important for us. Especially the gateway scenario of converting classic 
and proprietrary protocols to Opc/UA seems a regular use-case.

Anyways, the benefit of merging the efforts would be that a lot of classes can 
be shared among client and server and hence lead to easier dev experience.

BR,
Maurice

P.S.: I only had a quick glance at the code, Frank, Jannis and Rainer might 
have some more time to look into it.


From: Development  On Behalf Of Juan 
Gonzalez Burgos
Sent: Wednesday, April 10, 2019 5:10 PM
To: development@qt-project.org
Subject: [Development] Qt wrapper for UPC UA Server stack (open62541)

Hi guys,

This is pretty much WIP, but I would like some thoughts or even contributions.

https://github.com/juangburgos/QUaServer

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

Re: [Development] Qt Multimedia maintainer change

[Maurice Kalinowski]

+1
(same employer disclaimer)

Maurice


> -Original Message-
> From: Development  On Behalf Of
> Shawn Rutledge
> Sent: Thursday, February 7, 2019 3:10 PM
> To: development@qt-project.org
> Subject: Re: [Development] Qt Multimedia maintainer change
> 
> +1
> 
> > On 7 Feb 2019, at 14:23, Yoann Lopes  wrote:
> >
> > Hi,
> >
> > As most people have probably noticed, I haven’t been active on Qt
> Multimedia for quite some time now.
> >
> > Valentyn Doroshchuk should be the new maintainer, as he’s been the one
> putting most effort into the module for the past couple of years.
> >
> > --
> > Yoann
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Intention of dropping UWP 2015 x86 builds in favour of MinGW 32-bit packages

[Maurice Kalinowski]

The mail did not state 5.12.x. Hence it was under the assumption "as always" 
with the next minor release.

Maurice


> -Original Message-
> From: Jani Heikkinen
> Sent: Wednesday, February 6, 2019 12:54 PM
> To: Jesus Fernandez ; Maurice Kalinowski
> ; Simon Hausmann 
> Cc: development@qt-project.org
> Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in
> favour of MinGW 32-bit packages
> 
> Hi!
> 
> >>And I think we started providing binaries for a platform in 5.12.0 we cannot
> stop providing them in 5.12.x.
> I disagree. I agree we shouldn't do this kind of decisions without good
> reasons but I don't see anything why we couldn't do this kind of changes if
> there is good reasons. This is different issue than dropping support which we
> can't do in patch level releases...
> 
>  If we want to start delivering mingw32bit (which were dropped but it seems
> to be widely needed) then we need to drop something. It was proposed that
> UWP x86 msvc 2015 prebuild binaries are replaced with mingw32 ones. PM
> sent proposal to the ML and no-one disagreed. Then we did the decision to
> do the switch... One needing UWP x86 for MSVC2015 can still compile those
> by himself.
> 
> br,
> Jani
> ________
> From: Jesus Fernandez
> Sent: Wednesday, February 6, 2019 1:06 PM
> To: Jani Heikkinen; Maurice Kalinowski; Simon Hausmann
> Cc: development@qt-project.org
> Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in
> favour of MinGW 32-bit packages
> 
> > I think what Jesus refers to is patch level releases.
> 
> Yes, I was referring to patch releases.
> 
> And I think we started providing binaries for a platform in 5.12.0 we cannot
> stop providing them in 5.12.x.
> 
> 
> Best regards,
> 
> Jesús
> 
> 
> From: Jani Heikkinen
> Sent: 06 February 2019 11:02
> To: Maurice Kalinowski; Simon Hausmann; Jesus Fernandez
> Cc: development@qt-project.org
> Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in
> favour of MinGW 32-bit packages
> 
> Hi,
> 
> As Simon already wrote this is affecting only prebuilt binary packages we
> deliver and nothing else. It is true that we usually haven't touched (at least
> removed) those in patch level releases but I don't see any big issue with
> doing this now; UWP x86 msvc 2015 isn't that widely used and feedback from
> dropping mingw 32 bit is coming just from 5.12 series...
> 
> br,
> Jani
> 
> From: Development  on behalf of
> Maurice Kalinowski 
> Sent: Wednesday, February 6, 2019 11:32 AM
> To: Simon Hausmann; Jesus Fernandez
> Cc: development@qt-project.org
> Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in
> favour of MinGW 32-bit packages
> 
> I think what Jesus refers to is patch level releases.
> We've been changing binary packages for platforms within minor releases so
> far, but not for patch level ones.
> 
> Maurice
> 
> 
> From: Development  On Behalf Of
> Simon Hausmann
> Sent: Wednesday, February 6, 2019 9:19 AM
> To: Jesus Fernandez 
> Cc: development@qt-project.org
> Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in
> favour of MinGW 32-bit packages
> 
> Afaik this merely affects the binaries provided in the installer. It does not
> result in any changes in the git repos.
> Simon
> 
> On 5. Feb 2019, at 16:03, Jesus Fernandez
> mailto:jesus.fernan...@qt.io>> wrote:
> Can we remove a platform in a minor version?
> 
> 
> 
> Best regards,
> Jesús
> 
> 
>  Original message 
> From: Harald Kjølberg
> mailto:harald.kjolb...@qt.io>>
> Date: 05/02/2019 15:56 (GMT+01:00)
> To: development@qt-project.org<mailto:development@qt-project.org>
> Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in
> favour of MinGW 32-bit packages
> 
> 
> Hi,
> 
> As no objections have been received, the proposed change will be
> implemented, effective from Qt 5.12.2.
> 
> 
> Cheers,
> Harald
> 
> From: Development  project.org<mailto:development-boun...@qt-project.org>> on behalf of
> Harald Kjølberg mailto:harald.kjolb...@qt.io>>
> Date: Tuesday, 22 January 2019 at 14:36
> To: "development@qt-project.org<mailto:development@qt-project.org>"
> mailto:development@qt-project.org>>
> Subject: [Development] Intention of dropping UWP 2015 x86 builds in favour
> of MinGW 32-bit packages
> 
> 
> Hi,
> 
> In order to improve transparency and visibility (after getting some
> constructive and we

Re: [Development] Intention of dropping UWP 2015 x86 builds in favour of MinGW 32-bit packages

[Maurice Kalinowski]

I think what Jesus refers to is patch level releases.
We’ve been changing binary packages for platforms within minor releases so far, 
but not for patch level ones.

Maurice


From: Development  On Behalf Of Simon 
Hausmann
Sent: Wednesday, February 6, 2019 9:19 AM
To: Jesus Fernandez 
Cc: development@qt-project.org
Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in favour 
of MinGW 32-bit packages

Afaik this merely affects the binaries provided in the installer. It does not 
result in any changes in the git repos.
Simon

On 5. Feb 2019, at 16:03, Jesus Fernandez 
mailto:jesus.fernan...@qt.io>> wrote:
Can we remove a platform in a minor version?



Best regards,
Jesús


 Original message 
From: Harald Kjølberg mailto:harald.kjolb...@qt.io>>
Date: 05/02/2019 15:56 (GMT+01:00)
To: development@qt-project.org
Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in favour 
of MinGW 32-bit packages


Hi,

As no objections have been received, the proposed change will be implemented, 
effective from Qt 5.12.2.


Cheers,
Harald

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Harald Kjølberg 
mailto:harald.kjolb...@qt.io>>
Date: Tuesday, 22 January 2019 at 14:36
To: "development@qt-project.org" 
mailto:development@qt-project.org>>
Subject: [Development] Intention of dropping UWP 2015 x86 builds in favour of 
MinGW 32-bit packages


Hi,

In order to improve transparency and visibility (after getting some 
constructive and well deserved criticism):

We have received a proposal of dropping UWP 2015 x86 builds in favour of MinGW 
32-bit packages. We looked at this today and agreed that this can be done, and 
it should be our intention to do so. We will make the final decision February 
5th, and it will remain as described unless we get a lot of feedback saying 
that we should do otherwise.

For further details: https://bugreports.qt.io/browse/QTBUG-73019



Regards,
Harald Kjølberg

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

Re: [Development] Qt 5.13 feature freeze is getting closer

[Maurice Kalinowski]

Well even for TP there should be some consensus on whether it should be part of 
Qt or not, no?

We are lacking documentation on the process here, all I could find was 
https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt#Graduating_from_the_Playground.

“This decision is done on the qt-development mailing list, based on the 
technical and spirit fit to Qt, and it requires the approval of the Chief 
Maintainer.”

To my knowledge this has not happened at all. There was only a repository 
request so far, none for integrating it into the product line.

That is beside all the concerns about the quality of the code and missing 
actions to fix these.

Maurice


From: Development  On Behalf Of Lars Knoll
Sent: Wednesday, January 16, 2019 8:56 PM
To: Thiago Macieira 
Cc: Qt development mailing list 
Subject: Re: [Development] Qt 5.13 feature freeze is getting closer

On 16 Jan 2019, at 19:54, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

On Wednesday, 16 January 2019 09:44:40 PST Aleksey Kontsevich wrote:

In Nov, there was long discussion in review:
https://codereview.qt-project.org/#/c/240347/ Request was initially for
both: plugin and library - latter was transformed to Qt module.

Given that this is a complete surprise, I don't think we can find enough time
to do a review of it as a module in time for 5.13.

As far as I understood it the request was for a TP status, not a fully 
supported module.


In particular, I want to
take a look to see how it can integrate with a project my team is working on:
 https://clearlinux.org/documentation/clear-linux/concepts/telemetry-about

Why should that project influence a telemetry module for Qt?


So I think that for 5.13, the module can be at no higher state than
experimental. That will allow getting API reviews and testing by others.

See above, I don’t think anything else was being asked for.

Cheers,
Lars

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

[Development] Nominating Jannis Völker for Approver

[Maurice Kalinowski]

Hi,

I would like to nominate Jannis Völker for approvership. He has been an active 
contributor to Qt OpcUA mostly since end of 2017. He also has been actively 
taking care on JIRA, bug fixing and bringing the whole module forward.

If you're curious, here is a list of his changes:

https://codereview.qt-project.org/#/q/owner:%22Jannis+V%25C3%25B6lker%22,n,z

Reviews:
https://codereview.qt-project.org/#/q/reviewer:%22Jannis+V%25C3%25B6lker%22,n,z

BR,
Maurice


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

Re: [Development] qt open62541 client connection signals doesn't receive from backend class

[Maurice Kalinowski]

Hi,

Are you sure that the backend is loaded properly? Check 
QOpcUaProvider::availableBackends() and/or whether the client creation causes 
any issues.
Furthermore, I assume you have been using the documentation from Open62541 
itself? The default build generates a shared library, which needs to be in your 
PATH to be found on runtime.

As a final comment, your question is rather on using Qt / QtOpcUa, while this 
list is intended for developing on Qt itself. Hence, let’s move any followup 
discussion to inter...@qt-project.org where 
user problems are tackled.

BR,
Maurice


From: Development  
On Behalf Of Berna Sanchez
Sent: Sunday, September 2, 2018 7:03 PM
To: development@qt-project.org
Subject: [Development] qt open62541 client connection signals doesn't receive 
from backend class

Hello,
I'm on a stuck with a problem and some help will be appreciated it.
I've installed open62541 following this tutorial (Building On Windows – 
Mingw32) and seems like everything are ok, but when I try to connect my own 
client with a demo opcua server the QOpcUaClient::ClientState(Connecting) is 
always connecting state (no matter if server is running or not).

Debugging I can see:

-qopen62541backend.cpp:
Open62541AsyncBackend::connectToEndpoint(const QUrl ) is emitting signals 
correctly (connected when server is running or disconnected when not) so far I 
think it's ok.

On other hand, qopcuaclientprivate.cpp:
void pcUaClientPrivate::setStateAndError(QOpcUaClient::ClientState state, 
QOpcUaClient::ClientError error) seems like should receive the signals from 
backend class but it doesn't work, so client state still on connecting.

I also tried with other compiler (“Qt 5.11.1 64-bit for Desktop (MSVC 2017)”) 
and still happen the same.

I'm looking forward for your feedback. Thanks in advance.
Regards.
Berna.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Support for Windows Arm64 Desktop Target

[Maurice Kalinowski]

Hi Thomas,

Thanks for looking into this. In case your patches are ready, we’d be eager to 
review them following our guidelines at
https://wiki.qt.io/Qt_Contribution_Guidelines
https://wiki.qt.io/Setting_up_Gerrit

Talking about installers, that might be more complicated. For Windows we 
provide a huge amount of platforms already and simply put, it depends on the 
usage share of a platform to be part of the installer. For instance there has 
been discussions on when we can remove MSVC2015 versions to have both x86 and 
x64 versions in the installer.

However, not being available in the installer does not have an impact on the 
level of support by Qt.

BR,
Maurice


From: Development 
[mailto:development-bounces+maurice.kalinowski=qt...@qt-project.org] On Behalf 
Of Thomas Miller
Sent: Friday, July 20, 2018 2:02 AM
To: development@qt-project.org
Subject: [Development] Support for Windows Arm64 Desktop Target


Hi,

I’m a dev at Microsoft and recently I’ve been experimenting with building a Qt 
distribution that targets Arm64 Windows Desktop.

I wanted to know if changes to the Qt codebase to support an arm64 Windows 
desktop app would be accepted into the project and if so, what it would take to 
add this distribution as an option to the Qt installer?

I’ve had some success modifying the 5.10.1 codebase to build a distribution 
that targets arm64 apps and I was able to build the notepad example on my amd64 
dev machine and run it on one of my arm64 devices.

Basically, I started with this patch: 
https://gist.github.com/tycho/3ce679850a03a39d8c174ac05af56214 and then 
modified the msvc makefile generator so that I could target arm64 desktop cross 
platform. Like the arm winrt configuration but targeting arm64 desktop instead 
of arm Windows store.

I also modified windeployqt.exe to look at the architecture of the specified 
binaries instead of just the address width, so we don’t package amd64 dlls 
alongside arm64 executables.

I ported these changes (which I’m sure will require some iterations) to the dev 
branch and am currently building them. The diff for that is here: 
https://gist.github.com/thomaslmiller/b97bc7c7905f6e5fdfb93ee71e2a2fc5 in case 
anyone wants to look at it.

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

Re: [Development] How to run QtBase autotests on a remote machine?

[Maurice Kalinowski]

Hi,
>  >> Currently I build the tests and then scp individual tst_foo binaries  >> 
> to the
> host and run them manually. In order to fix the initial porting  >> problems 
> that
> will show up in most tests this is fine.
>  >
>  > Some tests shall need more than the binary; e.g. data files to act on.
> 
[Kalinowski Maurice] 
Check for testdata or builtin_testdata, I do not recall the precise name right 
now.

Basically you can specify whether you want the data to be copied or use qrc to 
integrate it to the app. The test system then automatically extracts it on the 
target hardware during execution and uses it.

>  >
> 
> When it comes to CI, tests don't seem to be run on Android and iOS targets.
> There are two cross-compilation targets (Linux arm64 and armv7) that are
> tested, but those are under QEMU emulation, not on real hardware.
[Kalinowski Maurice] 
Correct,

Oliver is currently working on getting UWP into it, it shares a lot of concepts 
with other remote targets. So when we started on it there were a couple of 
infrastructural things to clarify (like builtin_testdata from above).
>From what I know the other platforms might come at a later point, but should 
>be easier to do, as the technical building blocks are available.

Maurice 

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

[Development] Proposing Oliver Wolff as platform maintainer for UWP

[Maurice Kalinowski]

Hi,

As some might have recognized my focus inside the Qt Company has shifted from 
WinRT/UWP towards our Automation related offering. While I still review many 
patches for this platform, my effort in terms of active development have 
significantly reduced.

Consequently, I would like to propose Oliver Wolff to take over the role as 
platform maintainer. Oliver has been part of the team for years and (besides 
lots of other things) has been taking care of the networking parts. In addition 
to that, he has been "shadow-maintaining" the port over the last year, so this 
would rather reflect reality.
 
https://codereview.qt-project.org/#/q/owner:%22Oliver+Wolff+%253Coliver.wolff%2540qt.io%253E%22,n,z

BR,
Maurice

P.S.: Perhaps he manages to get sufficient agreement to be mentioned on the 
maintainer list, contrary to me when I took it over from Andrew :)

--
Maurice Kalinowski
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
maurice.kalinow...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator

[Maurice Kalinowski]

“The idea is to develop a generic library/plugin, which anyone could use for 
analytics”

If that is the case, then qt-creator/telemetry is the wrong repository to ask 
for. If you are aiming at something generic, then it should be qt/

Maurice

Von: Qt-creator 
[mailto:qt-creator-bounces+maurice.kalinowski=qt...@qt-project.org] Im Auftrag 
von Tino Pyssysalo
Gesendet: Thursday, February 22, 2018 2:59 PM
An: Simon Hausmann ; Tuukka Turunen 
; qt-crea...@qt-project.org; development@qt-project.org
Betreff: Re: [Qt-creator] [Development] Requesting repository for telemetry 
plugin in Qt Creator

Hi,

The idea is to develop a generic library/plugin, which anyone could use for 
analytics. The backend can be any storage and The Qt Company does not provide 
that.

We plan to use the same backend, which we already use in online installers to 
collect statistics about installations. At least in case of Qt Creator, the 
plan is to make some analysis results available for the community. Obviously, 
we do not do that for our commercial tooling.

Analytics is opt-in and disabled by default in Qt Creator. We plan to ask user 
in the installer, if the user wish to participate in Qt UX improvement. If the 
answers is no, the analytics plugin is never installed.  When the creator is 
started for the first time, it will show a dialog, consisting a list of 
collected data items and an option to enable/disable the plugin. There will be 
a new output pane, which shows collected data, conversions methods, if any 
used, and transmitted data to the user.
--
Tino


On 22/02/2018, 15.26, "Simon Hausmann" 
> wrote:


Hi,



Can you provide a bit more information about how this plugin / frontend fits 
into the Qt project? Where is the collected data sent to and how is it 
accessible to the community?



(-1 from me, as I think this needs to be clarified)



Simon


From: Development 
>
 on behalf of Tuukka Turunen >
Sent: Thursday, February 22, 2018 2:14:14 PM
To: Tino Pyssysalo; 
qt-crea...@qt-project.org; 
development@qt-project.org
Subject: Re: [Development] [Qt-creator] Requesting repository for telemetry 
plugin in Qt Creator




Hi,



+1 for creating the repo, but what about qt/qtanalytics as a name? This item 
could be useful also for other applications.



Yours,



 Tuukka



From: Qt-creator 
>
 on behalf of Tino Pyssysalo >
Date: Thursday, 22 February 2018 at 13.04
To: "qt-crea...@qt-project.org" 
>
Subject: [Qt-creator] Requesting repository for telemetry plugin in Qt Creator



Description:



Telemetry plugin (frontend) to collect usage data from Qt Creator to help 
improving Qt, Qt features, and Qt tools.

Non-personal data items, such as duration the user spent in design mode, will 
be collected in a way, which is completely transparent to the user.



Responsible: Tino Pyssysalo



Repository: qt-creator/plugin-telemetry





---

Tino Pyssysalo

Senior Manager



The Qt Company

Hämeenkatu 14 C 25

33100 Tampere, Finland

tino.pyssys...@qt.io

+358 40 8615475

http://qt.io



The future is Written with Qt

---




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

Re: [Development] Prebuilt 32-bit versjon for MSVC 2017

[Maurice Kalinowski]

The reason we have had x86 and x64 packages for UWP is not to target those two 
architectures for the desktop, but rather that the x86 version also works for 
the emulators for Windows Phone 8 / Windows 10 Mobile as well as Windows 10 IoT 
(Core).

Given that two out of those are basically gone by now, I'd be fine with 
dropping UWP x86 packages, but keep the arm packages for out embedded user base 
on Windows 10 IoT.

BR,
Maurice 

> -Ursprüngliche Nachricht-
> Von: Development [mailto:development-
> bounces+maurice.kalinowski=qt...@qt-project.org] Im Auftrag von Henry
> Skoglund
> Gesendet: Wednesday, February 21, 2018 2:16 PM
> An: development@qt-project.org
> Betreff: Re: [Development] Prebuilt 32-bit versjon for MSVC 2017
> 
> Hi,
> if I want to download prebuilt Qt binaries for the UWP platform then I can
> choose between 32-bit and 64-bit flavors of both MSVC 2015 and MSVC 2017.
> 
> It should be possible to offer the same variety for the Win32 versions,
> especially since I think the # of downloads for the Win32 Qt versions exceed
> the # of downloads for the UWP platform (for example, UWP requires
> Windows 10, but Win32 versions also work on Windows 7 and 8).
> 
> Rgrds Henry
> 
> 
> On 2018-02-21 14:04, NIkolai Marchenko wrote:
> > This dedication to dropping MSVC2015x32 seems quite stange after the
> > whole controversy of dropping MSVC2013 and how many people prefered to
> > tread very carefully and slowly.
> >
> > Unlike msvc 2013, 15th compiler is way better and doesn't restrain Qt
> > codebase nearly as much
> >
> > On Wed, Feb 21, 2018 at 3:44 PM, Harald Kjølberg
> > > wrote:
> >
> >
> > Hi,
> >
> > Currently Qt ships with 32-bit binaries for MSVC 2015, but not for
> > MSVC 2017. The Qt Company have received requests for adding prebuilt
> > 32-bit binaries also for MSVC 2017. By adding more prebuilt
> > binaries, we increase the complexity, and add to the overall
> > maintenance of our QA system. Our preferred approach would be to add
> > binaries for MSVC 2017 and remove the binaries for MSVC 2015, as the
> > numbers of binaries in the build remains the same. It will still be
> > possible to manually build Qt for MSVC 2015, in the same way as it
> > is possible to manually build for MSVC 2017 today. Feedback and
> > viewpoints are much appreciated and will enable us to make the best
> > possible decision.
> >
> >
> >
> >
> > Best regards,
> > Harald Kjølberg
> > Product Manager - Qt for Application 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 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] QtCoap: QNAM-like API or not

[Maurice Kalinowski]

> > They model their Coap client after QNAM and related classes (like
> > QNetworkRequest/Reply pair).
> >
> > As I understand it now - DTLS or not does not affect this API much -
> > they can later
> 
> You don't know that. Until we know how DTLS will work, we won't know if
> there's any impact in the front-end API for CoAP. For example, can you use
> one CoAP server for both encrypted and not encrypted? Multicast and
> unicast?
> 
> What's more, we CANNOT release a full CoAP API until it implements DTLS.
> It's just not acceptable to do so otherwise. Therefore, until there's DTLS, 
> the
> API is Technology Preview and subject to change. So I don't feel we need to
> review it yet. I have not spent any time myself.
> 
[Maurice Kalinowski] 

I guess having it as Technology Preview for a first release is the usual way to 
go anyways. That way, the API could still be changed afterwards, but also 
interested parties could get a first impression and suggest adoptions already, 
even though DTLS is not available yet.

Personally, I do not see those two items (missing DTLS, release TP) 
conflicting. The only "problem" which might exist, if DTLS takes too long to 
implement and CoAP would stay for a very long time in TP mode.

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

Re: [Development] Nominating Lorenz Haas for approver

[Maurice Kalinowski]

+1

Maurice

> -Original Message-
> From: Development [mailto:development-
> bounces+maurice.kalinowski=qt...@qt-project.org] On Behalf Of André
> Hartmann
> Sent: Sunday, November 5, 2017 6:01 PM
> To: qt-crea...@qt-project.org; development@qt-project.org
> Cc: Lorenz Haas 
> Subject: [Development] Nominating Lorenz Haas for approver
> 
> Hello all,
> 
> I'd like to nominate Lorenz Haas for approver status.
> 
> Lorenz has been contributing to Qt and Qt Creator since spring 2013. He has
> provided some high quality patches to Creators C++ Editor and is the author
> of Creators Beautifier plugin.
> 
> He is actively reviewing patches in these areas, and recently started
> contributing to and reviewing others patches for Qt OPC UA and MQTT also.
> 
> These are his own contributions:
> https://codereview.qt-project.org/#/q/owner:%22Lorenz+Haas%22,n,z
> 
> and these are his reviews:
> https://codereview.qt-project.org/#/q/reviewer:%22Lorenz+Haas%22,n,z
> 
> Best regards,
> André
> ___
> 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] Repository request: Qt KNX and Qt KMQTT

[Maurice Kalinowski]

Hi everyone,

Some of you might have heard about the Qt Company's Industry Automation 
specific work. If not, check this blog post as a starting reference at: 
http://blog.qt.io/blog/2017/08/14/qt-for-automation/

We would like to have two new repositories created to share the code publicly.

Name of the project: Qt KNX
Responsible person: Karsten Heimrich
Gerrit user/email: karsten.heimr...@qt.io
Desired repository name: qtknx


Name of the project: Qt MQTT
Responsible person: Maurice Kalinowski
Gerrit user/email: maurice.kalinow...@qt.io
Desired repository name: qtmqtt

Best Regards,
Maurice


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

Re: [Development] Adding Qt CoAP

[Maurice Kalinowski]

> >
> what are you talking about? https://codereview.qt-project.org/201311 is up for
> more than a month already.
[Kalinowski Maurice] 
And it is visible now after Frederik moved it. As I wrote in my initial mail, 
there has been some work done before...

Maurice


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

Re: [Development] Adding Qt CoAP

[Maurice Kalinowski]

Hey,

> > One of the items mentioned has been CoAP and that it would make a
> > great addition to Qt. Interestingly, there has been discussions
> > between the Qt Company and Witekio about exactly this topic. Thanks to
> > the people at Witekio these resulted in actual code already available
> > to get reviewed. To avoid any duplicate effort and have everyone
> > participating as early as possible a new repository is needed.
> 
> Hi Maurice
> 
> That's great. As you may have seen from my emails, I am a great supporter of
> CoAP and I'm really pleased that The Qt Company and others also think it's
> worth having in Qt.
> 
[Kalinowski Maurice] 
Absolutely, also thank you for opening the discussion on the mailing list. It 
has been a great enabler for this.


> > Name of the project: Qt CoAP
> >
> > Responsible person:
> > Cedric Amarger
> > Gerrit user/email: Cedric Amarger  Desired
> > repository name: qtcoap
> >
> > For now, I will leave any technical detail to Cedric.
> 
> I don't think we can discuss the format of such an implementation until we
> have DTLS support. For one thing, it isn't clear to me that we'll have a
> QDtlsSocket class in the first place, or whether it'll be a simple non- 
> QIODevice
> wrapper on top of QUdpSocket.
> 
[Kalinowski Maurice] 
Sure, which is also why the idea is to have it in a separate repository for 
now. Initially there was the consideration to put this into Qt Network and if 
so, in what fashion. This could still happen, but let's get this thing rolling 
and then discuss where to place it.


> I'm also wondering if we shouldn't have a bigger repo for IoT-related things,
> instead of creating a small one for each thing. Does it make sense to start
> thinking of "qtiot" ? Then we could merge qtopcua in it and could also add
> MQTT, DDS, DPS support and others.
> 

 [Kalinowski Maurice] 
Interestingly I had a similar discussion today whether it makes sense to have 
such a "super" repo as in connectivity having NFC and Bluetooth. However, 
connectivity is also a good example that this has not been a good idea. While 
many are interested in Bluetooth, a minority actually requires NFC. In the IoT 
sector that is even more fragmented, not even starting to think about what we 
see as "(Industry) Automation". Just as an example, while you have a bigger 
user group for DDS from your employer's perspective, clearly MQTT is the big 
item for the Qt Company's customers, based on the discussions I have been 
involved in.

Hence, I'd rather object for having one repository for all. Then again, we 
could also think about a IoT repository with just submodules, meaning if you're 
interested in the whole package, you just clone that. But that also depends on 
the product design of what has been announced as Qt for Automation being an 
AddOn to Qt.

While there is a session for OPC/UA already marked for Qt CS, this is certainly 
a good place to discuss the bigger plan with all parties involved.

Maurice

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

[Development] Adding Qt CoAP

[Maurice Kalinowski]

Hi everyone,

Most of you might have noticed the IoT related discussion happening on this 
mailing list. If not, check here in the archive: 
http://lists.qt-project.org/pipermail/development/2017-August/030723.html

One of the items mentioned has been CoAP and that it would make a great 
addition to Qt. Interestingly, there has been discussions between the Qt 
Company and Witekio about exactly this topic. Thanks to the people at Witekio 
these resulted in actual code already available to get reviewed. To avoid any 
duplicate effort and have everyone participating as early as possible a new 
repository is needed.

Name of the project: Qt CoAP

Responsible person:
Cedric Amarger
Gerrit user/email: Cedric Amarger 
Desired repository name: qtcoap

For now, I will leave any technical detail to Cedric.

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

Re: [Development] Examples and Demos in qtdoc

[Maurice Kalinowski]

So, is this in place now? Just wondering because of some changes getting into 
the qtdoc repo recently…

Maurice


From: Development 
[mailto:development-bounces+maurice.kalinowski=qt...@qt-project.org] On Behalf 
Of Lars Knoll
Sent: Friday, June 16, 2017 11:31 AM
To: Mitch Curtis 
Cc: Qt development mailing list 
Subject: Re: [Development] Examples and Demos in qtdoc


On 15 Jun 2017, at 15:23, Mitch Curtis 
> wrote:

-Original Message-
From: Development 
[mailto:development-bounces+mitch.curtis=qt.io@qt-
project.org] On Behalf Of Joerg Bornemann
Sent: Thursday, 15 June 2017 9:54 AM
To: Pasi Keränen >; 
development@qt-project.org
Subject: Re: [Development] Examples and Demos in qtdoc

On 14/06/2017 14:59, Pasi Keränen wrote:


I’m not 100% sure about qtdoc as the repo though. But I can live with it if
that is what is seen as best option by others.

There are two kinds of examples:
  1. Simple examples demonstrating the use of a certain technique.
 Those usually come with detailed source code documentation.
  2. Complex examples demonstrating much of the bling that's possible.
 Those are not source-documented, because writing the docs would be
 too laborious, and who would want to read them anyway.

I believe that examples of category 1 should live in the qdoc repository / in
their respective module repository. Examples of category 2 deserve a
separate space.

The "bigger examples" from Frederik's original mail are category 2. In
Qt4 those were called "demos". There could be a "qtdemos" repo with git-
lfs.

In qtwebengine there's this question bobbing up every once in a while what
to do with the demobrowser example. As an example, it actually needs
source documentation. But it's too big. There are voices that want to remove
it. Instead it could live on in such a qtdemos repo.

+1

That sounds like a good idea.

So documented examples in qtdoc, larger demos (that can also contain lots of 
image data) in a separate qtdemos repo.

Cheers,
Lars

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

Re: [Development] Proposal to adjust release candidate process

[Maurice Kalinowski]

Releasing beta more frequently is a welcomed item, for sure.

However, that implies that there is even more packages to test and what has not 
been discussed is the fact that there are not more people testing.

For WinRT the situation has been that Olli and I needed to test 
winrt/winphone-(arm/x64)-msvc(2013/2015), and that at least once per week. As 
you can imagine, if you go through the testing matrix properly that's around 
half a day for one package with multiple packages per person. There is not much 
time left to do development and bug fixing. For other platform teams the 
situation is the same. This has the effect that you start to be more "flexible" 
in what you test and hence it is way easier for a bug to slip through. 
Certainly we want to avoid that, but have not tackled any way to do so.

I remember that others volunteered to help with package testing. That surely 
would be welcomed, but also given the fact that Jani sends out testing requests 
fairly often and the response rate is zero / nada / null / nil since years, I 
doubt that will change as well.

Preferrably I'd not like to spend again 50%+ of my time testing packages until 
summer, or even more once the 5.8.1 discussion comes up again.


Maurice


> -Original Message-
> From: Development [mailto:development-
> bounces+maurice.kalinowski=qt...@qt-project.org] On Behalf Of Jani
> Heikkinen
> Sent: Tuesday, March 28, 2017 8:48 AM
> To: Lars Knoll ; Alex Blasche 
> Cc: Qt development mailing list 
> Subject: Re: [Development] Proposal to adjust release candidate process
> 
> 
> > -Original Message-
> > From: Development [mailto:development-
> bounces+jani.heikkinen=qt.io@qt-
> > project.org] On Behalf Of Lars Knoll
> > Sent: tiistaina 28. maaliskuuta 2017 9.33
> > To: Alex Blasche 
> > Cc: Qt development mailing list 
> > Subject: Re: [Development] Proposal to adjust release candidate
> > process
> >
> >
> > > On 28 Mar 2017, at 08:09, Alex Blasche  wrote:
> > >
> > >
> > >>> Sounds good, but please remember we'll need to keep at least the
> > >>> source tarballs for each and every beta and RC that we release.
> > >>
> > >> Yeah, that's OK
> > >
> > > This implies that the user can identify the exact tag or version
> > > (aka beta 5)
> > somewhere in the installer. Each bug report has to state this value.
> >
> > Yes, either through a number or (preferable IMO) by simply putting the
> > sha1 of qt5.git into a visible place.
> 
> We were planning to use Beta N in installer UI as well as git tags. should be 
> ok
> and it is following current ways of working
> 
> br,
> Jani
> 
> 
> >
> > 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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Announce] Qt VS Tools (Beta) released

[Maurice Kalinowski]

Done.

Maurice


From: Development 
[mailto:development-bounces+maurice.kalinowski=qt...@qt-project.org] On Behalf 
Of Alan Ezust
Sent: Tuesday, January 3, 2017 5:49 PM
To: development@qt-project.org; Alessandro Portale 
Subject: Re: [Development] [Announce] Qt VS Tools (Beta) released

I just installed VS2013 and now i want to install the vs2013 addin, but the 
very first link from that article
http://doc.qt.io/vs-addin/index.html
is 404 not found.
Can someone please fix that link so it works again?
thanks!
--Alan

On Thu, Aug 11, 2016 at 6:06 AM, List for announcements regarding Qt releases 
and development > wrote:
We are pleased to announce the release of the Qt VS Tools (Beta)!

http://blog.qt.io/blog/2016/08/11/from-visual-studio-add-in-to-qt-vs-tools-beta/

Br,
--
Alessandro Portale
Senior Manager, R

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
alessandro.port...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B
___
Announce mailing list
annou...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/announce
___
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 to adjust release candidate process

[Maurice Kalinowski]

Hence,

Technology Preview
Preview
Release Preview
Release Candidate
Release

\o/

Maurice

Von: Development 
[mailto:development-bounces+maurice.kalinowski=qt...@qt-project.org] Im Auftrag 
von Marco Bubke
Gesendet: Wednesday, December 21, 2016 4:21 PM
An: Thiago Macieira ; development@qt-project.org
Betreff: Re: [Development] Proposal to adjust release candidate process


I think many users see a beta as something you better not touch, but a release 
candidates can be trusted much more. I know it's not intended that way but 
people learned by experiences. [??]



Maybe "pre release" or "preview" could be a name to show the final status?






From: Development 
>
 on behalf of Thiago Macieira 
>
Sent: Wednesday, December 21, 2016 3:45:37 PM
To: development@qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process

Em terça-feira, 20 de dezembro de 2016, às 13:34:39 BRST, Tuukka Turunen
escreveu:
> If desired, we could use some other name than "Release Candidate 1" for the
> release that begins the last phase of the release. It could be called "Beta
> 2" or "Technology preview", if so desired. Personally, I would call it
> "Release Candidate 1".
>
> The difference to our current process is quite small. In essence it would be
> about considering the "RC1" the beginning of the final releasing phase (.0
> branch), not something we do almost at the end of it. I believe that
> lowering the quality criterial for "RC1" helps us in being more efficient
> as it has been in practice impossible to really fulfill the current process
> goal and have already the first RC as good as the final.

I like the process, but I would also rename the release like you proposed. We
can't have something called "release candidate" when we *know* it's not a
candidate. Let's call it beta 2, beta 3, etc. until we can make it a release.

Release candidates are really the snapshots that the release team creates when
we're testing for sanity right before the actual release.

--
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] Qt 5.9

[Maurice Kalinowski]

> > - For WinRT/WinPhone I propose to drop WinRT 8.1 and WinPhone 8.1
> support & start using term UWP (Universal Windows platform).  It means also
> dropping msvc 2013 from WinRT/WinPhone; UWP only supports msvc2015
> 
> Absolutely agree.
[Kalinowski Maurice] 
Start using the term UWP in our website etc. WinRT is still a technical correct 
term for the API. So we should not start simply renaming mkspecs or such.

In addition this causes a couple of changes to our CI system. My proposal would 
be:

- Have winrt-x86-msvc2015 (or winrt-x64-msvc2015) replace the 
winphone-arm-msvc2013 test target on CI. Right now this would be the same build 
test, but I still hope that CI resources will allow regular CI auto tests at 
one point
- Have winrt-arm-msvc2015 replace winrt-x86-msvc2015 replace to be tested 
during qt5.git integration. Currently Windows 10 (UWP) is only tested for the 
integration due to resource constraints. It should not get worse when we are 
removing platforms.

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

Re: [Development] Qt 5.9

[Maurice Kalinowski]

> On quarta-feira, 23 de novembro de 2016 08:10:36 PST Jake Petroules wrote:
> > > The currently sold CPU's are not really the measurement stick here.
> > > The measurement stick is actually installed Win 32 systems.
> > Yes, but what's the 32-bit Windows install base which is capable of
> > running Qt? We only support Windows 7 and above now, so I can't
> > imagine it's very many. Perhaps we should try to find some metrics to base
> our decision on.
> 
> That's an important point: since Qt 5.7, we no longer support anything older
> than Windows 7. That was the first Windows with decent 64-bit support and
> computers with Windows 7, 8, 8.1 and now 10 tended to come with the 64-
> bit version pre-installed. So the chances of users running 64-bit Windows are
> much higher now.
> 
[Kalinowski Maurice] 
This is only true for the desktop case. Especially those cheap tablets with 
Windows 10 in the ~100Euro area still have Windows 10 32bit included. That 
touches a pretty big consumer area.

Also note, that those is only for classic app development. For WinRT we still 
need x86 packages, because first x86 packages should be part of the bundle, and 
secondly the x86 build can be (and actually is) used for the Windows 10 
(Mobile) emulators in addition .

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

Re: [Development] Whether Qt5.8 support Visual Studio '15' now?

[Maurice Kalinowski]

VS 15 is not released yet, and with 5.8 beta soon to be released, there are 
some time constraints to check for it. Hence any feedback in advance is nice.

Maybe Thiago has been able to look into it.

Generally, latest at its release support will be available, probably (given 
track record) earlier.

BR,
Maurice
From: Development 
[mailto:development-bounces+maurice.kalinowski=qt...@qt-project.org] On Behalf 
Of ??
Sent: Wednesday, October 12, 2016 4:06 AM
To: development 
Subject: [Development] Whether Qt5.8 support Visual Studio '15' now?

Hi,
I want compile Qt5.8 with Visual Studio '15' ，Not 2015,are there any problems？

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

Re: [Development] Help! configure won't configure on Windows

[Maurice Kalinowski]

Quoting from another mail (haven't verified myself but rather reverted the 
patch Thiago mentioned locally):

"Change https://codereview.qt-project.org/#/c/168922/ is required. 
Unfortunately it's not yet in, apparently partly due to the gerrit troubles."

Maurice


> -Original Message-
> From: Development [mailto:development-
> bounces+maurice.kalinowski=qt...@qt-project.org] On Behalf Of Thiago
> Macieira
> Sent: Friday, September 16, 2016 4:51 AM
> To: development@qt-project.org
> Subject: Re: [Development] Help! configure won't configure on Windows
> 
> On quinta-feira, 15 de setembro de 2016 18:33:24 PDT Thiago Macieira wrote:
> > On quinta-feira, 15 de setembro de 2016 18:22:14 PDT Thiago Macieira
> wrote:
> > > On quinta-feira, 15 de setembro de 2016 18:16:08 PDT Thiago Macieira
> wrote:
> > > > Then I'm back at the prompt. There was no configuration. There is
> > > > no mkspecs/ qconfig.pri and no mkspecs/qmodule.pri. Trying to
> > > > compile produces error. I can't figure out *what* should be
> > > > running the configure tests, where they are called from, much less
> > > > why nothing is happening.
> > >
> > > Now this is happening on Linux too:
> > Ok, just to be sure, I've nuked EVERYTHING from another build and it
> > also
> > happens:
> 
> I've reduce this to this commit:
> 
> commit 60e5a1c8effd4099f7b1414107b5cbb67c266210
> Author: Lars Knoll 
> Date:   Thu Aug 25 15:45:44 2016 +0200
> Commit: Lars Knoll 
> CommitDate: Sat Sep 10 14:04:01 2016 +
> 
> Modularize the new configure system (infrastructure part) [...]
> Configure is now automatically invoked when building the a project
> tree's "root" project; this works with both modular and top-level builds
> of Qt (the latter with an according change in the super repo). As an
> immediate consequence, the -skip option moves to the super repo with a
> different implementation, as configuration is now done after the repo
> list is determined. The option belongs there anyway.
> 
> That other paragraph clued me in: I haven't updated qt5.git in a while. So I 
> did
> and I tried to run qmake there:
> 
> $ qmake $srcdir
> 
> Running configuration tests...
> Checking for pkg-config... yes
> Checking for gold linker... yes
> [... cut ...]
> Build options:
>   Mode ... release; optimized tools [...]
>   Build parts  libs examples tools
> 
> 
> Why is it running qtbase's configure in qt5.git? If that's to be expected, 
> why is
> it not obeying the options I passed in configure? I passed -developer-build,
> which triggers a debug build. The above is release. I also passed -nomake
> examples, so why are examples listed?
> --
> 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] Revisiting high-DPI configuration options

[Maurice Kalinowski]

> 2) Handling fractional scale factors
> 
> This is relevant for e.g. a Windows setting of 250%, corresponding to a scale
> factor of 2.5. Presenting a fractional scale factor to the app may cause
> graphics glitches, so we round it to the nearest integer, using qRound.
> 
> However, mathematically correct rounding may not be the best kind of
> correct in this case. In particular we should consider rounding factors of .5
> down instead of up. The effect would be presenting an UI that is visually
> slightly smaller than it should be, over the current behavior of presenting an
> UI that is slightly larger.
> 
> In addition we have the option of tweaking the DPI reported to the
> application to account for the remainder from the rounding.
> So for the 250% case we can report a devicePixelRatio of 2 and a DPI of 144.
> This relies on the existing DPI handling support (fonts scale automatically,
> rest of UI may not), but since the offset from the base DPI is small it might 
> be
> OK.
> 
> Finally, we should consider adding an option to simply let the fractional 
> scale
> factor through. We have user reports of applications that work fine with such
> factors, save for one or two bugs in Qt. These are typically custom-styled
> applications that do not rely on the Qt platform styles.
> Allowing this as an option would not mean that fractional factors are
> supported in Qt (for the formal meaning of “supported"), nor that we
> necessarily spend time on fixing related issues.
> 
[Kalinowski Maurice] 
+1 from my side. On WinRT / Windows Phone / UWP, you will hardly see an integer 
scale factor. That causes troubles when developers want to have native scaling 
and we forbid this internally.

As you mentioned, we have users who patches this part and they seem to be happy 
with what works then already. If painting glitches appear, we need to be sure 
to document why that is and what potential workarounds one could apply.

BR,
Maurice

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

Re: [Development] QtSingleApplication in Qt proper?

[Maurice Kalinowski]

> 
> +1 from me to add this to QtCore
[Kalinowski Maurice] 

What is the purpose of adding those items to QtCore?
Is it that it "feels" more stable when it is inside that module, or because you 
need this feature on a regular basis?

At least personally, I never needed to implement a service, yet see it is 
useful to have a supported API in case I had to develop on such. But would I 
want to carry it around with every project I work on? Probably not...

One can also follow previous discussions about bloating Qt Core with items and 
features that clearly were not meant for 90% of use-cases, still they got added 
to the module. This causes projects like Qt Lite to arise where you can leave 
those out again, coming with the cost of manually compiling Qt for your project 
and potentially losing support.

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

Re: [Development] Qt 5.8 branching & Feature Freeze

[Maurice Kalinowski]

Hi,

Another option might be to do it the same way like we do for UWP currently due 
to limited resources on the CI system. There we have at least a compile check 
every time qt5.git integration is supposed to happen.

This is bare minimum, but at least guarantees that compilation will work for 
release. The rest still needs to be manually tested and/or is covered by 
Windows 8.1 WinRT test coverage (which isn't too high either).

BR,
Maurice

Von: Development 
[mailto:development-bounces+maurice.kalinowski=qt...@qt-project.org] Im Auftrag 
von Tuukka Turunen
Gesendet: Wednesday, June 15, 2016 11:59 AM
An: Jake Petroules ; Mike Krus 
Cc: development@qt-project.org
Betreff: Re: [Development] Qt 5.8 branching & Feature Freeze


Hi,

Perhaps we could do without CI for tvOS for Qt 5.8 and fix issues when 
breakages happen. We are still quite stretched with the CI and adding tvOS 
increases the load of the CI and also risk of breakages for everyone. That of 
course is the role of CI, but since tvOS is not at the moment so critical, 
perhaps it is better to monitor it and fix afterwards when breakages do occur.

Yours,

 Tuukka


From: Jake Petroules
Sent: keskiviikkona 15. kesäkuuta 2016 12.01
To: Mike Krus >
Cc: Tuukka Turunen >; 
development@qt-project.org
Subject: Re: [Development] Qt 5.8 branching & Feature Freeze

+1. I requested this earlier as well.

On Jun 15, 2016, at 1:51 AM, Mike Krus 
> wrote:

Hi

would it be possible to have CI for tvOS in time for this too?


Cheers,

Mike


On 15 Jun 2016, at 08:15, Tuukka Turunen 
> wrote:


Hi,

I would also like to have all new modules (if any) of Qt 5.8 as well as 
implement all (feasible) platform and compiler versions well before the feature 
freeze. Is it possible to agree that latest by 1.8. all these are completed? 
Preferably earlier, if possible.

Yours,

 Tuukka

From: Development 
[mailto:development-bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of 
Jani Heikkinen
Sent: keskiviikkona 15. kesäkuuta 2016 9.27
To: development@qt-project.org
Subject: [Development] Qt 5.8 branching & Feature Freeze

Hi all,

It was agreed in yesterday's release team meeting to propose following schedule 
for Qt 5.8 branching and Feature Freeze:

- Start branching '5.8' from 'dev': 2.8.2016
- Feature Freeze (and finalize branching): 9.8.2016

With that schedule we should be able to release Qt 5.8.0 before Christmas. 
Delaying these would cause Qt 5.8.0 release to be delayed to the beginning of 
next year. Any objections?

br,
Jani


Jani Heikkinen
Release Manager

The Qt Company
Elektroniikkatie 13
90590 Oulu Finland
jani.heikki...@qt.io
+358 50 4873735
http://qt.io



[http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png]
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png]


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

--
Mike Krus | mike.k...@kdab.com | Senior Software 
Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel: UK +44-1625-809908   Mobile: +44 7833 491941
KDAB - The Qt Experts

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

--
Jake Petroules - jake.petrou...@qt.io
Consulting Services Engineer - The Qt Company
Qbs build system evangelist - qbs.io

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

Re: [Development] QMovie no longer supports .mng

[Maurice Kalinowski]

> > As a distribution packager, I think that's a good plan. :-) The people 
> > on proprietary operating systems seem less happy about that, as 
> > evidenced by this thread. But that's not MY problem… ;-)
>
> Indeed.
>
> If we want the binaries to include the builds, we could include the DLLs for 
> those libraries too.

For all supported windows platforms? While we shrank the amount of Qt pre-built 
packages, there is still a larger amount of platforms/configurations we support 
and ask users to build from source. Stripping that away might be complicated.

Maurice 

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