Re: [Development] Let's drop MSVC 2019 for dev (6.8)

[Oliver Wolff via Development]

Hey hey

On 15/03/2024 16:47, Thiago Macieira wrote:

On Monday, 5 February 2024 01:44:29 PDT Allan Sandfeld Jensen wrote:

I was trying to drop support for it in qtwebengine in 6.7, but the problem
was it was still used for qt packaging. But if we could at least switch
packing to vs2022, it would mean we could drop it in QWE.


Can we commit to this ASAP after the 6.7 release? We'll revisit later in the
cycle whether we still need 2019. Do note that Microsoft is preparing the next
release after 2022, as seen by their shipping 17.0 Tech Previews.

Jörg accidentally broke the C++ language level set up in dev, meaning we
didn't test C++20 mode with 2019 for a day or so, and some changes that
trigger 2019's broken C++20 support went in. If we don't drop 2019 by 6.8
release, we should force it to only compile in C++17 mode.




Sorry for the long silence. I talked to some people inside the company 
and we agreed on the following plan: We will try to get MSVC 2022 
packages into 6.7 as soon as possible. For 6.8 we will then remove 
support for MSVC 2019 (and hope that not too many people rely on that 
being available in the next LTS release). That should give users some 
time to test the 2022 packages and they can report bugs and fall back to 
the 2019 packages if something breaks for them before we do the "hard cut".


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

Re: [Development] Review please: natvis improvement

[Oliver Wolff via Development]

Hey Nicolas,

On 15/05/2023 08:46, Nicolas Arnaud-Cormos via Development wrote:

Hi all,

I've created some patches for improving natvis support with Qt6 
(debugging Qt with Visual Studio), but they are stuck waiting for 
review for one month now:

https://codereview.qt-project.org/c/qt-labs/vstools/+/472264

Who would be the right person for those reviews?



I pinged the guys who should be able to help. Sorry for the wait.

Olli




I'm failing to find who is the maintainer of the VS plugin, and I 
added the only person who touched the file as a reviewer.


Thanks,
Nicolas
--
Nicolas Arnaud-Cormos | Senior Software Engineer & Teamlead
KDAB (France) S.A.S., a KDAB Group company
Tel: France +33 (0)4 90 84 08 53,https://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts


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

Re: [Development] Do we need VS2019 for Qt 6.6?

[Oliver Wolff via Development]

Hey Thiago,


On 17/01/2023 23:07, Thiago Macieira wrote:

The reason is that it is failing to parse a constant expression.


Generally I think that raising the minimal version could be done, but is 
that reason alone good enough to warrant a minimal version raise for 
every MSVC Qt user? How severe is that issue and how hard is it to work 
around it?


It looks like a minor thing if you put it like that.

Cheers,
Olli



VS2019 is still supported by MSFT in "Mainstream" mode and will be for over a
year from today:
https://learn.microsoft.com/en-us/visualstudio/releases/2019/servicing-vs2019

But VS2022 is 14 months old.

So do we need both of them?


___
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] Do we need VS2019 for Qt 6.6?

[Oliver Wolff via Development]

Hey Thiago,

On 22/01/2023 17:15, Thiago Macieira wrote:

On Tuesday, 17 January 2023 14:07:42 PST Thiago Macieira wrote:

The reason is that it is failing to parse a constant expression.

VS2019 is still supported by MSFT in "Mainstream" mode and will be for over
a year from today:
https://learn.microsoft.com/en-us/visualstudio/releases/2019/servicing-vs201
9

But VS2022 is 14 months old.

So do we need both of them?


No answer. Is that because:

a) no one cares, so we can drop it.

b) no one knows, so we can't drop it.



Sorry for the delay. We need some more time to figure out if 2019 is 
still needed for 6.6. We will let you (and the mailing list) know later 
this week.


Cheers,
Olli



___
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] Nominating Morten Sørvig as maintainer of high-DPI

[Oliver Wolff]

+1

Olli

On 20/12/2021 16:35, Tor Arne Vestbø wrote:

Hello all,

I’d like to nominate Morten Sørvig as maintainer of high-DPI in the Qt 
Project [1].


Morten has been instrumental in the development of Qt’s high-DPI 
support, and has been the de-factor maintainer for a while now. Let’s 
make it official.


Cheers,
Tor Arne

[1] Under qtbase/QtGui in https://wiki.qt.io/Maintainers 




___
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] Windows maintainer change

[Oliver Wolff]

Hi all,

I would like to propose a change in Qt's Windows maintainership. I think 
that everybody knows, that Friedemann has been doing a great job 
maintaining the Windows platform specifics in Qt's code base. He wants 
to focus on Qt for Python now so we have been looking for an alternative 
way of maintenance.


I propose a shared maintenance between Andre de la Rocha and me for 
Windows. Andre has been involved in Qt's Windows development for almost 
4 years now. He is responsible for our accessibility backend on Windows 
and rewrote mouse/touch/pen handling for that platform. He also wrote 
the "win32" bluetooth backend and fixed bugs in various areas of Qt.


I have been part of the winrt maintainership and wrote and maintain the 
"winrt" backend for Bluetooth (which is also used in Qt6 as the backend 
also works for "desktop" applications on Windows 10).


Thanks again to Friedemann for all the work he put into the maintenance 
of Qt. You have been doing a great job and I hope that we can ask for 
some guidance now and then ;)


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

Re: [Development] Moving IRC from Freenode to Libera.Chat, voting thread

[Oliver Wolff]

On 22/05/2021 03:06, Giuseppe D'Angelo via Development wrote:

Hi,

As detailed in the other thread, I'd like to gather lazy consensus for 
moving the official IRC presence from Freenode to Libera.Chat.


Please use this thread for voting ONLY. Apologies for all the formality, 
but what I thought should've been a rather painless decision blew out of 
proportion.


+1

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

Re: [Development] QThread::create mandatory in Qt 6?

[Oliver Wolff]

Hi,

On 18/11/2020 21:36, Sérgio Martins wrote:

On 2020-11-18 07:34, Oliver Wolff wrote:

Hi

On 16/11/2020 23:29, Sérgio Martins via Development wrote:

On 2020-11-16 21:57, Thiago Macieira wrote:

On Monday, 16 November 2020 13:38:06 PST Cristian Adam wrote:
LLVM.org clang.exe binary reports the x86_64-pc-windows-msvc 
target, which
is Clang/MSVC. clang-cl is just a different command line options 
parser,

which always sets the *-msvc target.

Clang/MinGW is something that ends up in *-gnu as target. That's 
the case

for winlibs and llvm-mingw.


I see, thanks.

So, what's wrong with llvm-mingw?


Probably the prebuilt toolchain Tony is using (WinLibs) has an old 
standard library.

The problem is not specific to Clang perse.


But why do we want clang-MinGW to begin with ? MinGW is niche as it 
is. I don't see anyone wanting this combo.


clang-MSVC on the other hand is useful as it means a better compiler 
frontend (clang) using a better standard library on Windows (msvc).


As far as I know, people *do* want an open alternative that does not
involve Microsoft software. That's where mingw comes into play.


I agree we want MinGW, but we already have it in the CI (gcc-mingw).
clang-mingw won't add much value, as it overlaps a lot with the existing 
gcc-mingw.


clang-cl.exe however has a bigger delta over cl.exe.



The question is not about having one more supported Windows 
configuration. We do not have the resources to add more and more 
configurations to support, so it's more a "replace mingw for Windows 
with something else" situation. As there seems to be a need for an open 
alternative, it looks like we cannot/should not go the clang-cl way, but 
clang-mingw if we replace mingw with a clang toolchain.








As we
cannot support an unlimited amount of configurations, it looks like we
will go the clang-mingw route instead of clang-msvc.






Regards,


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

Re: [Development] QThread::create mandatory in Qt 6?

[Oliver Wolff]

Hi

On 16/11/2020 23:29, Sérgio Martins via Development wrote:

On 2020-11-16 21:57, Thiago Macieira wrote:

On Monday, 16 November 2020 13:38:06 PST Cristian Adam wrote:
LLVM.org clang.exe binary reports the x86_64-pc-windows-msvc target, 
which

is Clang/MSVC. clang-cl is just a different command line options parser,
which always sets the *-msvc target.

Clang/MinGW is something that ends up in *-gnu as target. That's the 
case

for winlibs and llvm-mingw.


I see, thanks.

So, what's wrong with llvm-mingw?


Probably the prebuilt toolchain Tony is using (WinLibs) has an old 
standard library.

The problem is not specific to Clang perse.


But why do we want clang-MinGW to begin with ? MinGW is niche as it is. 
I don't see anyone wanting this combo.


clang-MSVC on the other hand is useful as it means a better compiler 
frontend (clang) using a better standard library on Windows (msvc).


As far as I know, people *do* want an open alternative that does not 
involve Microsoft software. That's where mingw comes into play. As we 
cannot support an unlimited amount of configurations, it looks like we 
will go the clang-mingw route instead of clang-msvc.





Friedmann also mentions "We want clang.cl only (as discussed many times 
already)." (QTQAINFRA-2139)





Regards,


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

[Development] Qt’s UWP backend will be dropped in Qt 6

[Oliver Wolff]

Hi,

with Qt 6 approaching it is time to have a look at our set of supported 
platforms.


One candidate for removal of support was our port for Microsoft's 
Universal Windows Platform (UWP). Some considerations about dropping 
this support have been communicated on Qt's development mailing list in 
April last year [1] and there were some discussions about this topic on 
the corresponding bug report [2]


During this year's Microsoft Build conference Microsoft announced the 
unification of Win32 and UWP for their IoT offering. In general, it 
looks like Microsoft is stepping away from their strict stance about the 
usage of UWP technology and the Windows Store. Getting a classic Windows 
application into the Windows Store is much easier nowadays and will be 
even simpler in the future. Microsoft's new direction in their IoT 
offering will bring more "classic Windows development" into the IoT 
world and there will be no need for a dedicated UWP port.


With this official Microsoft standing in mind our current plan is to 
drop our dedicated UWP platform backend for Qt 6. According to these 
plans the last Qt version that will support "native Qt UWP application" 
will be Qt 5.15.


There are two main reasons for this decision:
- The number of bug reports for the port as well as the company's user 
data indicate that there is not much interest in the port.
- Keeping the port alive and up to date is a big effort (I will spare 
the details but can of course elaborate further if there is interest). 
The company decided developers' time is better spent in other areas. By 
dropping the dedicated UWP port the company's Windows developers can 
concentrate on our "classic" win32 port and other areas that didn't get 
the attention they needed.


All in all, we hope that dropping support for the UWP port will result 
in higher quality for other parts of Qt. From the company's point of 
view this benefit outweighs the "reduced cross-platformness of Qt" as 
the port is not used that much anyway.


Backends that use UWP APIs (bluetooth, sensors and positioning for 
example) are not affected by this decision and there will most likely be 
additional backends that use new MS technology.


Best regards,
Olli

[1] 
https://lists.qt-project.org/pipermail/development/2019-April/035673.html

[2] https://bugreports.qt.io/browse/QTBUG-74755
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Windows 7 support will be dropped in Qt 6

[Oliver Wolff]

Hi Kevin,

On 16.06.2020 19:25, Kevin Kofler wrote:

Edward Welbourne wrote:

Kevin Kofler (16 June 2020 12:08)

What "shiny new features"? All that a real-world application such as
KWrite really needs from the operating system has been there at least
since the 1990s, possibly since the 1970s.


and I guess it's been in Qt for several releases now, so why would
someone with those needs care about upgrading to Qt 6 ?


Because all KDE applications will have to get ported to Qt 6 soon.

You seem to be completely disconnected from how things work in the Free
Software community, and only seeing the commercial viewpoint.


Of course this is once again from "inside that evil company", but I want 
to add something here: Lots of people inside that evil company *do care* 
about the open source community *greatly*. There have been heated 
discussions about some recent decisions that have been made inside the 
company and there was quite some disagreement internally as well. We are 
not all the "evil corporate overlords" some people might envision when 
they see a @qt.io mail address.


Having said that, the decision of dropping support Windows 7 is neither 
to alienate the open source community as you claim, nor to upset the 
commercial customers as others say. In the end it all boils down to the 
available "resources" and where we want/are able to spend our time.


We do not have an unlimited number of developers, nor do we have 
infinite processing power or an infinite number of tests systems/QA 
engineers. We do have to decide, where development/CI/QA time is spent 
best independently of open source or commercial users.


In an ideal world, we would have enough developers to easily maintain 
all the parts that are needed to have Windows 7 support. Be it in 
working around missing functionality, that is only available in later 
Windows versions or making the new graphics abstraction work on Windows 
7 as well. We are not in this situation though. Our "resources" (I don't 
like calling developers resources :X ) are limited and Windows isn't the 
most loved operating system when it comes to contributions from the open 
source community.


We did have to make a decision here. We neither targeted commercial 
customers nor opern source users, but we have to decide, where to spend 
"our time". Unfortunately Windows 7 is not a priority in this, as there 
still is much to be done for Qt 6 and we just do not have the number of 
hands to keep all these balls in the air.


I guess this won't help much when it comes to calming down people, but I 
wanted to reiterate how we came to this decision. This really isn't 
about upsetting users.


Olli



 Kevin Kofler

___
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] [Interest] Windows 7 support will be dropped in Qt 6

[Oliver Wolff]

Hi Robert,

On 11.06.2020 15:02, coroberti . wrote:

On Thu, Jun 11, 2020 at 3:43 PM Oliver Wolff  wrote:

with Qt 6 approaching it is time to have a look at our set of supported
platforms.



The operating system was initially launched in 2009 and reached its
official end of life in January 2020. That means that Microsoft no
longer provides security updates and instances running Windows 7 should
be replaced as soon as possible.

Br, Olli


Dear Oliver,

The fact is that Windows-7 is supported at least till 2023.

Please, correct your fact table.

https://www.microsoft.com/microsoft-365/partners/news/article/announcing-paid-windows-7-extended-security-updates



It's true that Microsoft offers extended support for Windows 7. This 
support does not come for free though and there is a price tag attached.


I think the same might apply inside The Qt Company. If you are a 
commercial customer and want to buy extended support for Qt beyond 
regular support availability periods, please get in touch with your 
Sales representative.



BR, Olli



Kind regards,
Robert


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

[Development] Windows 7 support will be dropped in Qt 6

[Oliver Wolff]

Hi,

with Qt 6 approaching it is time to have a look at our set of supported 
platforms.


One candidate for removal of support was Windows 7. Some considerations 
about dropping this support have been communicated on Qt's development 
mailing list in March last year [1] and there were some discussions 
about this topic on the corresponding bug report [2]


The operating system was initially launched in 2009 and reached its 
official end of life in January 2020. That means that Microsoft no 
longer provides security updates and instances running Windows 7 should 
be replaced as soon as possible.


With this official Microsoft standing in mind our current plan is to 
remove support for Windows 7 in Qt 6.0 onwards. Qt 6.0 release is 
planned towards the end of 2020, roughly one year after Windows 7’s end 
of life.


Of course, we do not make decisions like this easily or to upset our 
users but there are clear advantages that speak in favor of dropping 
support:
- We can rely on Windows functions being available instead of 
trying to dynamically load libraries which might or might not be available.
- We can use functionality that only became available in later 
Windows versions unconditionally. One example of this can be UWP APIs 
which are Microsoft's "new way of writing APIs". Our new graphics 
abstraction (RHI) can also rely on newer features being available on 
Windows
- We can focus our Windows resources on bug fixes and new 
functionality instead of maintaining this "legacy" operating system
- CI resources that are used for Windows 7 tests can be used to 
test other configurations


Br, Olli


[1] 
https://lists.qt-project.org/pipermail/development/2019-March/035532.html

[2] https://bugreports.qt.io/browse/QTBUG-74687
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Oliver Wolff]

Hi

On 24.04.2020 08:57, Joerg Bornemann wrote:

On 4/23/20 15:52, Thiago Macieira wrote:


Proposed:

 template  using QVector = QList; // mark deprecated
 template  class QList { $(implementation to be 
moved); }


Proposal 2:

 template  class QList { $(implementation to be moved); }
 template  using QVector = QList;

no deprecation.


+1 for proposal 2.

Alternatively, proposal 3 (aka "do almost nothing"):
     template  class QVector { implementation }
     template  using QList = QVector;

No deprecation of QVector.
No replacement of QList with QVector in our API.

Rationale: QList is our default sequential container, and in Qt6 we just 
change its implementation.


The "people have been told many times to not use QList" argument can be 
countered with "this has been fixed in Qt6".


The "vector is a silly name from a mathematical standpoint" argument is 
valid, but vector is an established term in C++ world. Sorry, that ship 
has sailed.




I am also in favor of proposal 2 or 3. I think deprecating either QList 
or QVector without any big advantage for the user will just make porting 
form Qt5 to Qt6 needlessly harder.


Even inside Qt we are struggling to keep up with deprecation warnings 
(Thanks to Friedemann for fixing these). I am pretty sure Creator does 
have the same "problem". Extrapolating that from "just us" to the 
broader audience we are hopefully targetting, it looks like lots of 
users/applications will be hit by these warnings and it will mean (lots 
of?) work for them.


Cheers,
Olli




Cheers,

Joerg
___
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] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Oliver Wolff]

Hi,

On 21/02/2020 13:57, Mitch Curtis wrote:
>> -Original Message-
>> From: Eike Ziller 
>> Sent: Friday, 21 February 2020 1:55 PM
>> To: Mitch Curtis 
>> Cc: Ville Voutilainen ; Alex Blasche
>> ; development@qt-project.org
>> Subject: Re: [Development] A modest proposal: disable lower-case
>> keywords (emit, foreach, forever, signals, slots) by default
>>
>>
>>
>>> On 21. Feb 2020, at 13:30, Mitch Curtis  wrote:
>>>
 -Original Message-
 From: Development  On Behalf
>> Of
 Ville Voutilainen
 Sent: Friday, 21 February 2020 12:16 PM
 To: Alex Blasche 
 Cc: development@qt-project.org
 Subject: Re: [Development] A modest proposal: disable lower-case
 keywords (emit, foreach, forever, signals, slots) by default

 On Fri, 21 Feb 2020 at 10:42, Alex Blasche 
>> wrote:
> I think a fallback to
>
> somethingChanged()
>
> without any annotation is not what we want. We'd miss vital
> information
 and reduce readability.

 Can you please explain what that vital information is?
>>>
>>> How can you tell if it's a signal being emitted or just a function call 
>>> without
>> the emit syntax? With the emit syntax before the signal emission, it's
>> immediately obvious that it's a signal.
>>
>> It isn’t because you can put “emit” anywhere in your code because it has no
>> semantics for the compiler.
> 
> I never said it had any semantic purpose, I'm purely arguing that it has 
> implications for readability.

I agree with Mitch here. For me the emit has value. It's just an 
annotation, but for me it serves a purpose. I can see that this is a 
signal emission and even if people keep arguing that this is pointless 
it serves a purpose to me. "Look here a signal is emitted, so that other 
parts who are interested in this information might react". For me that's 
important information when reading code (be it while coding or in code 
reviews).

Now everyone can tell me, that I am stupid and that is not necessary, 
but to me it looks, like people are jumping the "I agree" train and 
people who disagree are somewhat "intimidated" and do no longer dare to 
voice that.

My 5 cents,
Olli

> 
>> It’s not beter than any code comment that you could also put there, like
>>
>> /*emit*/ something();
>>
>> or
>>
>> something(); // emit
> 
> I disagree; I think those are ugly.
> 
>>> Not all signals follow the *Changed() naming convention, nor should they,
>> so it becomes even less obvious in those cases.
>>>
 ___
 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
>>
>> --
>> Eike Ziller
>> Principal Software Engineer
>>
>> The Qt Company GmbH
>> Erich-Thilo-Straße 10
>> D-12489 Berlin
>> eike.zil...@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
> https://lists.qt-project.org/listinfo/development
> 
___
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

[Oliver Wolff]

Hi,

On 17/02/2020 10:13, Edward Welbourne wrote:
> Hi all,
> 
> 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.
> 
> (Sometimes, under the present branching model, I also have to put work
> on hold until other work merges up for me to rebase it onto.  However,
> that complication shall go away soon, so I'll ignore it.)
> 
> When my team is planning sprints, our scrum master wants to know what
> tasks I'll be working on, and what counts as "Done" for each of them.
> Having a separate state for "In Review", distinct from "In Progress",
> would let us distinguish the relatively plannable, and intense, part of
> the work from the part that (often happens in a later sprint, and)
> takes up a smaller proportion of my time but may take longer.

I have never worked in scrum, but what difference does it make there? 
The task is not done, as long as it is not in the done state. If the 
review takes to long, give people from your scrum team more time for 
review. If the major hassle is CI, we would need an "Integrating" state 
to see how bad our CI is. But in the end your task is not done. Isn't 
that what your scrum master (and other stakeholders) are interested in?

> 
> So I'd like to modify our Jira work-flows to include a distinct "In
> Review" state for when I've completed the main work and am either
> waiting for review or responding to reviewers' comments.  Of course, if
> those comments prompt me to go back and start over, I'll also want to be
> able to go back to the "In Progress" state from it.
> 
> Does anyone have any objection to this, or suggestions for a better way
> to handle the relevant work-flow transition ?  If not, I'm hoping Alex
> can work out how to implement what I want ...


I am afraid that this will just lead to more mails sent by JIRA. I do 
not see a clear benefit, as (as said before) the task is not done. Being 
in review and in integration does not need any new state, because it 
does not give useful additional information.

If I am bored and want to do reviews, I can just go to codereview and 
will find more than enough open patches that are waiting for reviews. 
There is no need to take a detour via JIRA for that.

All in all I am with Andre' here. It looks like this is just for the 
sake of following some process. If reviews and integrations take too 
long actions should be taken to fix that, but adding another JIRA task 
as a dumping ground will not help anyone.

BR,
Olli

> 
>   Eddy.
> ___
> 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] Help needed: MSVC 2017 compiler bug with QHash in 5.15 - QTBUG-82166

[Oliver Wolff]

Hi Thiago,

I will have a look today.

Olli

On 16/02/2020 19:30, Thiago Macieira wrote:
> https://bugreports.qt.io/browse/QTBUG-82166
> 
> The bug report says:
> qmap.h(1213): error C2244: "QMultiMap::insert": Keine Übereinstimmung für
> Funktionsdefinition mit vorhandener Deklaration gefunden [...
> \msvc.build_x64\audiofile\audiofile.vcxproj]
> qmap.h(1211): note: Siehe Deklaration von "QMultiMap::insert"
> qmap.h(1213): note: Definition
> qmap.h(1213): note: 'QMultiMap::iterator QMultiMap::insert(const Key
> &,const T &)'
> qmap.h(1213): note: Vorhandene Deklarationen
> qmap.h(1213): note: 'QMap::iterator
> QMultiMap::insert(QMap::const_iterator,const Key &,const T &)'
> qmap.h(1213): note: 'QMap::iterator QMultiMap::insert(const Key
> &,const T &)'
> 
> my sloppy translation of German is that the compiler is at the definition of
> QMultiMap::iterator QMultiMap::insert(const Key &,const T &)
> 
> and can't find the previous declaration of such a function. It suggests these
> two instead:
> QMap::iterator QMultiMap::insert(QMap::const_iterator,const Key
> &,const T &)
> QMap::iterator QMultiMap::insert(const Key &,const T &)
> 
> The second one should have matched, since QMultiMap's iterator is just QMap's:
>  using typename QMap::iterator;
> 
> In fact, this is a using declaration, not a typedef.
> 
> MSVC 2019 compiled the change without a problem and the CI seems to have found
> no problem. The bug reporter indicates this is happening on a precompiled
> header, so it may be difficult to reproduce.
> 
> Is there a volunteer to help figuring this out? I'm strapped for time and
> access to the 2017 compiler is limited for me.
> 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 Planning: Consideration of dropping support for UWP applications

[Oliver Wolff]

On 21/04/2019 10:43, Allan Sandfeld Jensen wrote:
> On Donnerstag, 18. April 2019 14:46:59 CEST Oliver Wolff wrote:
>> Hi,
>>
>> as you might have heard, we are currently in Qt 6's planning phase and
>> thus checking things that have to be done to make Qt even better.
>> Of course we also want to use this opportuniy to drop support for
>> platforms that are no longer relevant in Qt's new environment.
>>
>> One of these platforms is Microsoft's Universal Windows Platform which
>> is used on desktop PCs (for "Tiled" UWP applications, no classic desktop
>> applications), Windows Phone, Xbox one, Microsoft Hololens, and
>> Microsoft IoT devices. With Windows Phone no longer being relevant and
>> Microsoft's IoT strategy being unclear we now consider dropping support
>> for these platforms. Additional benefits and reasons can be found in
>> https://bugreports.qt.io/browse/QTBUG-74755
>>
>> To be able to make the right decision, we now want your input as well.
>> If you can give some input on why support should be kept or have
>> additional reasons for dropping support, please reply to this mail or
>> add your input to https://bugreports.qt.io/browse/QTBUG-74755 where we
>> want to gather all the needed information before making a decision.
>>
>> As said before, nothing is set in stone. At the moment we are gathering
>> information so that we can make a well informed decision.
> 
> How does UWP support relate to using UWP APIs?
> 
> It seems a lot of new Windows API is UWP specific. For instance for HDR
> support I need to read the luminance level for SDR content in HDR mode, and I
> could only find UWP API for that.

UWP APIs are available for "classic" Windows applications as long as the 
applications run on Windows >= 10. So they can be used in Qt's desktop 
port (they might need a compile and run time check though)

This of course also means, that backends that are available on desktop 
Qt (like Sensors, Bluetooth, and Location for example) will keep working 
on Windows desktop (>= 10). These backends would not be part of UWP's 
deprecation and would be kept alive and supported.

Olli

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

[Development] Qt 6 Planning: Consideration of dropping support for UWP applications

[Oliver Wolff]

Hi,

as you might have heard, we are currently in Qt 6's planning phase and 
thus checking things that have to be done to make Qt even better.
Of course we also want to use this opportuniy to drop support for 
platforms that are no longer relevant in Qt's new environment.

One of these platforms is Microsoft's Universal Windows Platform which 
is used on desktop PCs (for "Tiled" UWP applications, no classic desktop 
applications), Windows Phone, Xbox one, Microsoft Hololens, and 
Microsoft IoT devices. With Windows Phone no longer being relevant and 
Microsoft's IoT strategy being unclear we now consider dropping support 
for these platforms. Additional benefits and reasons can be found in 
https://bugreports.qt.io/browse/QTBUG-74755

To be able to make the right decision, we now want your input as well. 
If you can give some input on why support should be kept or have 
additional reasons for dropping support, please reply to this mail or 
add your input to https://bugreports.qt.io/browse/QTBUG-74755 where we 
want to gather all the needed information before making a decision.

As said before, nothing is set in stone. At the moment we are gathering 
information so that we can make a well informed decision.
Olli
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt 6 Planning: Consideration of dropping support for Windows 7

[Oliver Wolff]

Hi,

as you might have heard, we are currently in Qt 6's planning phase and 
thus check things, that have to be done to make Qt even better.
Of course we also want to use this opportuniy to drop support for 
platforms, that are no longer relevant in Qt's new environment.

One of these platforms is Windows 7, which will reach its end of life in 
the beginning of 2020. Please keep in mind, that we are talking about 
dropping support with Qt 6, so the last version, that will support 
Windows 7 will be Qt 5's last LTS release, which will be 5.15 (will be 
relased mid 2020). So having the LTS status, Windows 7 will be - without 
extended support - supported until 2023 - which will be roughly 3 years 
after its end of life. So even if we drop Windows 7 for Qt 6, it will 
not be the immediate end of Windows 7 support in Qt.

To be able to make the right decision, we now want your input as well. 
If you can give some input on why support should be kept or have 
additional reasons for dropping support, please reply to this mail or 
add your input to https://bugreports.qt.io/browse/QTBUG-74687 where we 
want to gather all the needed information before making a decision.

As said before, nothing is set in stone. At the moment we are gathering 
information, so that we can make a well informed decision.
Olli
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Multimedia maintainer change

[Oliver Wolff]

On 07/02/2019 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.
> 

+1 from me as well

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

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

[Oliver Wolff]

On 15/01/2019 16:42, Aleksey Kontsevich wrote:
>> There were lots of comments about coding style and the generic approach
> 
> That were fixed.

The inline comments might have been fixed, but there was quite some 
disagreement about the patch's status after it was merged. That's 
reflected by the comments that were added to the initial patch set after 
the merge, so I think there is still more work to be done.

> 
> 
>> Additionally no API review has taken place yet.
> 
> That was not done - true.

API reviews are an essential aspect for new Qt modules and they can take 
quite some time until they are done and agreed upon.

I just wanted to let you know, that getting Qt Telemetry (or whatever it 
will be called) will still be a lot of work and it's much more than just 
including the current "module" into qt5.git.

Olli

> 
> -- 
> Best regards,
> Aleksey
> Linked in  https://www.linkedin.com/in/alekseykontsevich
> 
> 
> 15.01.2019, 09:55, "Oliver Wolff" :
>> Hi Aleksey,
>> On 14/01/2019 18:50, Aleksey Kontsevich wrote:
>>>   Hi,
>>>
>>>   Whether Qt Telemetry module will be included:
>>>   
>>> https://codereview.qt-project.org/gitweb?p=playground%2Ftelemetry.git;a=summary
>>>   ?
>>
>> If I remember correctly, there was quite a large amount of comments
>> about the initial patch. As far as I can see, there were no followup
>> commits so I think the status still is, that there is still a lot of
>> work to be done until the module can be part of Qt (even as tech preview).
>>
>> There were lots of comments about coding style and the generic approach
>> for example. Additionally no API review has taken place yet.
>>
>> I doubt that the module will be ready in time for 5.13 in its current state.
>>
>> Best regards,
>> Olli
>>
>>>   --
>>>   Best regards,
>>>   Aleksey
>>>   Linked in https://www.linkedin.com/in/alekseykontsevich
>>>
>>>   14.01.2019, 13:01, "Jani Heikkinen" :
>>>>   Hi all,
>>>>
>>>>   There is only a bit more than two week to Qt 5.13 feature freeze, see 
>>>> https://wiki.qt.io/Qt_5.13_Release. At this point we should already know 
>>>> if there will be some new submodules in Qt 5.13 so please get possible new 
>>>> submodule in qt5 as soon as possible; those really needs to be in before 
>>>> we start soft branching (25.1.2019)! And of course inform us about those 
>>>> new submodules; we need to create packaging configurations for
>>>>   those as well.
>>>>
>>>>   And please start updating Qt 5.13 new features page here: 
>>>> https://wiki.qt.io/New_Features_in_Qt_5.13
>>>>
>>>>   br,
>>>>   Jani Heikkinen
>>>>   Release Manager
>>>>
>>>>   ___
>>>>   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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Oliver Wolff]

Hi Aleksey,
On 14/01/2019 18:50, Aleksey Kontsevich wrote:
> Hi,
> 
> Whether Qt Telemetry module will be included:
> https://codereview.qt-project.org/gitweb?p=playground%2Ftelemetry.git;a=summary
> ?

If I remember correctly, there was quite a large amount of comments 
about the initial patch. As far as I can see, there were no followup 
commits so I think the status still is, that there is still a lot of 
work to be done until the module can be part of Qt (even as tech preview).

There were lots of comments about coding style and the generic approach 
for example. Additionally no API review has taken place yet.

I doubt that the module will be ready in time for 5.13 in its current state.

Best regards,
Olli

> 
> -- 
> Best regards,
> Aleksey
> Linked in  https://www.linkedin.com/in/alekseykontsevich
> 
> 
> 14.01.2019, 13:01, "Jani Heikkinen" :
>> Hi all,
>>
>> There is only a bit more than two week to Qt 5.13 feature freeze, see 
>> https://wiki.qt.io/Qt_5.13_Release. At this point we should already know if 
>> there will be some new submodules in Qt 5.13 so please get possible new 
>> submodule in qt5 as soon as possible; those really needs to be in before we 
>> start soft branching (25.1.2019)! And of course inform us about those new 
>> submodules; we need to create packaging configurations for
>> those as well.
>>
>> And please start updating Qt 5.13 new features page here: 
>> https://wiki.qt.io/New_Features_in_Qt_5.13
>>
>> br,
>> Jani Heikkinen
>> Release Manager
>>
>> ___
>> 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] Suggestion - Remove Windows 7 as supported development host

[Oliver Wolff]

Hi Harald,

On 13/11/2018 14:13, Harald Kjølberg wrote:


Hi,


Referring to: https://bugreports.qt.io/browse/QTBUG-70891

The suggestion is to remove Windows 7 as a supported development host, but keep 
it as a target. From the numbers I have access to, more than 55% of the users 
are on Windows 10. However, I would like to get feedback on this in case there 
are other opinions.

Can you elaborate on the expected benefits of removing Windows 7 as a supported 
development host platform? I think our major pain points are in supporting 
Windows 7 as a target platform. I don't see any advantages in dropping it as a 
"host platform".

Olli

Thanks!



Best,
Harald Kjølberg
Product Manager – QtAD






___
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] [HEADS UP] 5.12 locked down (Re: Merge and Integration status report - 2018.11.08)

[Oliver Wolff]

On 12/11/2018 23:03, Allan Sandfeld Jensen wrote:
> On Montag, 12. November 2018 22:49:02 CET Thiago Macieira wrote:
>> On Monday, 12 November 2018 12:38:38 PST Liang Qi wrote:
>>> * 10:53am staged 8 changes togehter -
>>> http://coin/coin/integration/qt/qtbase/tasks/1543764990 (failed in 53m -
>>> tst_QEventDispatcher::registerTimer() on macOS 10.13)
>> Thanks for all your effort, Liang. It is much appreciated.
>>
>> The above test seems flaky, but increasing the timeout doesn't help. It
>> complains that 20 ms wasn't enough, but 20 ms would have been enough. When I
>> increased to 50 ms, it prints the same thing but saying 50 ms. There are
>> two more failures in the same test.
>>
>> So I'm inclined to believe that this is a real failure caused by something
>> changing in the event dispatcher code relating to macOS. But the weird thing
>> is that it should be running the QEventDispatcherUNIX class...
> I would argue the test should be blacklisted at least on macOS 10.13 as a P0
> task. Fixing it can wait.
>
> 'Allan
The test also fails on WinRT and thus at least the registerTimer test in 
corelib/kernel/qeventdispatcher is blacklisted for this platform. That 
one used to be blacklisted on macos as well, but is considered stable 
with 5.12. I think blacklisting registerTimer for the gui 
eventdispatcher on WinRT would make sense, as both tests use the same 
event dispatcher on this platform (I think that's also the case on Windows).

I had a look at the problem when I blacklisted it for WinRT and one 
problem was, that QTRY_IMPL used a hard coded step interval of 50 ms, 
which of course does not make sense if you try to have a timeout of 25 
ms. In addition to that I don't know, how well coin copes with such 
short timeout, as VMs tend to be quite slow when run from Coin (in my 
experience).

To sum things up, I think tests that are blacklisted for windows/winrt 
in tst_qeventdispatcher should at also be blacklisted in 
tst_qguieventdispatcher as the same event dispatcher is used 
(https://codereview.qt-project.org/245347). I don't know enough about 
Mac's approach, but tst_qeventdispatcher::registerTimer was 
unblacklisted recently as far as I know.

Olli

>
>
> ___
> 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] QUIP 12: Code of Conduct

[Oliver Wolff]

On 26/10/2018 09:18, Ulf Hermann wrote:
> On 10/26/18 9:05 AM, Oliver Wolff wrote:
>> +1 from here as well. I also think that the proposed document (and
>> especially the "enforcement" part) is way too long
> The KDE CoC [1] does not specify any action to be taken when it's
> violated. That's the main reason why it seems shorter. If you only
> consider the equivalent sections in our proposed CoC, the KDE one is
> actually much longer. That said, I wouldn't mind replacing the "Our
> Pledge" and "Our Standards" paragraphs in the current proposal with the
> KDE CoC if that helps with acceptance here.
>
> But, how does this actually work in practice at KDE? Is there another
> document that states what they do if someone oversteps the boundaries?
> There isn't even a contact email in their CoC. So, if someone was
> slapping me around with a large fish in the KDE IRC channel, I still
> wouldn't know what to do about it.
I think it depends on the CoC's main purpose (which we are currently 
defining). I'd see it as a behavioral guideline which states how to 
interact with other people. It might basically say that we treat each 
other with respect and are not assholes (pardon the french). If a 
(potential) contributor reads these, he will get the idea and know, what 
collaboration in the project will (ideally) be like.

By filling that guideline with technicalities and punishments we take 
away that positive vibe and create a more threatening atmosphere. 
Additionally it lengthens the core document (unnessecarily in my eyes). 
Enforcement and punishments are mere technicalities which can be 
"hidden" in another document. The code of conduct should describe the 
generic ways of working together for every day, while the additional 
document of punishment will only be used rarely and thus can be "hidden" 
a bit. I still think and hope that there will not be too many cases 
where the CoC police will have to intervene.

Just my 2 cents,
Olli

>
> Ulf
>
> [1] https://www.kde.org/code-of-conduct/
> ___
> 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] QUIP 12: Code of Conduct

[Oliver Wolff]

+1 from here as well. I also think that the proposed document (and 
especially the "enforcement" part) is way too long


On 25/10/2018 19:39, André Pönitz wrote:
> On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development wrote:
>> We do have a Code of Conduct at KDE for about 10 years now, and this hasn't
>> led to abuse of power, suppression of free speech, racism against white 
>> people
>> or whatever other nonsense people seem to attribute to CoCs nowadays.
> The KDE CoC is *friendly*. It contains words like "considerate", "pragmatic",
> "support". It doesn't push someone's personal political agenda.  This is a
> completely different beast than the Contributor Covenant that's about
> "enforcing", "reporting", "banning".
>
> I think we'd see much less heat in the discussion if the proposed Qt CoC had
> been based on the KDE CoC.
>
> Andre'
> ___
> 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] Change ANGLE 3rd party source from Google to Microsoft

[Oliver Wolff]

Hi Brett,

On 03/08/2018 14:46, Stottlemyer, Brett (B.S.) wrote:

On 8/3/18, 5:06 AM, "Development on behalf of Oliver Wolff" 
 
wrote:

 Hi,
 
 Is everyone ok with this change? The ANGLE update from Google (which

 uses a revision that still supports MSVC 2015) would be ready
 (https://codereview.qt-project.org/#/c/233385/), but we would like to
 use a newer version from Microsoft for 5.12 if we can agree on this change.
 
Just a quick look at the commit history shows Google’s version is under active development (last commit today) while Microsoft’s version is not (last commit, as of just now, was Oct 9th, 2017).  So, the choice is using an old sha on a maintained repo, or HEAD of an unmaintained one?  Hopefully that isn’t the case.
you seem to be correct. I will try to get in touch with them and ask 
about the status.


IIUC, Chromium moved to clang-cl builds for windows (see 
http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html).  
What/how is QtWebEngine building for 64+ (chromium) on windows?
I think QtWebEngine does not use the ANGLE version shipped with qtbase, 
but has another version of ANGLE shipped, but I will let someone from 
the WebEngine team comment on that. For qtbase we need to build ANGLE 
with MSVC 2015 and 2017 and with MinGW. Changing to clang-cl is not an 
option there.


Thanks,
Brett

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


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

[Development] Change ANGLE 3rd party source from Google to Microsoft

[Oliver Wolff]

Hi,

I would like to propose a change of where we get the ANGLE sources we 
use in qtbase. At the moment we use Google's ANGLE 
(https://github.com/google/angle). Unfortunately they stopped supporting 
MSVC 2015 last year and their UWP code path does not build out of the 
box. Microsoft (https://github.com/Microsoft/angle) still actively 
maintains MSVC 2015 and also has a focus on UWP within their port. As 
far as I can tell there is no difference in the license used, so we 
should be fine from that point of view.


Background info: ANGLE is used to translate OpenGL calls to Direct 3D. 
This is done for desktop Windows
    - by default (when no "-opengl ..." is given (which arguably should 
be changed to dynamic))
    - if native OpenGL fails (when configured with -opengl dynamic)  
due to crappy opengl drivers or blacklisted GPU for example


Is everyone ok with this change? The ANGLE update from Google (which 
uses a revision that still supports MSVC 2015) would be ready 
(https://codereview.qt-project.org/#/c/233385/), but we would like to 
use a newer version from Microsoft for 5.12 if we can agree on this change.


Best regards,
Olli

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

Re: [Development] Noninating André de la Rocha for Approver

[Oliver Wolff]

+1 (disclaimer: We are sitting in the same office)

Olli


On 25/07/2018 17:12, Alex Blasche wrote:

Hi,

I'd like to nominate André for approver rights.

He has been with us at the TQtC for almost a year. He has mainly contributed to the 
Win32 port (e.g. Windows UI Automation adoption & Windows Pointer Input Message 
Support) but you may have seen an occasional iOS fix too.

His work:
https://codereview.qt-project.org/#/q/owner:+andre.rocha,n,z

His reviews:
https://codereview.qt-project.org/#/q/reviewer:+andre.rocha,n,z


--
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 Miguel Costa for Approver

[Oliver Wolff]

+1... he did a tremendous job with the AddIn (disclaimer: he is sitting 
next to me in the office)


Olli


On 25/07/2018 17:12, Alex Blasche wrote:

Hi,

I'd like to nominate Miguel for approver rights.

He has been with us at the TQtC for a year. His largest contributions have been 
to the Visual Studio addin which he properly ported to the latest VS 
incarnations/APIs. More recently he has started to look at the WinRT port and 
the Angle integration in particular.

His work:
https://codereview.qt-project.org/#/q/owner:+miguel.costa,n,z

His reviews:
https://codereview.qt-project.org/#/q/reviewer:+miguel.costa,n,z

--
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] qtbase auto tests on UWP (formerly known as WinRT) enabled

[Oliver Wolff]

On 27/06/2018 07:14, Oliver Wolff wrote:

Hi,

yesterday I merged a change, that enables execution of qtbase auto 
tests on UWP (formerly known as WinRT).


The used configuration uses MSVC 2015 so error messages should be 
somewhat familiar, but some UWP headers tend to give weird error 
messages. If you run into a problem you cannot fix yourself, please 
just ping on #qt-winrt on freenode or send me a mail.


I have already seen on integration which fails due to the WinRT config 
(https://codereview.qt-project.org/#/c/233249/) and am currently 
having a look at what's wrong there.
https://codereview.qt-project.org/#/c/233403/ reviews welcome and sorry 
for the breakage




BR,
Olli

___
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] qtbase auto tests on UWP (formerly known as WinRT) enabled

[Oliver Wolff]

Hi,

yesterday I merged a change, that enables execution of qtbase auto tests 
on UWP (formerly known as WinRT).


The used configuration uses MSVC 2015 so error messages should be 
somewhat familiar, but some UWP headers tend to give weird error 
messages. If you run into a problem you cannot fix yourself, please just 
ping on #qt-winrt on freenode or send me a mail.


I have already seen on integration which fails due to the WinRT config 
(https://codereview.qt-project.org/#/c/233249/) and am currently having 
a look at what's wrong there.


BR,
Olli

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

Re: [Development] Proposing Oliver Wolff as platform maintainer for UWP

[Oliver Wolff]

Thanks for the trust everyone.


On 30/04/2018 10:54, Alex Blasche wrote:

Congratulations to Oliver. The wiki was updated.

--
Alex


-Original Message-
From: Development [mailto:development-
bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Maurice
Kalinowski
Sent: Monday, 9 April 2018 14:18
To: development@qt-project.org
Subject: [Development] Proposing Oliver Wolff as platform maintainer for UWP

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

___
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 Mårten Nordheim as an approver

[Oliver Wolff]

+1 from me as well. He is one of the brave souls who had a look at 
beautiful winrt code voluntarily (and gave valuable feedback on it)



On 25/04/2018 13:40, Edward Welbourne wrote:

Hi all,

I'd like to nominate Mårten Nordheim for Approver.

We've had him here at TQtC, in the Core & Network team, for a bit over a
year; he's been reviewing steadily and finding mistakes I miss.  As well
as diverse work in qtbase, he's also dabbled in the qtnetworkauth and
qtwebsockets modules.  Here's his list of changes in gerrit:

https://codereview.qt-project.org/#/q/owner:"M%25C3%25A5rten+Nordheim",n,z

and the (somewhat busier) list of what he's reviewed:

https://codereview.qt-project.org/#/q/reviewer:"M%25C3%25A5rten+Nordheim",n,z

Eddy.
___
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] Building Qt with dynamic OpenGL on MinGW broken

[Oliver Wolff]

Hi,

On 04/08/2016 09:49, Julius Bullinger wrote:

Hello,

because of QTBUG-52487, there's currently no straight-forward way to build an 
OpenGL-dynamic QT 5.7 with MinGW on Windows. There's a patch attached to the 
bug report, but it's not on Gerrit (and the author hasn't responded to the 
request to push it to Gerrit).
for me the straightforward way for that configuration is to install the 
DirectX SDK and use that. With that installed the build just works fine 
here. Are there any issues with that?


May I propose that somebody else takes the patch and pushes it to Gerrit for a 
proper review?
I think that there is more to that than the patch attached to the bug 
report (as the reporter says, that the PATH variable has to be adapted). 
So it's probably not just taking the patch and pushing it to gerrit.


Thanks and best regards,
Julius

Best regards,
Olli

___
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 Visual Studio V1.2.5

[Oliver Wolff]

Am 23.02.2016 um 11:49 schrieb Graham Labdon:

Hi
So I just installed the latest visual studio addin (for VS2012) but I seem to 
have lost the integrated help
Can anyone suggest why this might be?

thanks


Hi Graham,

what exactly does not work for you? Don't you have any Add-In or Qt help 
available or doesn't context sensitive help work for you? Can you check, 
whether "HELP -> Add and Remove Help Content" (Alt+Ctrl+F1) shows the 
help files shipped with the Add-In (Qt5 and Visual Studio Addin 1.2)?


Best regards,
Olli



___
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] ot: qt development information

[Oliver Wolff]

Hi,

the short and simple answer is no. The current version of the Qt Visual 
Studio Add-In only supports Qt 5.x.


On 2/24/2015 15:42, Alessio Mochi wrote:
I would like know if exist an integration plugin for vs2013 that work 
with qt 4.8.

Thanks.


___
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] Feature Freeze exception for SSL on WinRT

[Oliver Wolff]

Hi,

similar to the efforts that are done to get SSL running on Ios we are 
also trying to make it happen on WinRT. Unfortunately the functionality 
will not be ready in time for the feature freeze. As SSL support is 
quite important for the whole network story (and to bring enginio to 
winrt as well), I kindly ask to get a feature freeze exception for WinRT 
for that area. I talked to Rich about having a stub implementation (see 
https://codereview.qt-project.org/#/c/91576/ ) in for the feature freeze 
and add functionality there afterwards. Even though he would have 
preferred to have the functionality in place in time, having the stub in 
place and fill it (right) afterwards is fine with him. So (one) the 
approver would be fine with that approach, but asking here is probably 
another story.

So would having an exception for WinRT be ok in that case?

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

Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)

[Oliver Wolff]

On 13/05/2014 16:47, Thiago Macieira wrote:
 Em ter 13 maio 2014, às 09:57:59, Knoll Lars escreveu:
 That won't help unless we also disable the revdep for QtQuick, as QtQuick
 depends on QtNetwork.
 That doesn’t mean we need to run the network tests as a revdep as well.
 Then the problem is simply of running the network tests. The CI could be smart
 and decide that it doesn't need to run tests/auto/network if src/network
 wasn't modified.


I don't think that this is a good idea. Changes in QtCore which break 
something in network
wouldn't cause a CI error and test failures would only surface as soon 
as a change to network
is made. Isn't that one of the situations we want to avoid?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: Managing the Addition of New SSL Backends

[Oliver Wolff]

On 06/05/2014 08:11, Jeremy Lainé wrote:
 Thanks Richard for taking the time to write up your summary, as the subject 
 is pretty vast.

 On 05/03/2014 11:23 PM, Richard Moore wrote:
 Support for QNAM
 

 It's obvious that to be useful, a backend must allow QNAM to make SSL
 requests. It need not support the more advanced features such as
 client certs, custom CAs, custom cipher suites etc.

 In order to handle user exceptions, we need a way to signal the
 errors. This means that QSslError would be required. Another option
 might be to offer some pre-built UI component for this, but that has
 the issue that a single component would probably not be a good fit to
 many UIs.
 Who is looking into WinRT, as I'd be interested in hearing what the WinRT API 
 offers in
 terms of error reporting?
As covered in in [1] there should be at least enough error reporting to 
implement a minimal SSL subset
for WinRT.


 On the iOS / Secure Transport front, QSslError support is not going to be as 
 detailed as
 the OpenSSL backend as the API offers very little detail about what went 
 wrong
 establishing a secure connection.


 Another issue is displaying the certificate to the user. The
 QSslCertificate API is large, and whilst I think most backends would
 be able to provide most (if not all) of the facilities this is still a
 significant barrier. Instead, how about we allow QSslCertificate to be
 used as an opaque type for most apps?  This could be done by providing
 access to the platform native (or a Qt provided) certificate
 dialog. This would reduce the requirements for the backend
 substantially.
 Can you explain your thinking in more detail on this point? For iOS / Secure 
 Transport
 there is a clean separation between the SSL code and anything GUI related - 
 to my
 knowledge there is no native dialog to handle accepting certificates.
I don't think that there is that kind of dialog for WinRT either or at 
least I haven't seen anything like that.
So to have all that cross platform and not have to implement it again 
and again we should probably offer
a Qt dialog which has the most important certificate properties inside?

 On the other hand:

 - you can get access to the raw DER data for the certificate 
 (SecSecurityGetData [1])

 - you can create a certificate instance from the raw DER data
 (SecCertificateCreateWithData [2])

 I have therefore written some code to parse just enough ASN.1 to extract the 
 certificate
 details:

 https://qt.gitorious.org/qt/sharkys-qtbase/source/ec189e6994b331e0e6662440a4a6fba3366277ec:src/network/ssl/qsslcertificate_ios.cpp

 Does WinRT provide access to the DER data?
Yes see [2]

 Simplifying the Cipher API
 ==

 Currently, the QSslCipher API is pretty large. It's not simply the
 code in the QSslCipher class itself, but also all the stuff in the
 QSslConfiguration that defines the preferences. Instead, we could
 offer a simplified API that all backends must offer. So, for example
 we could have something as simple as High, Medium and Low! After all,
 most people (including developers) don't know the trade-offs of the
 different cipher suites anyway. We could also have a flag for perfect
 forward secrecy since that is independent of the strength. It would
 also be possible to have a setting like FIPS for people who care about
 that.
 I haven't looked into what iOS offers here yet.

 Cheers,
 Jeremy

 [1]
 https://developer.apple.com/library/ios/documentation/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/c/func/SecCertificateCopyData

 [2]
 https://developer.apple.com/library/ios/documentation/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/c/func/SecCertificateCreateWithData

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

Cheers,
Olli

[1]
https://bugreports.qt-project.org/browse/QTBUG-37497

[2]
http://msdn.microsoft.com/en-us/library/windows/apps/windows.security.cryptography.certificates.certificate.getcertificateblob.aspx
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Question about modifiers in key events

[Oliver Wolff]

Hi,

I am trying to fix https://bugreports.qt-project.org/browse/QTBUG-35632 
and while
doing so I noticed that this use case is broken on Linux, Windows and 
Mac. Running
the code from my last comment I get different results depending on the 
platform. When

it is run on Linux or Windows I get:
Event: true false false

Application: false false false


while Mac gives:
Event: false false false

Application: false false false


At least on Windows and Linux (xcb) there seems to be logic involved 
which removes
the modifier if the key pressed was a modifier key itself (so if 
Qt::Key_Control is pressed
Qt::ControlModifier is removed from the modifiers). This is done in 
qwindowskeymapper
line 863ff on Windows. I could not find the place where it is done in 
xcb but checking the
code from the bug gives the same result as on Windows. The event's 
modifiers are then

assigned to QGuiApplication's modifier_buttons (which is used for
QApplication::keyboardModifiers() from the bugreport), which is why that 
shows wrong results.
QEvent::modifiers (qevent.cpp line 1026ff) readds the modifier so that 
this gives correct results

at least on Linux and Windows.

My question is which would be the right way to fix this behaviour. My 
initial idea was to remove
the logic that removes the modifier from Windows and XCB and adapt 
QEvent::modifiers accordingly
so that the modifiers are not removed and added in various places. 
Unfortunately I do not know, which
behaviour/use case would be broken by that as auto test coverage seems 
to be not existent in that area
(which I would like to change as well, but...). Another option would be 
to add the logic that readds the
modifier (the one from QEvent::modifers) to QGuiApplicationPrivate, but 
that would be another place
that plays around with the modifiers. Also this logic would have to be 
put in use in several places there

(processKeyEvent, processMouseEvent, processTabletEvent, etc).

Does anyone have an idea, why modifiers are removed/added in various 
places and which use case might
be broken when I touch something there? Thiscode seems to be fragile, as 
changes seem to cause regressions
as we have seen over the last few patches to the windows implementation. 
Any preferred way of fixing this?


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

Re: [Development] Question about modifiers in key events

[Oliver Wolff]

On 14/01/2014 08:26, Oliver Wolff wrote:

Hi,

I am trying to fix 
https://bugreports.qt-project.org/browse/QTBUG-35632 and while
doing so I noticed that this use case is broken on Linux, Windows and 
Mac. Running
the code from my last comment I get different results depending on the 
platform. When

it is run on Linux or Windows I get:
Event: true false false

Application: false false false


while Mac gives:
Event: false false false

Application: false false false


At least on Windows and Linux (xcb) there seems to be logic involved 
which removes
the modifier if the key pressed was a modifier key itself (so if 
Qt::Key_Control is pressed
Qt::ControlModifier is removed from the modifiers). This is done in 
qwindowskeymapper
line 863ff on Windows. I could not find the place where it is done in 
xcb but checking the
code from the bug gives the same result as on Windows. The event's 
modifiers are then

assigned to QGuiApplication's modifier_buttons (which is used for
QApplication::keyboardModifiers() from the bugreport), which is why 
that shows wrong results.
QEvent::modifiers (qevent.cpp line 1026ff) readds the modifier so that 
this gives correct results

at least on Linux and Windows.

My question is which would be the right way to fix this behaviour. 
My initial idea was to remove
the logic that removes the modifier from Windows and XCB and adapt 
QEvent::modifiers accordingly
so that the modifiers are not removed and added in various places. 
Unfortunately I do not know, which
behaviour/use case would be broken by that as auto test coverage seems 
to be not existent in that area
(which I would like to change as well, but...). Another option would 
be to add the logic that readds the
modifier (the one from QEvent::modifers) to QGuiApplicationPrivate, 
but that would be another place
that plays around with the modifiers. Also this logic would have to 
be put in use in several places there

(processKeyEvent, processMouseEvent, processTabletEvent, etc).


Of course it does not have to be added to several places, as only key 
events can remove modifiers depending
on the key pressed. But the question about the best way to fix it still 
stands :)




Does anyone have an idea, why modifiers are removed/added in various 
places and which use case might
be broken when I touch something there? Thiscode seems to be fragile, 
as changes seem to cause regressions
as we have seen over the last few patches to the windows 
implementation. Any preferred way of fixing this?


Cheers,
Olli


___
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's winrt port. Bringing it to dev and questions about networking

[Oliver Wolff]

Hi,

as some of you might have heard we are planning to get qtbase's winrt
branch integrated to dev in order to have a tech preview available at 
least for that part of Qt. In order to have it reviewed properly it 
would be awesome if some of you could have a look at the winrt topic
branch 
(https://codereview.qt-project.org/#q,status:open+project:qt/qtbase+branch:dev+topic:winrt,n,z)
and review changes there. Every other feedback is of course welcome as well.

We are still struggling with the network part of the code. I am
somewhat lost about how to activate socket notifiers for the port.
It looks like I can listen on ports and connect to servers but
example do not work. Neithger googlesuggest nor fortuneserver/-client
give any output. The WIP network change can be found here
https://codereview.qt-project.org/#change,64822 The approach to handling
sockets changed fundamentally so that mapping the options to the new
approach isn't always trivial.

The part I seem to be struggling with most is activating socket
notifiers as soon as something can be read from/written to a socket.
Handling of these events should done in qnativesocketengine_winrt.cpp 
(about line 417) but I don't know how to trigger something for the
notifiers from there. Ossi suggested to give the information about
data being available back to the event loop and have it handled there
but I could not find a way on how to do that. My issue basically seems
to be that the sockets do not know about their notifiers and I seem
unable to make a connection the other way around. Any input on that
problem would be highly appreciated :)

Thanks,
Olli

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

Re: [Development] Nominating Andrew Knight (aknight) for Approver

[Oliver Wolff]

Am 30/08/2013 13:37, schrieb Robin Burchell:
 Hello,

 I'd like to nominate aknight for approver status. Andrew has been
 doing some solid work that I've noted in QtWayland (and with wayland
 in general), and also appears to have some solid knowledge of Windows
 from his dashboard:
 https://codereview.qt-project.org/#dashboard,1001190. Also useful:
 https://codereview.qt-project.org/#q,status:closed+owner:%2522andrew+knight%2522,n,z

 Andrew is responsive on IRC and helpful during code review/discussion,
 so I think he'd be an asset.

 Anyone willing to second?

 BR,

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


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

Re: [Development] Qt 5.2 timelines

[Oliver Wolff]

Hi,

just as a heads up we hope to be able to get at least the qtbase
part of Qt's winrt port into dev before feature freeze. Plan is to
create the merge request by September 6 so that there is enough time
for reviews. If you want to have a look earlier you are of course
welcome to do so as well. Code can be found in winrt branch of qtbase.

Cheers,
Olli

Am 14/08/2013 14:13, schrieb Knoll Lars:
 Hi everybody,

 just wanted to send out a heads up about the Qt 5.2 timelines.

 I'd like to have the feature freeze at the 20th of September, so that we
 can have a alpha out before end of September, as discussed. Then we work
 towards a beta by the end of October, and a final by end of November.

 This is a pretty tight plan, but we can not really do the feature freeze a
 lot earlier since we will need the time to finish the Android and iOS
 ports and the qml/v4 work. Also KDE was asking for time until the end of
 September, so that they will be able to get all the features in that they
 need for the first release of KDE Frameworks 5.

 An added complication is that 5.2 and Qt Creator 3.0 will have
 interdependencies, so we will need to get them ready together. That
 implies that we will need to react fast and quickly to any showstoppers
 that the creator team finds in Qt 5.2.



 We used around a bit more then 3 months to get 5.1 out, and this plan
 leaves a lot less time for stabilisation of 5.2. There are however reasons
 why I believe we can achieve the plan.

 A lot of the delays in 5.1 happened because of 4 reasons:
 * stability issues with the CI system
 * Adding of two new platforms to CI and packaging
 * Lots of late changes to the build system
 * Addition of the online installers

 None of these should repeat themselves. The CI system is under much better
 control now, and we don't add online installers or new platforms again
 this time. I'll also veto build system changes after branching into stable.

 In addition, the quality of 5.1 is quite a bit better then 5.0, so we
 should have less showstoppers during the stabilisation phase..

 One thing we need to do however to give us a chance of making the final
 release happen according to plan is to add any new modules that will be
 part of 5.2 to the packaging now. We had some good discussions around Qt
 Connectivity, Mac/Win Extras and Location during the contributor summit,
 and should conclude on these modules very soon now.

 In addition, I believe we should start creating daily packages from the
 dev branch, so that we know our packaging is in a decent shape already
 before we branch into stable.

 With this in place, I believe we will manage to shorten our stabilisation
 phase down to around two months and be able to release 5.2 by end of
 November.

 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] Please warn of force pushes...

[Oliver Wolff]

Hi,

Am 22/04/2013 03:14, schrieb Thiago Macieira:
 My server just let me know:

From git://gitorious.org/qt/qtbase
 60fbb00..c5a3cfa  dev- dev
 1f3a67e..f78842a  stable - stable
   ! [rejected]winrt  - winrt  (non-fast-forward)

 PLEASE let the mailing list know every time a history rewrite is about to
 happen and when it has happened in one of the main repositories.




as this branch is rebased (not merged) regularly (Ossi does the actual 
rebase) forced pushes happen quite often. We will send out a notice 
before these happen in the future, sorry for not thinking of that.

Cheers,
Olli

 ___
 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