Re: [Development] Moving QDesktopServices from Gui to Core?

[Lars Knoll via Development]

> On 7 May 2024, at 19:15, Thiago Macieira  wrote:
> 
> On Tuesday 7 May 2024 10:03:21 GMT-7 Thiago Macieira wrote:
>> So I want to know of a use-case where all of the following are true:
>> * application is GUI-less (i.e., is a background service)
>> * application has no GUI counterpart
>> * application is definitely running in a GUI environment

One example I’ve seen are installation scripts that you run from the command 
line that need some permissions and launch a browser to get them. Pretty much 
the OAuth case mentioned here.
> 
> Rethinking a little here, if we drill d own one level it may make sense. 
> Replace "application" with "library":
> 
> One may want to make a library that has no GUI dependency and implements some 
> network service. Therefore, they don't want to link to QtGui for 
> QDesktopServices. If the functionality is in QtCore, then they could request 
> the browser if the application is GUI.
> 
> The problem is that said library needs a fallback if the application is *not* 
> GUI. Moreover, I'd question the automatic launching of a browser as part of 
> this library's behaviour. A better design would be for it to emit a signal 
> indicating it requires something to happen and then to let the application or 
> a wrapping library to make a policy decision on what to do.

There could also be use cases where you have split your app into two parts, a 
UI running in one process and a backend running in another one. The backend 
doesn’t link against any GUI libraries, but might need to launch an OAuth flow 
in response to something that’s been triggered by the UI. And there could be 
many reasons why you’d want a process separation, security being one of them.

So I do believe there are valid use cases for opening a browser window from a 
process that does not link against a GUI library. Given that the implementation 
doesn’t require anything UI specific neither I don’t see why we shouldn’t have 
it in Qt Core.

Cheers,
Lars

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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Lars Knoll via Development]

> On 6 May 2024, at 09:02, Marc Mutz via Development 
>  wrote:
> 
> Hi,
> 
> Juha is currently improving the OAuth implementation in QtNetworkAuth. 
> The protocol involves launching the system browser to get an access 
> code, in turn used to get access tokens with which services can then be 
> accessed.
> 
> OAuth therefore requires a UI to run the browser in, but not necessarily 
> a _G_UI (the system browser could be lynx). Even if a CLI tool like a 
> mail fetcher, backup program, or VPN client will eventually launch 
> Firefox or Chrome, I think it's too much to ask to link to QtGui just to 
> do the equivalent of exec xdf-open .

I’d agree with that. And there’s no way to do OAuth without launching a browser 
during the authentication process.
> 
> I've looked at the implementation of openUrl(), and the only 
> Gui-dependency is on the platform helpers. The handler registration is 
> only using Core functionality.
> 
> I would therefore propose to move the services code from Gui to Core 
> (QTBUG-125085), so QtNetworkAuth can access it w/o incurring a Gui 
> dependency.
> 
> After a quick look, I can see two ways to do that:
> - keep the platform handling code in the platform helpers, incl. Gui 
> dependency, and only move the handler registration to Core
> - move the platform url handlers out of the platform helpers into (a 
> plugin for) Core
> 
> The first would enable users to write their own handlers w/o Gui 
> dependency, but has the disadvantage that the code behaves differently, 
> depending on whether QtGui is loaded or not.
> 
> The second would be more work, but with consistently better user experience.
> 
> Is there a reason other than history for the openUrl handlers to be in 
> the platform handlers? We have XDG-code in QtCore already (mime types), 
> so we should have all the information in Core already to implement the 
> functionality, should we not?

I believe the reason for this is mainly history. Moving this to Qt Core makes 
sense IMO.

I don’t think you need a separate plugin for Qt Core to implement this though. 
I’m a bit unsure about the windows code, but on Linux and macOS it’s simply 
launching ‘xdg-open’ or ‘open’. It would probably fit better to simply follow 
the usual pattern for Qt Core with a _platform.cpp implementation file.

Cheers,
Lars


> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz  (he/his)
> Principal Software Engineer
> 
> The Qt Company
> Erich-Thilo-Str. 10 12489
> Berlin, Germany
> www.qt.io
> 
> Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
> 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] Nominating Jøger Hansegård for approver rights

[Lars Knoll via Development]

+1!

Lars

> On 14 Mar 2024, at 10:06, Tor Arne Vestbø via Development 
>  wrote:
> 
> Hi,
> 
> I would like to nominate Jøger Hansegård for approver rights in the Qt 
> project.
> 
> Jøger joined The Qt Company 10 months ago and has since then been getting his 
> hands dirty in Qt Multimedia, and lately focusing on color management.
> 
> Jøger is a thorough and responsible engineer and I trust that he will make a 
> good approver for the Qt project.
> 
> Authored changes: 
> https://codereview.qt-project.org/q/owner:joger.hansegard%2540qt.io
> Reviews: 
> https://codereview.qt-project.org/q/reviewer:joger.hansegard%2540qt.io
> 
> Cheers,
> Tor Arne
> -- 
> 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] QML Rectangle corner radius API for Qt 6.7

[Lars Knoll via Development]

> On 22 Dec 2023, at 17:48, Giuseppe D'Angelo via Development 
>  wrote:
> 
> Il 22/12/23 17:08, Pierre-Yves Siret ha scritto:
>> I wouldn't want a radii grouped property just because of its name.
>> I much prefer writing topLeftRadius: 10 than radii.topLeft: 10.
>> The pedantic latin syntax doesn't help with the readability. Maybe that's 
>> just because I am not a native English speaker.
> 
> 
> It might be pedantic, but here's an excerpt from the docs:
> 
>> Individual corner **radii** can be set as well (see below).
> 
> 
> Anyhow, something like:
> 
>  borderRadius: { topLeft: 10; bottomRight: 10 }
> 
> (or cornerRadius or whatever) fixes the API issue I was mentioning, it's 
> discoverable, it's "obvious", has minimal impact (1 property on Rectangle 
> instead of 4), and it's also compact to write.

Yes, that’s what I had in mind. 

Naming wise I would vote for borderRadius, simply because that name and its 
behaviour is well known for most developers and designers from CSS. 
cornerRadius could be an alternative (I think Figma uses that name).

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

Re: [Development] QML Rectangle corner radius API for Qt 6.7

[Lars Knoll via Development]

> On 22 Dec 2023, at 13:54, Tor Arne Vestbø via Development 
>  wrote:
> 
>> On 22 Dec 2023, at 13:20, Giuseppe D'Angelo via Development 
>>  wrote:
>> 
>> Il 22/12/23 11:15, André Somers ha scritto:
>>> I can see two options. The simplest option is to have a `radii`
>>> property, which is a grouped property containing the `topLeft`,
>>> `topRight`, `bottomLeft` and `bottomRight` properties as a floating
>>> point value as we have now. I think that would be cleaner than the
>>> current state of things.
>> 
>> While at it, it should be aptly named `cornersRadii` or similar.
>> 
>> `radius` has always violated Qt API guidelines. A rectangle doesn't have a 
>> radius. We shouldn't be doing the same mistake again.
> 
> Radius is a well established term for this in Qt, and other UI frameworks. A 
> key principle in Qt’s API design is familiarity and consistency.

I’m not 100% sure about this. “Radius" without any pre/postfix is IMO somewhat 
confusing on a rectangle. HTML uses “borderRadius”, which I actually like quite 
a bit. And as it’s a new property, it would also not cause conflicts with the 
old name.

Cheers,
Lars

> 
> We can change the `radius` property from a qreal into a group property with 
> left/rigth/top/bottom, similar to anchors. We can detect in the setRadius 
> setter if the incoming argument is a real, and apply that to all of the 
> corners. That would be backwards compatible, and give a more granular API for 
> those that need it.
> 
> Tor Arne 
> 
> -- 
> 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] BC/SC in patch releases

[Lars Knoll via Development]

> On 24 Aug 2023, at 14:30, Giuseppe D'Angelo via Development 
>  wrote:
> 
> On 22/08/2023 23:27, Marc Mutz via Development wrote:
>> We have
>> https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B  
>> for backwards binary compatibility issues and we have
>> https://contribute.qt-project.org/quips/6  for acceptable and
>> unacceptable backwards source compatibility.
>> However, please keep in mind that the Qt project promises that we
>> maintain_forward_  BC and SC within patch releases:
>> https://wiki.qt.io/Qt-Version-Compatibility
> 
> I'm a bit of a broken record here, but does anyone know the reason for having 
> two-way binary compatibility in patch releases?

There were mainly two reasons I remember why we have it:

1. It does in theory allow users to create an application binary that can run 
against different patch level revisions of Qt. I think the idea here was to 
make deployment easier on platforms that have a pre-installed Qt. This is 
mainly Linux distributions. 

2. It forces us to limit the changes made in patch level releases.

Personally, I think both arguments have lost their value over time. 

If you really want to deploy against different versions of Qt, you should 
simply compile your app against the oldest version you are planning to support. 
That should cover case (1) in a better way and is much more in line with 
industry practice. Argument (2) was good 15 years ago when we had rather 
limited coverage by automated tests, but nowadays, this restriction might be 
harming us more than it’s doing any good.

I personally think it’s worthwhile discussing this and maybe modifying/easing 
our policies here to some degree.

Cheers,
Lars

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

Re: [Development] BC/SC in patch releases (particularly enum additions)

[Lars Knoll via Development]

> On 23 Aug 2023, at 11:48, Edward Welbourne via Development 
>  wrote:
> 
> On Tuesday, 22 August 2023 14:27:09 PDT Marc Mutz via Development wrote:
 I think we should decide what we mean by forward BC and SC and
 describe it in https://wiki.qt.io/Qt-Version-Compatibility more
 precisely.
> 
> On 23.08.23 04:48, Thiago Macieira wrote:
>>> I thought the rule was "no new symbols, period" with the exception
>>> for QOperatingSystemVersion for operating systems that have been
>>> released since that Qt release was made.
> 
> Marc Mutz  (23 August 2023 07:52) replied:
>> Indeed. This is how I remember it, too (though the exception is new to
>> me), but that is clearly not what the project is producing atm,
>> therefore I decided to raise this here.
> 
> All of which makes perfectly good sense, but we do have history of
> adding new members to other enums.  The example I'm familiar with - that
> I dimly remember, although one should be wary of trusting my memory and
> I can't find where it happened, asking Lars about when he was Chief
> Maintainer, and continuing at his bidding - is adding members to
> QLocale's Language, Script and (formerly and still technically Country,
> now to be thought of as) Territory enums.

We have been adding new enum values in certain cases. The operating system 
versions needing to be amended to support a new version of macOS is one 
example. That has happened a couple of times within LTS releases as far as I 
remember.

We’ve also once or twice upgraded CLDR or Unicode versions within patch level 
releases to fix serious bugs, and I believe have in that process also added new 
enum values.

> The documentation of these does get "since" annotations (and these will
> reference future versions, if we don't amend them during or after
> picking) that could be the basis for "don't use these overtly in code if
> you care about backwards-and-forwards compatibility" docs (that should
> be added, if we continue doing this).  They only present a problem if
> the client code overtly exercises the new enum members.

Those new enum values only present an issue if they are explicitly used in user 
code. But in that case, I would think that the user is happy to have them 
available. Given the choice between that and a forward compatibility promise 
that allows downgrading I am sure they all prefer having the enum value 
available.

I can honestly not see any real downside of adding those enum values in these 
kind of cases. If you don’t use the value explicitly, you don’t have a problem. 
If you do, you really want it and are happy we made it available.

> 
> To quote (with [minor changes]) the commit message of (trial baloon)
> https://codereview.qt-project.org/c/qt/qtbase/+/498607
> 
>  The counter-case is that client code generally only queries the
>  available locales to ask the user to pick one, then uses it; or reads
>  a locale ID from some source (e.g. HTTP headers) and passes it to
>  QLocale to make sense of it. That [may] exercise newly-added enum
>  members, in which case it will be a behavior change between patch
>  releases (we now support locales we did not before), but the same can
>  arise simply from CLDR adding data for locales we already do have the
>  codes for in our enums. In any case, code doing this will run when
>  compiled and run-time linked against different patch releases, in
>  either direction; and users gain the benefit of the new enum members
>  [and locales] if they update their Qt libraries.
> 
> which I suppose to be the rationale for past post-x.y.0 additions to
> these enums.  This benefit may well be significant for some users and
> authors of client code do have to go out of their way to break it.
> 
> I agree with Marc that we should, at the very least, be clearer about
> what exactly our policy is - and stick to it,

I agree with that, but would propose to amend our policy and explicitly allow 
adding enum values in those limited cases. Updates to Unicode data, supporting 
new OS versions and maybe a few other limited cases come to my mind here.

Cheers,
Lars

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

[Development] Nominating Artem Dyomin as Approver

[Lars Knoll]

Hi all,

I’d like to nominate Artem Dyomin for approver rights in Qt.

Artem has been working with Qt Multimedia since last summer, doing a very good 
job implementing new features, fixing bugs and refactoring code in the module.

You can see his merged changes here: 
https://codereview.qt-project.org/q/owner:artem.dyomin%2540qt.io+is:merged

And his reviews here: 
https://codereview.qt-project.org/q/reviewer:artem.dyomin%2540qt.io

Cheers,
Lars

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

Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer

[Lars Knoll]

+1

He’s been doing that job without the title for years already :)

Cheers,
Lars

> On 4 May 2023, at 12:10, Marc Mutz via Development 
>  wrote:
> 
> Hi,
> 
> I'd like to nominate Eddy as the maintainer for the QLocale and 
> src/corelib/time QtCore subsystems. Eddy is filling that role de-facto 
> already; making it de-jure sounds only logical.
> 
> I asked, and he'd be on board, if we'd have him.
> 
> Anyone else in favour? (I'm not sure I have a vote, actually...)
> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz 
> Principal Software Engineer
> 
> The Qt Company
> Erich-Thilo-Str. 10 12489
> Berlin, Germany
> www.qt.io
> 
> Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
> 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] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[Lars Knoll]

> On 17 Apr 2023, at 18:16, Thiago Macieira  wrote:
> 
> On Monday, 20 March 2023 08:44:30 CDT Edward Welbourne wrote:
>> Thiago Macieira (31 October 2019 22:11) wrote [0]:
>>> This RFC (...) is meant to discuss how we'll deal with locales on Unix
>>> systems on Qt 6. This does not apply to Windows because on Windows we
>>> cannot reasonably be expected to use UTF-8 for the 8-bit encoding.
>> 
>> [0]
>> https://lists.qt-project.org/pipermail/development/2019-October/037791.html
>> 
>> The GNU make mailing list currently has a thread (starts at [1]) about
>> handling of encodings on Windows.
>> 
>> [1] https://lists.gnu.org/archive/html/bug-make/2023-03/msg00066.html
>> 
>> The discussion there seems to indicate that setting the system code-page
>> to UTF-8 can be done in a way that interoperates gracefully with other
>> processes and the file system, presumably thanks to the system being
>> substantially UTF-16-based, so all 8-bit encodings go via that anyway.
> 
> That only works for the file names, not the file contents and other channels. 
> For QProcess, we're slightly fortunate that we have UTF-16 API, so the 
> encoding that the other application uses for its command-line is irrelevant 
> for us.
> 
> But anything that goes through QIODeivce::read or write (QProcess, QFile, 
> Q{Udp,Tcp,Local}Socket) will suffer if there's no agreement on what that 
> encoding is. Usually for sockets, the protocol is binary and obviate the 
> problem. For files, some file formats help. But in particular for 
> communicating 
> with another process, there's no reliable way.

Communicating through a socket will always require that both sides agree on the 
encoding. That’s not really anything new. 

The question is how they encode the data when writing to the socket. If they 
use QTextStream, the data will by default get written in utf8 already today 
(since Qt 6.0). If they explicitly convert the QString to and from a specific 
encoding using QStringConverter/QTextCodec nothing bad will happen neither.

So the remaining problem comes when they use QString::to/fromLocal8Bit(), as 
that might change from some windows locale to utf8. Not a problem when 
communicating with a socket between two Qt apps, but might be an issue when 
storing data in a file or communicating with an app that doesn’t use Qt.

But we could consider that a user error, as you really shouldn’t use local8bit 
for anything else than stdin/out and interfacing with 8bit system APIs.

> 
>> The means to achieve this appear [2] to hinge on setting the active
>> codepage for the application in a manifest file, that it gets combined
>> with after it is linked.
>> 
>> [2]
>> https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-> 
>> code-page
> 
> That was already known at the time, in 2019. What has changed is that the 
> Windows API has matured to the point that this is now a viable choice 
> (previously, it was experimental and known to cause issues). But it's still 
> an 
> application choice; we can't enforce it.

We did enforce it on Unix systems though with Qt 6. I do believe we can over 
time enforce it on windows as well, or at least make it the default.
> 
>> There do appear to be some vagaries still, it may depend on UCRT and I'm
>> not sure I've really understood it all, but it looks like we may, in
>> time, be able to consistently use UTF-8 as 8-bit encoding on Windows.
> 
> Sorry, no, we can't force users to do it because we don't know if their code 
> is safe.
> 
> But I think we should:
> a) do it for our own applications, since we do know our own code
> b) advise users somehow that they should opt-in to this
> c) decide if we want to change from opt-in to opt-out in the medium term (7.0 
>  for example)
> d) decide if we want to enforce it in the long-term
> 
> Option (d) depends on (c). Option (c) informs whether we need a Qt CMake API 
> or whether we can simply say upstream CMake should handle it.

I think this should be the goal, but I’d vote for a slightly faster schedule. 

(a) and (b) are things we should be able to do right now. All our apps work 
fine one Unix systems with a utf8 locale, so there should be relatively few 
problems doing the switch on Windows. The only thing this requires is a bit of 
cake infrastructure work (that I believe has been mostly done already), and 
some documentation for our users.

(c) is something we should also announce with a time schedule right now. I 
would go and do this either for 6.8 or 6.9 (ie with the next LTS release or 
directly afterwards). If we announce it now, it gives our users 1.5 to 2 years 
to adopt (and they can always opt out afterwards).

(d) is something I would do for Qt 7, as that’s the correct time to do those 
changes and clean up our code base

Cheers,
Lars



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

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[Lars Knoll]

Hi,

> On 21 Mar 2023, at 17:46, Alvin Wong via Development 
>  wrote:
> 
> Hi,
> 
> Yes, embedding the manifest with activeCodePage set to UTF-8 is the only 
> thing need to enable UTF-8 as the ANSI code page (ACP) for the process.
> 
> Qt itself should work fine after the bug in QStringConverter had been fixed 
> [1] a while back. (You can also refer to the linked mail thread. [2]) 
> However, as this bug has shown, any code that uses`MultiByteToWideChar` 
> incorrectly or wrongly assumes that `CP_ACP` always refers to a charset in 
> which each characters are formed by no more than two bytes will break. 
> Therefore, before switching to UTF-8 as the ACP, application developers have 
> to check their code and other libraries to make sure everything will still 
> work properly after the switch.
> 
> [1]: https://codereview.qt-project.org/c/qt/qtbase/+/412208
> [2]: https://lists.qt-project.org/pipermail/interest/2022-May/038241.html
> 
> About the CRT, it is true that only UCRT fully supports UTF-8 locale. When 
> compiling with MSVC, you are almost always using UCRT so it should be fine.
> 
> MinGW-w64 is a bit more complicated -- when one gets a mingw-w64 toolchain, 
> the whole toolchain is already configured for a specific CRT. Usually it will 
> be the system MSVCRT. (If it's configured for UCRT, the toolchain author will 
> usually make it clear, because compiled programs will not run out-of-the-box 
> on Windows 8.1 or earlier.) I did not run tests myself, but I would not trust 
> MSVCRT to support UTF-8 ACP fully. mingw-builds [3] and llvm-mingw [4] are 
> some examples of mingw-w64 toolchains that ships UCRT versions.
> 
> [3]: https://github.com/niXman/mingw-builds-binaries/releases
> [4]: https://github.com/mstorsjo/llvm-mingw
> 
> There are two more problems with enabling UTF-8 ACP using the manifest that I 
> have encountered so far. When a process is running with UTF-8 ACP, there 
> seems to be no API available to get the native system ACP. This can be an 
> issue if, for example some external tools write files using the system ACP 
> and your program wants to read those files. The other problem (a mild 
> annoyance) is that, some debuggers which isn't using updated APIs (gdb for 
> example) does not capture `OutputDebugString` messages in the correct 
> encoding, which affects QDebug output.
> 
I’ve looked into that one when we did the work for Qt 6. The console has its 
own code page that can be set independently from the app, and I believe also 
independently from the system code page. qDebug() should be mostly fine, as 
we’re using OutputDebugStringW() internally and let Windows handle this mess.

What it does affect is writing to stdout/err and OutputDebugStringA(). 

> (Console output encoding is separate from the ACP, so one might also need to 
> call `SetConsoleOutputCP(CP_UTF8)`, but the detail is a bit fuzzy to me.)

Setting the code page for console output should help when writing to 
stdout/err. It’ll require a bit of testing again (it’s been a while since I 
looked into it), but I believe console was mostly handling this fine 
independent of the codepage being used by it internally (ie. Windows would 
recode the string).

Cheers,
Lars

> 
> Cheers,
> Alvin
> 
> 
> On 20/3/2023 21:44, Edward Welbourne wrote:
>> Thiago Macieira (31 October 2019 22:11) wrote [0]:
>>> This RFC (...) is meant to discuss how we'll deal with locales on Unix
>>> systems on Qt 6. This does not apply to Windows because on Windows we
>>> cannot reasonably be expected to use UTF-8 for the 8-bit encoding.
>> [0] 
>> https://lists.qt-project.org/pipermail/development/2019-October/037791.html
>> 
>> The GNU make mailing list currently has a thread (starts at [1]) about
>> handling of encodings on Windows.
>> 
>> [1] https://lists.gnu.org/archive/html/bug-make/2023-03/msg00066.html
>> 
>> The discussion there seems to indicate that setting the system code-page
>> to UTF-8 can be done in a way that interoperates gracefully with other
>> processes and the file system, presumably thanks to the system being
>> substantially UTF-16-based, so all 8-bit encodings go via that anyway.
>> 
>> The means to achieve this appear [2] to hinge on setting the active
>> codepage for the application in a manifest file, that it gets combined
>> with after it is linked.
>> 
>> [2] 
>> https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
>> 
>> There do appear to be some vagaries still, it may depend on UCRT and I'm
>> not sure I've really understood it all, but it looks like we may, in
>> time, be able to consistently use UTF-8 as 8-bit encoding on Windows.
>> 
>>  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] Qt Multimedia: proposing behavior change to QAudioSink::resume

[Lars Knoll]

I agree. Let’s change behaviour and move it to active after a call to resume(). 
It also behaves the same in push and pull mode in that case.

Cheers,
Lars

> On 31 Jan 2023, at 13:11, Tor Arne Vestbø via Development 
>  wrote:
> 
> Hi,
> 
> This does indeed look like an oversight, where the behavior was perhaps 
> modeled under the assumption the buffers were empty at the time of suspend().
> 
> I would expect the state to return back to the same state the sink had when 
> calling suspend().
> 
> Cheers,
> Tor Arne
> 
>> On 30 Jan 2023, at 16:38, Volker Hilsheimer via Development 
>>  wrote:
>> 
>> Hi,
>> 
>> 
>> TL;DR: I’d like to change QAudioSink::resume() to always change the sink to 
>> Active state, no matter how the sink was start()’ed.
>> 
>> 
>> QAudioSink provides low-level access to an audio device, allowing 
>> applications to provide PCM data.
>> 
>> The class operates in one of two modes: in pull mode, the application 
>> provides a QIODevice when calling QAudioSink::start(QIODevice *), and the 
>> sink will pull data from that devices as needed. In push mode, the 
>> QAudioSink creates and returns a QIODevice from the other 
>> QAudioSink::start() overload. Applications write PCM data into that device.
>> 
>> The problem is with QAudioSink::resume. The function is documented to 
>> behavior differently depending on how start() was called:
>> 
>> /*!
>>   Resumes processing audio data after a suspend().
>> 
>>   Sets error() to QAudio::NoError.
>>   Sets state() to QAudio::ActiveState if you previously called 
>> start(QIODevice*).
>>   Sets state() to QAudio::IdleState if you previously called start().
>>   emits stateChanged() signal.
>> */
>> 
>> QAudioSink::suspend() behaves the same way in both modes: audio stops 
>> immediately, already buffered data is preserved.
>> 
>> This means that on a sink that has 10 seconds worth of data, calling 
>> suspend() after 1 second, and then resume()’ing changes the state of a 
>> push-mode audio sink to Idle, audio will play for 9 seconds while the sink 
>> reports to be idle, and the sink doesn’t change to “really idle” when all 
>> the audio data has been played.
>> 
>> This means also that applications have no way of knowing when it’s time to 
>> write more data, as an underflow error is never reported - the sink is 
>> already idle, there are no state changes. This is pretty broken IMHO making 
>> the push-style API practically useless if suspend/resume are used. However, 
>> the behavior is documented, and verified in tests.
>> 
>> A sane behavior would be to move the sink to Active after resume (and to 
>> handle buffer under-runs as usual, resulting in Idle state with error).
>> 
>> I’m not sure yet that we can implement the sane behavior on all platforms. 
>> Pull-mode evidently implements it, but I don’t know yet if we can inspect 
>> the amount of data buffered by the underlying audio system. Before we start 
>> investigating that - can anyone think of any particular reason why the 
>> existing behavior is a good idea?
>> 
>> 
>> Volker
>> 
>> -- 
>> 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] Adding CPD support to Qt print dialog

[Lars Knoll]

> On 16 Sep 2022, at 03:36, Chris Adams  wrote:
> 
> Hi Gaurav,
> 
> First, I want to make clear: I know nothing about printing at all,
> either in Qt or in general.
> But I did a quick archive search and found the following:
> https://lists.qt-project.org/pipermail/development/2020-May/039584.html
> 
> On Fri, Sep 16, 2022 at 8:22 AM Gaurav Guleria  wrote:
>> 
>> Hello all,
>> 
>> I am Gaurav Guleria, a GSoC student, working with Till Kamppeter to add
>> and improve Common Print Dialog (CPD) support to existing print dialogs
>> like GTK and Qt. More about CPD can be read here:
>> https://openprinting.github.io/projects/04-print-dialog/.
>> 
>> I wanted to ask about your opinions on the implementation and the way we
>> should proceed with it. I talked with a few people and read this old
>> article here: https://wiki.qt.io/Qt-5-QtPrint, which suggests the Qt
>> team prefers CPD support as a plugin rather than a direct integration
>> into the QPrintDialog.
> 
> I might be misunderstanding his reply, but Lars seemed to suggest that
> he would have preferred CDB-related changes to live inside
> qtbase/src/printsupport rather than an add-on plugin.

That wiki page is somewhat outdated. In the end, it really depends on how the 
integration can be best handled. The goal should be that CPD support is 
transparent to the user of Qt, similar to how the native print or file dialogs 
work on other platforms. 

But the native print dialogs do currently all live inside Qt print support, so 
I don’t see why we shouldn’t add one more. 
> 
>> Just to summarize briefly, implementing CPD support directly in the
>> print dialog would mean that the Qt team wouldn't have to worry about
>> any future CUPS changes, or any other print backends for that matter, as
>> CPD will handle them all instead.

I am unsure whether we can get rid of CUPS and replace it with CPD, or whether 
we will need both side by side (and select the supported one at runtime). 
What’s the status here, are all Linux distributions nowadays supporting CPD? If 
yes, then we can either remove CUPS, or at least turn it into a compile time 
configuration option.
>> 
>> It would be really helpful if you could share your views on this and
>> give your suggestions.
> 
> Whatever path you end up taking, I wish you good luck and a successful 
> project!

Good luck with this, it would be great to see finally have CPD support for Qt.

Cheers,
Lars

> 
> Best regards,
> Chris.
> 
> 
>> Thanks,
>> 
>> Gaurav
>> 
>> ___
>> 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] How to do deprecation

[Lars Knoll]

Hi Eddy,

On 20 Jul 2022, at 16:50, Edward Welbourne 
mailto:edward.welbou...@qt.io>> wrote:

Hi all,

TL;DR: there's a new [[Deprecation]] wiki page, please review.

We noticed recently that some APIs had been wrapped in #if-ery on
QT_DEPRECATED_SINCE(major, minor) without having QT_DEPRECATED or one of
the QT_DEPRECATED_VERSION* macros prepended to the actual declarations
within that #if-ery.  This meant that when you build with
QT_DISABLE_DEPRECATED_BEFORE set to a recent enough version, the
declarations vanished but code that was still using it never got a
deprecation warning from the compiler, no matter how
QT_DEPRECATED_WARNINGS_SINCE was set.  So no-one had been warned to fix
their uses of deprecated API and the code that did so duly broke the
build.  Hopefully we can all agree that this is bad.

Agreed. I think part of the problem is that you currently need to do several 
things to properly deprecate a method.

* You need to wrap the method in QT_DEPRECATED since #ifdefs
* You need to add a QT_DEPRECATED_VERSION_X_maj_min macro before the declaration
* You need to document the method as deprecated using the \deprecated tag

It’s way too easy to make mistakes here. One solution could be to reduce this 
down to one way of deprecating:

QT_DEPRECATED_METHOD(method, major, minor, reason)

So instead of


#if QT_DEPRECATED_SINCE(6, 4)

QT_DEPRECATED_VERSION_X_6_4("Use size() or length() instead.")

inline qsizetype count() const { return d.size; }

#endif


You’d have:

QT_DEPRECATED_METHOD(qsizetype count(), 6, 4, "Use size() or length() 
instead.”)

It should be possible to make this work using some macro magic, so that it’ll 
expand to the right declaration (with or without warning or removed) depending 
on Qt version and the QT_DISABLE_DEPRECATED_BEFORE setting.

Oh, and qdoc should of course pick up those things automatically, so you don’t 
need to add the qdoc tag in the docs :)

Cheers,
Lars



So I went looking for where we document how to do this properly and was
mildly surprised to find no such documentation.  If anyone happens to
know where it's documented, please do let me know.  I managed to find
docs for QT_DISABLE_DEPRECATED_BEFORE, QT_VERSION_CHECK and QDoc's
\deprecated, but none for various other related macros (despite some
search results, leading to pages in which the word DEPRECATED did not
appear) and certainly nothing covering how all the pieces fit together.

So I wrote a wiki page [0] about the process, as I understand it, and
managed to get some others to look it over and point out the more
obvious deficiencies of the first draft.  I think it is now ready for a
wider review and perhaps now would be a good moment for us to discuss
whether the process described (to the best of my ability) there is in
fact fit for purpose and whether there are caveats, restrictions or
further complications that should be documented, or further advice that
should be included there for those contemplating a deprecation.

* [0] https://wiki.qt.io/Deprecation

What I have described is merely what I understand to be current best (or
at least somewhat standard) practice; obviously, if better practice can
be devised, I'd love to know what it is.

In particular, one thing caught my attention when documenting the
defaults - if you predefine QT_DISABLE_DEPRECATED_BEFORE, then it is
used as the default for QT_DEPRECATED_WARNINGS_SINCE, which leads to no
deprecation warnings being given, because all the API that would be
warned about is simply omitted.  So you get compiler errors.  These are
usually less helpful than warnings, at least when the _X_ variants of
various macros are used, with even a half-way helpful message.  So
perhaps we should change the default values here.

When QT_DISABLE_DEPRECATED_BEFORE isn't predefined, it gets defined to
something suitably ancient and QT_DEPRECATED_WARNINGS_SINCE defaults to
the current version.  Perhaps that should remain the default, even when
QT_DISABLE_DEPRECATED_BEFORE is predefined.


I have also added a related section to Fabian's new page [1], covering
its application to deprecations.  Feedback on that page would, no doubt,
be generally appreciated.  Or, of course, you could just improve it
right there in the wiki; same for [[Deprecation]].  It's a wiki.

* [1] https://wiki.qt.io/Merging_breaking_changes_of_internal_API

If anyone feels enthusiastic about making a QUIP of either or both, I'd
be happy to help,

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

[Development] New Chief Maintainer

[Lars Knoll]

Hi everbody,

The voting period for the new Chief Maintainer has ended yesterday. I’m really 
happy to say that we have elected a new Chief Maintainer.

Before getting to the results, I’d like to thank both candidates for stepping 
up and their willingness to take over the role.

The vote ended with 24 votes for Volker and 18 for Allan.

You can see the results of the vote at 
https://governancevoting.qt-project.org/voting and also check there that your 
own vote was registered correctly.

We will also publish a slightly longer blog post on Monday to make the change 
more widely known.


This means Volker Hilsheimer will be our new Chief Maintainer. Congratulations!

Volker, I would like to wish you good luck with leading the project. I know 
that the Qt project is going to be in very good hands with you.

Finally, I’d like to thank you all for supporting me as the (old) Chief 
Maintainer throughout the years. It’s been an honour to lead the Qt Project 
since we established it in 2011.


Cheers,
Lars

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

Re: [Development] Nominating Volker Hilsheimer as maintainer of Qt Speech

[Lars Knoll]

+1.

Lars

> On 13 Jun 2022, at 09:19, Frederik Gladhorn  wrote:
> 
> Hello :)
> 
> I've lately not had time to contribute to Qt (personal life keeping me busy).
> Since Volker and others did a great job porting Qt Speech to Qt 6, they know 
> the code better than me by this time. I'd like to step down as maintainer and 
> allow those who actually contribute to take over.
> 
> Hereby I nominate Volker as maintainer (he's agreed privately already).
> 
> Cheers,
> Frederik
> 
> ___
> 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] Chief Maintainer election

[Lars Knoll]

Hi,

Just a short reminder for all Maintainers:

In case you haven’t voted for a new Chief Maintainer, you can still do so until 
end of Thursday.

Cheers,
Lars

On 2 Jun 2022, at 11:46, Lars Knoll mailto:lars.kn...@qt.io>> 
wrote:

Hi all,

The nomination period for the Qt Chief Maintainer election ended yesterday 
night.

I’m very happy to say that we have two excellent candidates for the position 
with Allan and Volker. Both have been working with Qt for many years and know 
it extremely well. I am certain that whoever of the two will get elected will 
be doing a very good job, so I know already now that Qt will be in very good 
hands moving forward.

But since not all of you might know Volker and Allan very well, I’ve asked them 
to send an email presenting themselves and what they consider important for Qt 
and the role of the Chief Maintainer moving forward. So you will get a bit more 
of an impression from them during the day.

Elections will run from 3rd of June (starting at midnight CEST), until the end 
of the 16th of June (23:59 CEST). Everybody that is part of the Maintainer 
group on Gerrit 
(https://codereview.qt-project.org/admin/groups/a60ed457f6e3833c81023c72743ba73c7e23fb09,members)
 is eligible to cast a vote.

Daniel will follow up with more details on how to cast your vote a bit later 
today.

With that, I’d like to wish both candidates good luck, and am very much looking 
forward to see who will become our new Chief Maintainer.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org<mailto: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] Asking for a FF exception for ICU based QStringConverter

[Lars Knoll]

> On 9 Jun 2022, at 19:16, Alexander Akulich  wrote:
> 
> Hi everyone,
> 
> On Wed, Jun 8, 2022 at 5:18 PM Fabian Kosmale  wrote:
>> 
>> What remains to be done:
>> - There are concerns that mixing Qt versions might lead to an unbounded 
>> memory leak with the current implementation.
> 
> I can't find any precedent but if we *really* want then probably we
> can get the "compiled with" Qt version from QCoreApplication
> (QCoreApplicationPrivate::app_compile_version).
> 
> 1. Allocate the resources only if the version >= 6.4.0
> 2. Probably add a "TODO: remove me" in 6.x.0 (e.g. after the next LTS)

Nice idea. I could live with that solution. Only allocate the new codecs if Qt 
was compiled against 6.4.0 or greater, and if the app was compiled against an 
earlier version, simply return an invalid codec.

Cheers,
Lars

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

Re: [Development] Feature freeze exception for permission API

[Lars Knoll]

I think that’s ok given that its self contained, and something users really 
need on mobile. But as with the other exception, please try to finish it as 
soon as possible.

Cheers,
Lars

On 9 Jun 2022, at 15:01, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:

Hi,

The permission API (https://bugreports.qt.io/browse/QTBUG-90498 / 
https://codereview.qt-project.org/c/qt/qtbase/+/409324) was planned for Qt 6.4, 
but unfortunately did not stabilize enough in time for the freeze.

To avoid pushing the API to 6.5, and to get some user feedback on the both the 
APIs, the implementation, and the use-cases, we’re hoping to make the APIs 
tech-preview/preliminary in 6.4.

The API itself is self-contained and fairly minimal, not affecting other parts 
of Qt, so the risk is low, and if we last minute find issues we can disable it 
entirely via the Qt configure system.

The remaining work to get it into tech-preview/preliminary shape is expected to 
take another week.

Given the above, would it be possible to grant a feature freeze exemption until 
end of next week for this feature?

Cheers,
Tor Arne

___
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] Asking for a FF exception for ICU based QStringConverter

[Lars Knoll]

Given that the change doesn’t interfere with existing functionality, this is 
ok. But please try to finish and get the change merged as soon as possible.

Cheers,
Lars

> On 8 Jun 2022, at 16:17, Fabian Kosmale  wrote:
> 
> Hi,
> 
> unfortunately, we did not manage to get a QStringConverter backend based on 
> ICU into Qt in time for FF
> (https://codereview.qt-project.org/c/qt/qtbase/+/393373). This is a feature 
> strongly requested by KDE as an enabler
> for their KDE Frameworks 6 port [1] and from various users in APAC, where 
> non-UTF codecs like Shift JIS  still have some
> popularity.
> 
> What remains to be done:
> - There are concerns that mixing Qt versions might lead to an unbounded 
> memory leak with the current implementation.
>  I don't think that's actually the case (but if it is, then we need a 
> different enough approach that this most likely has to be
>  deferred to Qt 6.5 at least).
> -  Testing uncovered that there's an issue with writing out replacement 
> characters, causing infinite recursion under certain
>circumstances. That needs to be fixed, but should hopefully be easy by 
> checking and mirroring how ICU's own replacement
>callback works.
> - Thiago (rightfully) requested more test cases; I'm cautiously optimistic 
> that those won't uncover any further issues.
> 
> Impact on other parts of Qt and 6.4 API review
> - The base patch will not introduce any new public API, it just extends what 
> is possible with the existing API.
> - The follow-up patch will introduce one new function; and make use of the 
> new ICU backend in a few places in Qt, which
>   before would have rejected the incoming data.
> 
> Expected additionally needed time:
> I expect that the remaining work can be completed by the end of next week.
> 
> Given the above, would it be possible to grant a feature freeze exemption 
> until end of next week for this feature?
> 
> Regards,
> Fabian
> 
> [1] KDE has to support legacy codecs in e.g. their text editor(s).
> ___
> 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] Chief Maintainer election

[Lars Knoll]

Hi all,

The nomination period for the Qt Chief Maintainer election ended yesterday 
night.

I’m very happy to say that we have two excellent candidates for the position 
with Allan and Volker. Both have been working with Qt for many years and know 
it extremely well. I am certain that whoever of the two will get elected will 
be doing a very good job, so I know already now that Qt will be in very good 
hands moving forward.

But since not all of you might know Volker and Allan very well, I’ve asked them 
to send an email presenting themselves and what they consider important for Qt 
and the role of the Chief Maintainer moving forward. So you will get a bit more 
of an impression from them during the day.

Elections will run from 3rd of June (starting at midnight CEST), until the end 
of the 16th of June (23:59 CEST). Everybody that is part of the Maintainer 
group on Gerrit 
(https://codereview.qt-project.org/admin/groups/a60ed457f6e3833c81023c72743ba73c7e23fb09,members)
 is eligible to cast a vote.

Daniel will follow up with more details on how to cast your vote a bit later 
today.

With that, I’d like to wish both candidates good luck, and am very much looking 
forward to see who will become our new Chief Maintainer.

Cheers,
Lars

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

[Development] New Chief Maintainer - Nomination period ending today

[Lars Knoll]

Hi everybody,

Just a quick update and reminder. 

The nomination period for the Chief Maintainer position ends tonight (at 23:59 
CEST). Please remember that if you choose to nominate someone, that person also 
has to accept the nomination by that time.

My original plan didn’t leave any time between nomination period and start of 
voting. That’s of course somewhat unrealistic. So I hope it’s ok for me to push 
back the voting period by one day to give us a bit of time to prepare the 
voting based on the final set of candidates. 

This means that voting will start on Friday, 3rd of June 2022 at 0:00 CEST and 
end on Thursday the 16th of June 2022 at 23:59 CEST.

Cheers,
Lars

> On 20 May 2022, at 11:07, Lars Knoll  wrote:
> 
> Hi everybody,
> 
> Sorry for being a bit slow to answer, the last days were a bit hectic for me 
> :)
> 
> As I’m for the moment still the Chief Maintainer, I guess it’s also my 
> responsibility to get the nomination and voting process organised.
> 
> I do agree that we will need a full vote of all maintainers, especially if we 
> have more than one candidate.
> 
> So here’s how I propose to handle this:
> 
> * We have a nomination period that I’d like to extend until the 1st of June 
> (before end of the day in CEST). That gives you all 2 weeks since my 
> announcement to nominate candidates. Nominees have to state that they’d be 
> willing to take on the responsibility before that deadline.
> * On Thursday, 2nd of June we will start the voting process using the 
> infrastructure we have created last year. Voting will be anonymous. Voting 
> will be open for 2 weeks and close on the 15th of June (23:59 CEST). As per 
> our QUIP, all maintainers in the Qt Project are allowed a vote.
> 
> I hope everybody can agree with this process.
> 
> Cheers,
> Lars

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

Re: [Development] Leaving The Qt Company

[Lars Knoll]

Hi Samuel,

Thanks! It’s indeed been quite a ride, and I'd like to also thank you for being 
there and all the work you’ve been doing for the community over the years.

Cheers,
Lars

> On 18 May 2022, at 10:51, Samuel Gaist  wrote:
> 
> Hi Lars,
> 
> Thank you for the ride !
> 
> The road has seen some bumps but your teams and you have managed to keep Qt 
> moving forward in interesting ways through all these years.
> 
> It has been a pleasure to work with you on some of my contributions.
> 
> All the best for your new journey !
> 
> Samuel
> 
>> On 18 May 2022, at 10:27, Lars Knoll  wrote:
>> 
>> Hi all,
>> 
>> Let’s take the big news first. I’ve resigned from my position at The Qt 
>> Company. More on that and what it means for the Qt Project further below. 
>> 
>> 
>> But as I’ve spent almost exactly 25 years in the Qt ecosystem, 22 of those 
>> working for the various companies owning Qt, I hope it’s ok if this gets a 
>> bit longer and I spend some paragraphs looking back into history.
>> 
>> As said, it’s been almost exactly 25 years, since I first heard about Qt. At 
>> that time, I read an article in the German C’t computer magazine about a new 
>> Desktop project for Linux called KDE. The underlying technology being used 
>> was Qt. As a person that used Linux extensively during his studies, I 
>> immediately got interested and it didn’t take long until I started my first 
>> steps learning Qt.
>> 
>> As some of you might know I got involved rather deeply about a year or two 
>> later, when I started the KHTML project to create a new HTML engine for KDE 
>> in 1998/1999. That project was later forked by Apple to form the basis for 
>> their WebKit project, the Safari browser and Google’s Chrome browser. It's 
>> cool to think that the browser engine(s) that most people use today started 
>> off as a Qt based project all those years ago.
>> 
>> I remember getting to know some of the people working for Trolltech back 
>> then at KDE conferences. In the winter of 2000, they invited me over to Oslo 
>> to have a look at Qt. The company was at that time still tiny with 11 or 12 
>> employees. I got a great tour of Oslo including the ski jumping tournament 
>> at Holmenkollen and signed up for the job.
>> 
>> I was originally expecting to spend 2-3 years at Trolltech and then at some 
>> point move back to Germany. As you all can see, that’s not how it went 
>> though. I ended up staying in Norway and have been working with and for Qt 
>> ever since.
>> 
>> Starting with Qt 1.0, Trolltech released the source code to Qt (at that time 
>> only for Linux/Unix), and the Open Source nature of Qt played a big part in 
>> its success. I’m very happy that we could continue on that path, by over 
>> time making all platforms Qt supports available as Open Source as well as 
>> moving over to more standard and freer licensing (first GPL, later LGPL).
>> 
>> At the end of the Trolltech years, we started looking into how to make it 
>> easier for the community to contribute to Qt, and first had a model where 
>> our users could submit patches to us. That never really worked very well, 
>> and I’m really happy that we moved over to our current governance model in 
>> 2011. Since then Qt has truly been an Open Source project.
>> When Qt got sold by Nokia in 2012, many people considered it a dead 
>> technology. But I and many of you believed in the technology, and together 
>> we’ve managed to turn this into a great success.
>> 
>> As you all know, Qt is a dual licensed technology. That Qt has the backing 
>> of a commercial business behind it, is what made the required investments 
>> possible to keep the technology competitive. 
>> 
>> I’m extremely proud of what we achieved with Qt over the last 10 years. It 
>> happened because everybody on this list put in a lot of work into making Qt 
>> one of the best development frameworks on this planet. 
>> 
>> Qt is something that I care deeply about. I’ve been with it all the way and 
>> through all the ups and downs from when Trolltech got its first larger 
>> investment to now. But seeing what you all are doing, I know it’s in very 
>> good hands moving forward.
>> 
>> 
>> 
>> Leaving The Qt Company and in the future spending most of my time outside 
>> the Qt ecosystem has been a difficult decision. But in the end, after those 
>> 25 years, it does feel very much like the right decision for me. I want to 
>> try out something else. 
>> 
>> So I will be joining a small Norwegian start

Re: [Development] New Chief Maintainer

[Lars Knoll]

Hi everybody,

Sorry for being a bit slow to answer, the last days were a bit hectic for me :)

As I’m for the moment still the Chief Maintainer, I guess it’s also my 
responsibility to get the nomination and voting process organised.

I do agree that we will need a full vote of all maintainers, especially if we 
have more than one candidate.

So here’s how I propose to handle this:

* We have a nomination period that I’d like to extend until the 1st of June 
(before end of the day in CEST). That gives you all 2 weeks since my 
announcement to nominate candidates. Nominees have to state that they’d be 
willing to take on the responsibility before that deadline.
* On Thursday, 2nd of June we will start the voting process using the 
infrastructure we have created last year. Voting will be anonymous. Voting will 
be open for 2 weeks and close on the 15th of June (23:59 CEST). As per our 
QUIP, all maintainers in the Qt Project are allowed a vote.

I hope everybody can agree with this process.

Cheers,
Lars


> On 20 May 2022, at 09:03, Paul Wicking  wrote:
> 
> Thank you for your invaluable contribution in the role as Chief Maintainer 
> over the years, Lars!
> 
> Regarding the way forward; I agree with André Somers that lazy consensus will 
> not do, the QUIP explicitly requires a vote. I also agree that objecting to a 
> candidate shouldn't require one to also nominate someone else. However, I 
> consider that rather a moot point; the maintainers are to organize a vote, 
> and the QUIP offers no guidelines or instructions in whom can be nominated, 
> that all nominees must be pre-approved, or anything like that. As such, I 
> believe the maintainers can nominate whomever they see fit for the role and 
> then cast their votes accordingly.
> 
> However, I'm not sure I agree with André that the winning candidate requires 
> 50% of the votes, as it is not clear to me what the intention of the QUIP 
> authors was when they used the phrase "simple majority". A simple majority 
> can (and certainly often do) mean relative majority in electoral systems. 
> However, I believe the QUIP offers some leeway for the maintainers to decide 
> on this, as it clearly states they are to arrange a vote. Bikeshedding 
> opportunities galore :)
> 
> In any case, I see one nomination in this thread, of Volker, who accepts the 
> nomination as an honor, and that nomination has even been seconded by another 
> maintainer. There's also a proposed deadline for coming up with further 
> nominations (25th May). So to me, it looks like the maintainers are doing 
> what they are expected to do in accordance with the QUIP.
> 
> Finally, I understand the QUIP such that the vote on the new Chief Maintainer 
> is to be arranged by and voted on by Maintainers only. As such, please 
> consider this the attempt of one approver to offer some guidance for the 
> select group of Maintainers. I would like to congratulate Volker, as well as 
> any possible future nominees, on the nomination for the role. I trust the 
> maintainers will elect a person that will act as a unifying figure within the 
> community in the role of Chief Maintainer.
> 
> Kind regards,
> Paul
> 
> Disclaimer: though employed by The Qt Company, this email is solely in the 
> capacity of being an inividual contributor to the Qt Project and reflects my 
> personal perspective only.
> 
> 
> From: Development  on behalf of André 
> Somers 
> Sent: Friday, May 20, 2022 05:43
> To: Volker Hilsheimer; development@qt-project.org
> Subject: Re: [Development] New Chief Maintainer
> 
> Hi Volker,
> 
> On 19-05-2022 22:42, Volker Hilsheimer wrote:
>>> On 18 May 2022, at 11:23, André Somers  wrote:
>>> 
>>> 
>>> On 18-05-2022 11:19, André Somers wrote:
 As I understand it [1], this needs a formal vote. However, the QUIP
 does not specify a full procedure. I would suggest:
>>> And then I forget the actual link:
>>> 
>>> https://quips-qt-io.herokuapp.com/quip-0002.html#how-to-become-chief-maintainer
>> 
>> Thanks André.
>> 
>> The QUIP asks for a simple-majority vote of all Maintainers. Either way, 
>> let’s see what other nominations we get.
>> 
>> May I propose that until end of Wednesday 25th, Maintainers can nominate 
>> other candidates (including themselves), and then we can have a vote amongst 
>> those candidates nominated (the simple majority is enough as per QUIP). The 
>> QUIP doesn’t explicitly require the candidate to be a Maintainer.
>> 
>> If we have only one candidate by end of Wednesday, then we can use lazy 
>> consensus, i.e. as long as none of the maintainers object to the candidate, 
>> that candidate becomes chief maintainer. Although I’d expect that whoever 
>> has an objection to one candidate also nominates another candidate.
> 
> The procedure outlined in the linked QUIP is substantially different
> from the procedure outlined for becoming a Maintainer. The wording to me
> suggest we need an actual vote in this case, n

[Development] New Chief Maintainer

[Lars Knoll]

Hi all,

As I’ve said in my other email, I am resigning from my position at The Qt 
Company to join a small startup in Norway that is working with things unrelated 
to Qt.

As such, I won’t have too much time to spend with Qt in the future anymore, and 
will resign from my position as the Chief Maintainer because of that.

Qt obviously needs a new Chief Maintainer to take over from me. I’ve had a 
couple of discussions with various people over the last few weeks, and I 
believe I’ve found a great candidate for the job.

I’d like to nominate Volker Hilsheimer as the next Chief Maintainer of Qt.

I believe that the Chief Maintainer should be someone who works full time with 
Qt. He should know the technology, and needs to have the trust of the other 
Maintainers. He needs to understand Qt as an Open Source project and have the 
passion to bring the project forward. I also believe that ideally the person 
should work for and be well connected within The Qt Company. Volker has all of 
those aspects, and I couldn’t think of a better person to take care of the Open 
Governance of Qt going forward.

Cheers,
Lars

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

[Development] Leaving The Qt Company

[Lars Knoll]

Hi all,
Let’s take the big news first. I’ve resigned from my position at The Qt 
Company. More on that and what it means for the Qt Project further below.

But as I’ve spent almost exactly 25 years in the Qt ecosystem, 22 of those 
working for the various companies owning Qt, I hope it’s ok if this gets a bit 
longer and I spend some paragraphs looking back into history.
As said, it’s been almost exactly 25 years, since I first heard about Qt. At 
that time, I read an article in the German C’t computer magazine about a new 
Desktop project for Linux called KDE. The underlying technology being used was 
Qt. As a person that used Linux extensively during his studies, I immediately 
got interested and it didn’t take long until I started my first steps learning 
Qt.
As some of you might know I got involved rather deeply about a year or two 
later, when I started the KHTML project to create a new HTML engine for KDE in 
1998/1999. That project was later forked by Apple to form the basis for their 
WebKit project, the Safari browser and Google’s Chrome browser. It's cool to 
think that the browser engine(s) that most people use today started off as a Qt 
based project all those years ago.
I remember getting to know some of the people working for Trolltech back then 
at KDE conferences. In the winter of 2000, they invited me over to Oslo to have 
a look at Qt. The company was at that time still tiny with 11 or 12 employees. 
I got a great tour of Oslo including the ski jumping tournament at Holmenkollen 
and signed up for the job.
I was originally expecting to spend 2-3 years at Trolltech and then at some 
point move back to Germany. As you all can see, that’s not how it went though. 
I ended up staying in Norway and have been working with and for Qt ever since.
Starting with Qt 1.0, Trolltech released the source code to Qt (at that time 
only for Linux/Unix), and the Open Source nature of Qt played a big part in its 
success. I’m very happy that we could continue on that path, by over time 
making all platforms Qt supports available as Open Source as well as moving 
over to more standard and freer licensing (first GPL, later LGPL).
At the end of the Trolltech years, we started looking into how to make it 
easier for the community to contribute to Qt, and first had a model where our 
users could submit patches to us. That never really worked very well, and I’m 
really happy that we moved over to our current governance model in 2011. Since 
then Qt has truly been an Open Source project.
When Qt got sold by Nokia in 2012, many people considered it a dead technology. 
But I and many of you believed in the technology, and together we’ve managed to 
turn this into a great success.
As you all know, Qt is a dual licensed technology. That Qt has the backing of a 
commercial business behind it, is what made the required investments possible 
to keep the technology competitive.
I’m extremely proud of what we achieved with Qt over the last 10 years. It 
happened because everybody on this list put in a lot of work into making Qt one 
of the best development frameworks on this planet.
Qt is something that I care deeply about. I’ve been with it all the way and 
through all the ups and downs from when Trolltech got its first larger 
investment to now. But seeing what you all are doing, I know it’s in very good 
hands moving forward.

Leaving The Qt Company and in the future spending most of my time outside the 
Qt ecosystem has been a difficult decision. But in the end, after those 25 
years, it does feel very much like the right decision for me. I want to try out 
something else.
So I will be joining a small Norwegian startup with one of the founders of 
Trolltech. While still in Software, it’ll be something rather different, not 
related to C++ or developer tools.

So how do things continue from here?
First of all, I’ll still be working for Qt until my summer vacations at the end 
of June.
After that, I will have significantly less time for Qt, but I certainly won’t 
be completely gone. I will continue to read the Qt project mailing lists and 
maybe come by for events such as the Contributor or World Summit. Also, feel 
free to send me a mail at any time, I’ll try to help where I can.
I will also keep my position as a maintainer for Qt Multimedia. I believe the 
module is now in a decent shape, and I should be able to spend some hours per 
week on it.
But a few hours per week will certainly not be enough to fill the work I’m 
currently doing for Qt. So, I have decided to resign from my position as the 
Chief Maintainer of the Qt project. I’ll send more details around this in a 
separate mail.

I’d like to thank everybody whom I’ve worked with over the years. I’ve made 
many friends in Qt and through Qt. It’s been a fantastic ride and will always 
be grateful for the time I could spend on the technology and with the people 
developing it.
Cheers,
Lars
___
Development mailing list
Dev

Re: [Development] QRect::contains and undocumented(?) edge

[Lars Knoll]

Hi Tomi,

> On 19 Apr 2022, at 21:49, Tomi Pannila  wrote:
> 
> Hi Qt developers,
> 
> could you please explain how your method "QRect::contains(const QRect &r, 
> bool proper)" at
> https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/tools/qrect.cpp?h=dev
> satisfies your API design principles
> 1. Have clear and simple semantics
> 2. Be intuitive
> 3. Be easy to memorize
> 4. Lead to readable code
> from https://wiki.qt.io/API_Design_Principles ?

Short answer: It doesn’t. It’s a very old API from the early days of Qt, and 
wouldn’t be done this way today anymore. At the very least, the boolean 
argument should be replaced by an enum indicating what the mode does. 
rect.contains(otherRect, true) is not understandable without reading 
documentation. rect.contains(otherRect, QRect::IncludeEdges) would be already 
much better.

> 
> More precisely, I'm talking about the edge related stuff, which is not 
> documented properly in Qt documentation. The meaning of an edge is not 
> defined(?).

As we’re dealing with integers, it’s the difference between less and 
less-equal, but I agree it’s not documented all to well.

> What files make use of the edge property?
> Wouldn't it be better to create a separate class for edged rectangles, if 
> rectangles with edges are needed?

No. You don’t want to add a complete new class for one test functions like 
contains(). QRect is being passed into and returned from quite a lot of methods 
in Qt, and you wouldn’t want to have to overload all of those with both a QRect 
and a QInclusiveRect. In addition, you’d duplicate lots of APIs and both 
classes would behave the same for most methods.

> With separate class one could have custom edge sizes as a bonus.

That would be a rect with a border. But where do you stop then? One border 
width for all sizes of configurable for each side independently? In addition, 
you’d need more data to store that information making the class bigger.

So far there hasn’t been a need to have this as a general purpose class in Qt.

> It would also be good if in your documentation you would define 
> mathematically what is meant by a rectangle.
> Something like
> "
> For $x1 < 2$ and $y1 < y2$,
> $$QRect(x1, x2, y1, y2) := \set{ (x, y) \in int^2  \quad |  \quad x1 \le x 
> \le x2 \quad \text{and} \quad y1 \le y \le y2 }$$
> "
> could work together with mathjax, https://www.mathjax.org/ .
> 
> I can guess that x1 x2, with x2 < x1, is "allowed" in QRect due to easier 
> manipulation of QRects in some cases (all ints) (references to such cases?),
> but it flips the left accessor to actually right(?), hence making it 
> illogical. Similarly for y1 and y2. I see the isValid method.
> I mean, one could have "int left, top;" and "unsigned int width, height;" 
> instead of "int x1, x2, y1, y2" to describe QRect.
> 
> 
> 
> Earlier I was browsing qcosmeticstroke.cpp where clip check with a point is 
> multiple times checked(?) with
> "
> const QRect &cl = stroker->clip;
> if (x < cl.x() || x > cl.right() || y < cl.y() || y > cl.bottom())
> return;
> "
> https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/painting/qcosmeticstroker.cpp

Yeah, that could probably use rect.contains(point).
> 
> I was expecting to see this kind of implementation, with negation, in 
> QRect::contains. I was also thinking if performance in rendering
> is so important that a call to QRect::contains cannot be made, and that for 
> some reason QRect::contains cannot be made inline.
> Perhaps there is a way to include an inline implementation of QRect::contains 
> to QRect.h which could be used here?

I doubt that some contains() calls would be preformance critical in that code 
path.
> 
> At
> https://doc-snapshots.qt.io/qt6-dev/qrect.html
> something is mentioned about "historical reasons". No further arguments or 
> links given. Perhaps this is the source of the confusion I have?
> Are these historical reasons permanent or do you plan to move away from these 
> historical reasons? What would go wrong if you abandon the historical reasons?

Historical reasons means this has been the behaviour for the last 25 years, and 
a huge amount of code relies on this behaviour. Changing it would lead to 
subtle breaks in lots of places for our users, breakage that is not easily 
found at compile time. So we don’t want to change it to not break lots of user 
code out there relying on it.

> I'm aware that QRect has been illogical for a long time
> https://www.qtcentre.org/threads/6561-what-are-the-historical-reasons-mentioned-in-the-QRect-class-reference
> 
> 
> 
> I have no commits in Qt. This is my first post to development mailing list.

Welcome then! :)

Cheers,
Lars

> 
> 
> 
> Best Regards,
> Tomi Pannila
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] Requesting repository for Qt Quick 3D Physics

[Lars Knoll]

+1.

Lars

On 14 Mar 2022, at 08:53, Eskil Abrahamsen Blomfeldt 
mailto:eskil.abrahamsen-blomfe...@qt.io>> 
wrote:

Hi,

We are working on an integration of - and API for using - the PhysX physics 
engine with Qt Quick 3D. We would like to request a qt/ repository for 
including this as a supported Qt module in the future.

Name: Qt Quick 3D Physics
Description: Physics engine integration for Qt Quick 3D
Responsible person: Jonas Karlsson
Content: https://git.qt.io/jokarlss/qtquick3dphysics


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

___
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] Requesting approval on https://codereview.qt-project.org/c/qt/qtbase/+/21156

[Lars Knoll]

Done. Maintainer approval based on the +1 from Alexandru :)

> On 10 Mar 2022, at 04:01, Thiago Macieira  wrote:
> 
> It's been 23 days since I last uploaded the patch. There are two +1 votes 
> within 2 days of the upload, but no action since then.
> 
> This is not QtCore, so I don't feel right in maintainer-approving it. So I'm 
> requesting a +2.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel DPG Cloud Engineering
> 
> 
> 
> ___
> 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] Need approvals for "Make sure all private headers include at least one other" changes

[Lars Knoll]

Done.

Lars

> On 8 Mar 2022, at 05:51, Thiago Macieira  wrote:
> 
> https://codereview.qt-project.org/q/Ib056b47dde3341ef9a5213ef677e471674b6
> 
> I'll abandon anything not approved in one week.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel DPG Cloud Engineering
> 
> 
> 
> ___
> 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] Requesting forward BC exception for QtWaylandCompositor in 6.2 and 5.15

[Lars Knoll]

> On 16 Feb 2022, at 18:10, Thiago Macieira  wrote:
> 
> On Tuesday, 15 February 2022 07:54:07 PST Marc Mutz wrote:
>> https://bugreports.qt.io/browse/QTBUG-100845
>> 
>> The QWaylandBufferRef class has a very annoying bug in that its relational
>> operators cannot compare `const` objects (only on the RHS). That's because
>> these operators are implemented as members, but are not const. Since
>> they're not const, they cannot be called with a const LHS...
> 
> By the way, how often is this done? What's the exposure in the real world?

Wayland Compositor is not the most often used module in Qt. I think most users 
are on embedded devices. That also means I wouldn’t be overly concerned about a 
FW BC break in that module. Still it’s good if we can avoid it.
> 
> The pre-6.3 implementation could be #if __cplusplus <= 2020

That could actually be a solution for 6.2. We keep the old API if you compile 
in C++17 mode and only enable the new methods in C++20 mode. Requires a bit of 
work on our side to make sure the symbols are in the libraries as required, but 
otherwise it’s basically about what we expose in the header.

Cheers,
Lars

> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel DPG Cloud Engineering
> 
> 
> 
> ___
> 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] Requesting forward BC exception for QtWaylandCompositor in 6.2 and 5.15

[Lars Knoll]

Hi Marc,

Two questions:

* Is there a work-around for the developers with the current state, e.g. by 
adding some casts?
* Could you add the missing operators inline, so they don’t add new symbols?

Cheers,
Lars

On 15 Feb 2022, at 16:54, Marc Mutz mailto:marc.m...@qt.io>> 
wrote:

Hi,

https://bugreports.qt.io/browse/QTBUG-100845

The QWaylandBufferRef class has a very annoying bug in that its relational 
operators cannot compare `const` objects (only on the RHS). That's because 
these operators are implemented as members, but are not const. Since they're 
not const, they cannot be called with a const LHS...

That's the C++98 picture.

In C++20, the reversed version of these operators is also considered, which 
fixes (const == mutable), but makes mutable OP mutable ambiguous (hard error, 
not a warning).

This makes the operators all but useless in C++20, and awkward to use (swapping 
RHS and LHS, const_cast'ing) before that.

For Qt 6.3+, we can fix this by QT_REMOVED_SINCE the member and adding an 
exported friend op==(const, const): 
https://codereview.qt-project.org/c/qt/qtwayland/+/395784 This is backwards BC. 
For 6.2 and 5.15, forwards BC is required, though (no new symbols, unless 
fixing code that didn't compile before).

The problem now is that even if I make use of the didn't-compile-before 
exception, I still need to add overloads that at least a C++20 compiler would 
use in lieu of reversed signatures, breaking forward BC also for code that, 
without the fix, would have compiled.

Example:

const QWaylandBufferRef lhs; QWaylandBufferRef rhs;
lhs == rhs; // OK in C++20, fails in C++ < 20

The last expression currently calls the reversed member-op==. If I add the 
missing overloads, then it would instead call one of those, one it will not 
find when going back to an older Qt version. I cannot add the missing overloads 
as free unexported functions, because the member operator hides them and 
because at least the const, const overloads need to be out-of-line (const_cast 
is a UB when performed on an object originally declared const), or else we need 
to break the class' encapsulation by making it inline.

So, I'd like to ask for permission to add the full set of {mut, const} × {==, 
!=} × {mut, const} to 6.2 and 5.15 (two are present, so six are missing), and 
then rebasinghttps://codereview.qt-project.org/c/qt/qtwayland/+/395784 onto it 
to replace this hotfix with the real deal. I cannot use QT_REMOVED_SINCE in 
6.2, as it's only available from 6.3.

If, after all this, the answer is that QtWaylandCompositor isn't under BC 
constraints, then at least you have learned how terribly complicated such 
glitches can become.

If you wish to apply your own gray matter to the problem, 
https://codereview.qt-project.org/c/qt/qtwayland/+/395783 contains just the 
test, to be passed in both C++17 and C++20 modes.

Thanks,
Marc


Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
marc.m...@qt.io
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/qt-company.png]
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/facebook.png]
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/twitter.png] 

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/linkedin.png] 

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/youtube.png] 



___
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] XCB platform plugin maintainer change

[Lars Knoll]

+1.

Cheers,
Lars

On 1 Feb 2022, at 10:50, Gatis Paeglis 
mailto:gatis.paeg...@qt.io>> wrote:

Hi all,

I would like to propose a change in Qt's Linux/XCB maintainership.
Since 2019, I have moved full time to the Qt for MCUs project and
there is no time left for XCB work.

/qtbase/src/plugins/platforms/xcb$ git shortlog --since=2021 --no-merges -s -n .

11  Liang Qi
 6  Tor Arne Vestbø
 3  Gatis Paeglis

I would like to propose Liang Qi as the new maintainer. He has been
with the company for more than a decade.

Gatis Paeglis.
___
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] Proposing to officially allow C++20 types in Qt 6 ABIs

[Lars Knoll]

> On 28 Jan 2022, at 02:07, Thiago Macieira  wrote:
> 
> On Thursday, 27 January 2022 16:49:22 PST Marc Mutz wrote:
>> That would break projects that build their Qt themselves (embedded), and
>> with C++17 (because, you know, compile times increase with every std
>> version 🙂).
> 
> Ok, then we make it optional to turn back the clock and compile as C++17. But 
> we default to C++20. This option would be as ABI-breaking as the feature 
> system or choosing qreal == float. 

I’d be fine with that given that we have good enough C++20 support on the 
desktop and mobile platforms. We upgrade the default to C++20, but keep things 
compiling in C++17 mode. If we do that, we should however consider upgrading 
our minimum compiler requirements for the binaries (ie desktop and mobile 
platforms) to compilers that support C++20. In addition, we’ll need to add 
testing of C++17 builds in CI.

The last question is whether we would do that switch for 6.4 or 6.5.

Cheers,
Lars



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

Re: [Development] Nominating Volker Hilsheimer as co-maintainer of Qt Widgets

[Lars Knoll]

+1!

Cheers,
Lars

> On 25 Jan 2022, at 09:46, Fabian Kosmale  wrote:
> 
> +1
> 
> Volker has been doing a great job fixing issues, stabilizing tests and 
> improving the unit test coverage in the Widgets module
> 
> 
> Von: Development  im Auftrag von Richard 
> Gustavsen 
> Gesendet: Dienstag, 25. Januar 2022 09:38
> An: Qt development mailing list
> Betreff: [Development] Nominating Volker Hilsheimer as co-maintainer of Qt 
> Widgets
> 
> Hi all!
> 
> I would like to propose a change in the maintenance of Qt Widgets [1]. I’m 
> the current maintainer of the module, but I’m happy to inform you that Volker 
> Hilsheimer has agreed to join me as a co-maintainer. Volker is one of the 
> biggest contributors to Widgets [2], and has been helping out maintaining the 
> module for a long time already. So let’s make it formal as well!
> 
> [1] https://wiki.qt.io/Maintainers#Qt_Maintainers
> [2] 
> https://codereview.qt-project.org/q/owner:volker.hilsheimer%2540qt.io+repo:qt/qtbase+status:merged
> 
> Best Regards,
> Richard Moe Gustavsen
> Principal Engineer
> The Qt Company
> Oslo, Norway
> 
> ___
> 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] Nominating Dimitrios "Jimis" Apostolou as Approver

[Lars Knoll]

+1.

Lars

On 20 Jan 2022, at 07:31, Jukka Jokiniva 
mailto:jukka.jokin...@qt.io>> wrote:

+1 from me too

--Jukka

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Oliver Eftevaag 
mailto:oliver.eftev...@qt.io>>
Date: Wednesday, 19. January 2022 at 16.01
To: Mårten Nordheim mailto:marten.nordh...@qt.io>>, 
Volker Hilsheimer mailto:volker.hilshei...@qt.io>>, 
development@qt-project.org 
mailto:development@qt-project.org>>
Subject: Re: [Development] Nominating Dimitrios "Jimis" Apostolou as Approver
+1 🙂

Oliver Eftevaag
Software Engineer
Graphics and UI


The Qt Company
Sandakerveien 116
0484, Oslo, Norway


oliver.eftev...@qt.io
+4746446690


http://qt.io


From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Mårten Nordheim 
mailto:marten.nordh...@qt.io>>
Sent: Wednesday, January 19, 2022 2:52 PM
To: Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>>; 
development@qt-project.org 
mailto:development@qt-project.org>>
Subject: Re: [Development] Nominating Dimitrios "Jimis" Apostolou as Approver

+1 for sure

Mårten


From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>>
Sent: Wednesday, January 19, 2022 12:59
To: development@qt-project.org
Subject: [Development] Nominating Dimitrios "Jimis" Apostolou as Approver

Hi,

I’d like to nominate Dimitrios Apostolou, aka Jimis, as approver in the Qt 
Project.

Jimis has been working as a Software Engineer in the Qt Company since 2019 and 
has made a number of contributions [0] and reviews [1]. Most of his work 
happens in the build and test machinery and the infrastructure around it, which 
doesn’t leave a lot of traces in gerrit. I appreciate Jimis as a passionate, 
knowledgable, and open minded software developer and systems engineer, and I 
trust that he’ll use the approver status responsibly.

Disclaimer: Jimis reports to me in The Qt Company.


Volker


[0] - https://codereview.qt-project.org/q/owner:jimis%2540qt.io
[1] - https://codereview.qt-project.org/q/reviewedby:jimis%2540qt.io

___
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] Updating x86 SIMD support in Qt

[Lars Knoll]

Hi Thiago,

I’m absolutely in favour of upping the SIMD support in Qt. Compilers support 
everything we need, and we should make better use of that.

The main thing I’m wondering about is how much performance we gain by from a 
multi arch build Qt for different x86_64 architectures opposed to building 
maybe for v2 and detecting/using AVX and AVX512 at runtime. I would assume it’s 
little we gain, as there are very few places where the compilers 
auto-vectorizer will be able to emit AVX instructions, but I might be wrong 
here.

AVX is only used by a couple of classes in Qt Core and the drawhelper in Qt 
Gui. Qt Gui already does runtime detection, so it would be only about adding 
that to the methods in Qt Core. 

Couple more comments inline below.

> On 19 Jan 2022, at 04:01, Thiago Macieira  wrote:
> 
> For Qt 6.4, I'd like to propose we change the way we detect and enable SIMD 
> support. TL;DR:
> 
> * Assume all compilers support 5-year-old stuff
> * Up the minimum CPU for Linux, Window and macOS/x86
> * Fix macOS Universal builds to use the minimum
> * Add an option to cmake to choose a minimum matching one of the Linux x86-64 
>   ABI revisions
>   * Make it easy to build QtCore, QtGui ad Qt3D multi-arch on Linux
> 
> Long version:
> 
> 1) assume all compilers support what we need
> 
> Our current tests for compiler support go all the way back to SSE2, which is 
> mandatory on x96-64. While testing some changes, I've confirmed that all 
> compilers in the CI support x86 CPU features matching the Intel Cannon Lake 
> architecture, which is more than we need, except for the QCC compiler missing 
> one intrinsic that we can workaround.
> 
> I've also found that macOS universal builds, WASM, Android and maybe some 
> more 
> are improperly detecting support. Specifically for universal builds, what we 
> detect depends on the order in which you specify the architectures. This is 
> buggy at a minimum, surprising at best.
> 
> I propose we remove the tests for the intrinsics of each individual CPU 
> feature. Instead, let's just assume they all have everything up to 2016. This 
> will shorten cmake time a little and fix the macOS universal builds. It'll 
> also change how 32-bit non-SSE2 builds are selected (see below).
> 
> The change https://codereview.qt-project.org/c/qt/qtbase/+/386738 is going in 
> this direction but retains a test (all or nothing). I'm proposing now we 
> remove the test completely and just assume.

I’m fine with that, I don’t think we need to support a compiler that doesn’t 
support those. 

Can we at the same time do the same thing for NEON btw. While there are some 
platforms that don’t support NEON, I believe all compilers do support them.

> Question:
> - the QT_COMPILER_SUPPORTS_xxx macros are in qconfig.h (public config). Do we 
>  keep compatibility? We can easily just move them to qprocessordetection.

These are also to some extent used to differentiate between SSE and NEON. I 
think we can hardcode those in qprocessordetection for source compatibility.
> 
> 2) add options to select the target architecture revision
> 
> Linux established 3 new revisions of the architecture:
> * x86-64 v1 (baseline): SSE2 support
> * x86-64 v2: baseline + SSE3, SSSE3, SSE 4
> * x86-64 v3: v2 + AVX + AVX2 + FMA + BMI + F16C
> * x86-64 v4: v3 + AVX512F + BW + DQ + VL + ER
> 
> For i386, we can consider a "v0" of the non-SSE2 original baseline from the 
> 1980s.

Fine for me. I don’t really care that much about i386, as it’s quickly dying 
out and we’re not providing any binaries for it anymore.
> 
> I propose adding a CMake option to make it easy to opt in to one of those. 
> Yes, you can just set CMAKE_C(XX)FLAGS_{RELEASE,DEBUG,RELWITHDEBINFO}, so 
> this  
> part would be convenience.
> 
> For the default, see #4.
> 
> 3) add a way to have multi-arch glibc-based Linux builds
> 
> The revisions also match subdirectory searches by the Linux dynamic linker. 
> The subdirectories"x86-64-v2", "x86-64-v3" and "x86-64-v4" are new in glibc 
> 2.33, but glibc has supported "haswell" (for v3) and "avx512_1" (for v4) for 
> a 
> number of years prior to that.
> 
> The proposal is to allow the user to specify more than one architecture in 
> the 
> list above. We can query the dynamic linker to find out if it supports the 
> new 
> names and, if not, use the old ones.
> 
> For example, if I specified QT_X86_SUBARCH="v2;v3;v4", it would compile 
> QtCore 
> three times. The build products would be:
>  lib/libQt6Core.so.6.4.0
>  lib/haswell/libQt6Core.so.6.4.0  OR
>   lib/glibc-hwcaps/x86-64-v3/libQt6Core.so.6.4.0
>  lib/haswell/avx512_1/libQt6Core.so.6.4.0 OR
>   lib/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.4.0
> with their matching symlinks.
> 
> This would apply to only a few select libraries. I'm thinking QtCore, QtGui, 
> QtQml and some of the Qt3D libraries.
> 
> I don't currently see a need to do this for any plugins and there is no 
> standardised way to name them anyway.
> 
> This w

Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat

[Lars Knoll]

Another +1. 

Thanks for stepping up, Sona!

Cheers,
Lars

> On 18 Jan 2022, at 16:36, Mårten Nordheim  wrote:
> 
> +1 from me as well
> 
> 
> From: Development  on behalf of Cristián 
> Maureira-Fredes 
> Sent: Tuesday, January 18, 2022 15:10
> To: development
> Subject: [Development] Nominating Sona Kurazyan as maintainer of qt5compat
> 
> Hello,
> 
> I would like to nominate Sona as maintainer [1]
> for the qt5compat module, which at the moment doesn't
> have one. Even if it's a special module we have around
> only for Qt6, we need a responsible person in charge of it.
> 
> She has been working mainly in qtbase in the last years
> and took care of many tasks when the module was created [2].
> 
> Due to her contributions in qtbase and other modules [3],
> I firmly believe she will manage to maintain it.
> 
> Cheers
> 
> 
> [1] https://wiki.qt.io/Maintainers#Qt_Maintainers
> [2]
> https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+repo:qt/qt5compat+status:merged
> [3]
> https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+status:merged
> 
> --
> Dr. Cristián Maureira-Fredes
> R&D Manager
> 
> The Qt Company GmbH
> Erich-Thilo-Str. 10
> D-12489 Berlin
> 
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Jouni Lintunen
> 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

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

Re: [Development] Qt Compilation Speed

[Lars Knoll]

> On 3 Jan 2022, at 16:10, Sérgio Martins  wrote:
> 
> On 2022-01-03 13:40, Lars Knoll wrote:
>> (...)
>> One other possible solution to improve compile times is the hack we
>> used 15 years ago in KDE, where we grouped many .cpp files into one
>> compilation unit. There’s however a balance needed here, as it reduces
>> the efficiency of -j, but maybe compiling 4-8 .cpp files as one unit
>> could help.
> 
> Hello Lars,
> 
> "unity builds" were added to CMake by Christian Adam, you should read your 
> company blog :D
> It seems to adjust the size of the amalgamations so all your CPU cores are 
> still used.

Nice. Looks like I missed that one :)
> 
> The results are astonishing, clazy builds almost 100% faster. However, clazy 
> does use a lot of LLVM headers, which are
> known to be slow to compile. So your mileage will vary.
> 
> It does make incremental builds slower, as then you need to recompile the 
> entire amalgamation. For this reason I don't think
> it's a silver bullet.

It’s not. It’s a kludge. It can help you get your dependencies compiled faster, 
but it’s usually not very helpful for the code you’re actively working on. And 
as Thiago pointed out, it comes with its own share of issues.

Cheers,
Lars

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

Re: [Development] Qt Compilation Speed

[Lars Knoll]

On 3 Jan 2022, at 14:21, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

On Monday, 3 January 2022 05:43:53 -03 Marc Mutz wrote:
Hi,

The Qt Creator folks have noted that compilation of Qt projects against Qt
6.2 is sometimes almost twice as slow as it was in 5.15:
https://bugreports.qt.io/browse/QTBUG-97601

While we have some ideas where this may come from (including more std
headers, qmetatype compile-time typename construction, qglobal.h becoming
larger and larger), most of these should be fixed by PCH, yet PCH builds
are also slower.

Compile times to matter, as they directly impact the productivity of all of us 
and of our users. So if we can find ways to reduce them, that’s probably a 
worthwhile effort.

The change to C++17 makes a huge difference too, regardless of PCH. That
#include  in qglobal.h adds up to 300 ms in each build without PCH,
and a considerable amount with it too. And it gets worse with C++20 and
ranges.

I don't know what Qt Creator used as C++ standard before 6.x, so this might be
stale information.

We can't fix this, if it s the issue. The C++ standard is cramming more stuff
in , not new headers, so it's not a QoI either.

This sucks, but I also don’t see an easy way to avoid most of those headers. 
I’ve played around a bit to see what we could gain by forward declaring (yes, I 
know it’s UB according to the C++ standard…) std types, but didn’t really get 
very far, but I also only spent an hour or two on it.

qglobal.h does however have quite a few legacy includes at the end that should 
not really be there. Some of those include quite a set of std headers. I wonder 
whether removing those and explicitly adding them where required would help.

I also wonder if we can avoid . It’s only used in very few public 
headers in QtCore, and we might be able to move those usages into the 
implementation.

One other possible solution to improve compile times is the hack we used 15 
years ago in KDE, where we grouped many .cpp files into one compilation unit. 
There’s however a balance needed here, as it reduces the efficiency of -j, but 
maybe compiling 4-8 .cpp files as one unit could help.

Cheers,
Lars


The questions that we face now are a) do we care and b) if we do, then what
metrics should we use to define success?

Clang has a mode to tell you how much time it's spending on each phase. If the
issue is headers, we can find unnecessary ones and remove them easily, with an
automated too.

Splitting headers to make for shorter builds I'd say we can only do for a few
headers. Find the biggest offenders in corelib and try to see what we can do.
Some minor source compat breakage due to indirect inclusions getting removed
is acceptable. But it's not something that can easily be done for a great deal
many more headers: it would likely be more effort than it's worth the outcome.

And remove #include  in qglobal.h, if we can. Maybe add a #define
that skips including it and possibly disables some other functionality that
you'd have to #include yourself. QGLOBAL_LEAN_AND_MEAN?

--
Thiago Macieira - thiago.macieira (AT) intel.com
 Software Architect - Intel DPG Cloud Engineering



___
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] Feature freeze exception for QML type compiler

[Lars Knoll]

I guess qtdeclarative already has one exception, so this would make it two.

The exception is fine for me, as this shouldn’t effect anything outside of 
qtdeclarative. But please to to get it finished this week.

Cheers,
Lars

On 13 Dec 2021, at 11:37, Andrei Golubev 
mailto:andrei.golu...@qt.io>> wrote:

Hi,

I would like to request a feature freeze exception for adding important
implementation bits of the QML type compiler (QTBUG-84368) planned to be
introduced to public in 6.3.

This compiler exists as a tool in qtdeclarative repository already, with a small
subset of tests and functionality. It is meant as a Tech Preview, focusing on
early adopters to collect the initial feedback on the new QML compilation
process that we plan to further enhance in future releases. The QML type
compiler (qmltc for short) basically translates QML type structure to C++ code.

Note that *unlike* qmlcachegen, qmltc is an "opt-in" component (users must
explicitly ask - through CMake - for their code to be compiled with qmltc and 
then
also address QML creation differences on the C++ side).

As already mentioned, most of the foundational work is done at that point, but
we lack wider code generation capabilities, enhanced tests and some CMake API
refinements. All of that is covered by
https://codereview.qt-project.org/c/qt/qtdeclarative/+/334369.

The expected impact on the Qt release is as follows:
- slight impact on public CMake API: the function to invoke qmltc is by far
  separated from the rest of the CMake API bits (so e.g. qt_add_qml_module() is
  unaffected)
- no impact on public C++ or QML API (we have merged all the necessary changes
  already and do not expect any new findings)
- slight impact on building: qmltc tests invoke the compiler during build time
  (that has been the case for a while now in fact), as long as the tests are
  built successfully, no additional issues are expected (nothing else uses qmltc
  in Qt so far)
- no impact on translatable strings
- some impact on documentation (which needs to be added)

The ETA is within this week. The patch should've been in merge-able state on
Friday already but we have encountered some CMake-related issues at the last
moment. These issues are now fixed and I'm waiting for a precheck build results.

The alternative to feature freeze would be to postpone the qmltc release to 6.4.
We would like to avoid this to be able to collect more user feedback within the
Tech Preview stage.

Best Regards,
Andrei

___
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] QtMultimedia FM radio and plugin support in Qt6

[Lars Knoll]

Hi Alberto,

> On 12 Dec 2021, at 08:03, Alberto Mardegan  
> wrote:
> 
> Hi all!
>  When the new QtMultimedia was announced [1], there was a mention that
> the Radio API was being removed (by the way, there is no mention of this
> removal in the migration document [2]). Did it happen because of a lack
> of time, or were there other reasons? Is it going to come back?

It wasn’t mentioned because the API was not implemented in any of the backends 
we provided, ie. it was non-functional for regular Qt packages.
> 
> I also would like to resurrect the topic of loadable plugins for the
> backends. While in Ubuntu Touch we don't have plans to migrate to Qt6
> any time soon, this is definitely going to happen sooner or later, and
> our backend is not supported. So the obvious question is how we will
> have to proceed: would the Qt project accept the contribution of an
> additional backend, are there any chances of getting the plugin API
> back, or should we maintain an out-of-tree mega patch for our backend?

We could consider having one plugin for all of Qt MM. But I certainly do not 
want to go back to what we had in Qt 5, namely one plugin per functionality 
group, as that makes things extremely messy to implement.

I would be fine with an additional backend maintained inside Qt MM, but it also 
depends a bit on what you prefer. Btw, how is your backend different from what 
we have in Qt 5.15?
> 
> The latter option, while the simplest for the Qt Project, would be
> rather hard for us to work with.

I agree. A fork or a mega patch is the least desirable option. So let’s focus 
on the other two possibilities. Either a plugin infrastructure or working 
inside Qt project.

One thing I can say already now is that I do not want to go back to Qt 5 times 
and make the backend API public. We will need the freedom to change the API 
between versions where required. 

> I wonder, therefore, if it would be
> possible to have a compromise, that is that the plugin support gets
> re-introduced as a build option, as if it was a backend on its own like
> the Linux, Android, Windows etc. ones.  Or if it was somehow delivered
> as a private API with no promise of stability, that would also do it.

It is already available as private API, and there’s a hook to load a different 
backend in 6.2. Have a look at
QPlatformMediaIntegration::setIntegration(). We’re using it to test the 
frontend API with a dummy backend. 

So you should be able to do most things today, but you’d need a global 
constructor functions that sets up the integration somewhere.

Cheers,
Lars

> 
> Ciao,
>  Alberto
> 
> [1]: https://lists.qt-project.org/pipermail/development/2021-May/041458.html
> [2]: https://doc.qt.io/QT-6/qtmultimedia-changes-qt6.html
> 
> -- 
> http://www.mardy.it - Geek in un lingua international
> ___
> 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] Feature freeze exception for QML Language Server

[Lars Knoll]

Ok, let’s try to add the module in the regular way first. That’s IMO preferable 
over using a submodule in declarative. 

Lars



> On 10 Dec 2021, at 19:56, Jani Heikkinen  wrote:
> 
> Hi! 
> 
> From packaging point of view it would be of course easiest if it will be part 
> of declarative; in that case it wouldn't need any actions from packaging 
> side. But on the other hand it isn't that big issue to add it as a new module 
> either if the module self is ok shape and wouldn't cause integration issues 
> later on. 
> 
> br,
> Jani
> 
>> -Original Message-
>> From: Fabian Kosmale 
>> Sent: perjantai 10. joulukuuta 2021 10.47
>> To: Lars Knoll 
>> Cc: Qt development mailing list ; Jani
>> Heikkinen 
>> Subject: AW: [Development] Feature freeze exception for QML Language
>> Server
>> 
>> Hi,
>> 
>> the qtlanguageserver repository adds no tools. It currently doesn't expose
>> any public API at all. The private API consists of two blocks:
>> - jsonrpc, an implementation of the JSONRPC protocol
>> - languageserver, a generic framework for writing a languageserver
>> 
>> As there is no public API, and currently only a single user, we might instead
>> add it as a 3rdparty module in declarative only used by the tool, if that 
>> would
>> make things easier.
>> 
>> Regards,
>> Fabian
>> 
>> 
>> Von: Lars Knoll 
>> Gesendet: Freitag, 10. Dezember 2021 09:36
>> An: Fabian Kosmale
>> Cc: Qt development mailing list; Jani Heikkinen
>> Betreff: Re: [Development] Feature freeze exception for QML Language
>> Server
>> 
>> As far as I can see, qtlanguageserver is not currently being packaged or part
>> of the release. So we'd need to be adding that module in addition to the
>> feature freeze exception for declarative.
>> 
>> Jani, what do you think? Would you expect any problems/delays adding the
>> qtlanguageserver repository (if it's not already there)?
>> 
>> Fabian, what kind of APIs/tools does the qtlanguageserver repository add?
>> It's coming rather late and should have really been added earlier.
>> 
>> I have relatively few concerns about an exception for the QML language
>> server code in qtdeclarative, as nothing depends upon it. So it mainly comes
>> down to what the impact of adding the new repository will be.
>> 
>> Cheers,
>> Lars
>> 
>>>> On 9 Dec 2021, at 15:51, Fabian Kosmale  wrote:
>>> 
>>> Hi,
>>> 
>>> I'd like to request a feature freeze exception for adding an initial
>>> version of a QML language server (QTBUG-98759).
>>> 
>>> It is meant to exist as a tool in the qtdeclarative repository,
>>> depending on the library in the new Qt Language Server repository
>>> (https://codereview.qt-project.org/admin/repos/qt/qtlanguageserver).
>>> It is meant to be released as a Tech Preview. It's initial focus will
>>> be on exposing the warnings from the semantic analyis which also powers
>> qmllint.
>>> 
>>> While the necessary foundational work in the language server
>>> repository and in qtdeclarative has been done, the actual tool which
>>> integrates everything is still in a somewhat rough shape
>>> (https://codereview.qt-project.org/c/qt/qtdeclarative/+/384271).
>>> 
>>> The expected impact on the Qt release is as follows:
>>> - no impact on public API
>>> - slight impact on building (qtdeclarative would need to be build
>>> after the  Qt LSP repository, as that would become an optional
>>> dependency)
>>> - no (expected) impact on private library API; the existing one in
>>> declarative  should be enough to cover the current needs of the server
>>> - no impact on tranlsatable strings
>>> - some impact on documentation (which needs to be added)
>>> 
>>> I expect the remaining work to be finalized by the end of next week.
>>> 
>>> The alternative to a feature freeze extension would be to release the
>>> LSP server as a stand-alone tool linking against private Qt API. We
>>> would however like to release it as part of the Qt release itself, to
>>> simplify both packaging for us and installing for our users.
>>> 
>>> Regards,
>>> Fabian
>>> ___
>>> 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] Feature freeze exception for QML Language Server

[Lars Knoll]

As far as I can see, qtlanguageserver is not currently being packaged or part 
of the release. So we’d need to be adding that module in addition to the 
feature freeze exception for declarative.

Jani, what do you think? Would you expect any problems/delays adding the 
qtlanguageserver repository (if it’s not already there)?

Fabian, what kind of APIs/tools does the qtlanguageserver repository add? It’s 
coming rather late and should have really been added earlier.

I have relatively few concerns about an exception for the QML language server 
code in qtdeclarative, as nothing depends upon it. So it mainly comes down to 
what the impact of adding the new repository will be.

Cheers,
Lars

> On 9 Dec 2021, at 15:51, Fabian Kosmale  wrote:
> 
> Hi,
> 
> I'd like to request a feature freeze exception for adding an initial version 
> of
> a QML language server (QTBUG-98759).
> 
> It is meant to exist as a tool in the qtdeclarative repository, depending on 
> the
> library in the new Qt Language Server repository
> (https://codereview.qt-project.org/admin/repos/qt/qtlanguageserver). It is 
> meant
> to be released as a Tech Preview. It's initial focus will be on exposing the
> warnings from the semantic analyis which also powers qmllint.
> 
> While the necessary foundational work in the language server repository and in
> qtdeclarative has been done, the actual tool which integrates everything is
> still in a somewhat rough shape
> (https://codereview.qt-project.org/c/qt/qtdeclarative/+/384271).
> 
> The expected impact on the Qt release is as follows:
> - no impact on public API
> - slight impact on building (qtdeclarative would need to be build after the
>  Qt LSP repository, as that would become an optional dependency)
> - no (expected) impact on private library API; the existing one in declarative
>  should be enough to cover the current needs of the server
> - no impact on tranlsatable strings
> - some impact on documentation (which needs to be added)
> 
> I expect the remaining work to be finalized by the end of next week.
> 
> The alternative to a feature freeze extension would be to release the LSP 
> server
> as a stand-alone tool linking against private Qt API. We would however like to
> release it as part of the Qt release itself, to simplify both packaging for us
> and installing for our users.
> 
> Regards,
> Fabian
> ___
> 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] Feature freeze exception for QTBUG-98545

[Lars Knoll]

> On 9 Dec 2021, at 09:57, Alexandru Croitor  wrote:
> 
> 
>> On 9. Dec 2021, at 08:53, Lars Knoll  wrote:
>> 
>> I’m always a bit worried about build system changes in stable branches. Does 
>> this in any way interfere with or change how Qt itself is being build and 
>> packaged?
> 
> It shouldn't, it's extra API to be used by user projects, the Qt build itself 
> does not use this API.
> 
Thanks. Given that and Ulf’s added explanations, the exception is ok.

Cheers,
Lars

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

Re: [Development] Feature freeze exception for QTBUG-98545

[Lars Knoll]

I’m always a bit worried about build system changes in stable branches. Does 
this in any way interfere with or change how Qt itself is being build and 
packaged?

Cheers,
Lars

> On 7 Dec 2021, at 12:21, Alexandru Croitor  wrote:
> 
> Hi,
> 
> I'd like to request a feature freeze exception for adding the new CMake 
> deployment API in Qt 6.3.
> 
> It covers deployment of applications that use Qt and QML modules targeting 
> Windows and macOS, with further platform support added in later Qt versions 
> (Linux and cross-compilation if/when possible).
> 
> The CMake API is meant to be Technical Preview in 6.3.
> 
> JIRA task https://bugreports.qt.io/browse/QTBUG-98545
> 
> The work is mostly done, but there are still a few things we need to iron out 
> before we can merge the changes and thus might slip the deadline.
> 
> The ongoing work can be found in these 2 Gerrit chains:
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/383732/9
> https://codereview.qt-project.org/c/qt/qtdeclarative/+/383833
> 
> Regards,
> Alexandru.
> ___
> 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 Governance: Vote of no confidence

[Lars Knoll]

As the vote was not contested during the last two weeks, the change in approver 
rights has now been implemented.

The voting results will be deleted in another 14 days from now (2 weeks after 
the final decision), as stated in the proposal for the voting procedure.

Best regards,
Lars

On 29 Oct 2021, at 09:53, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:

Hi all,

The vote has been closed on Tuesday night. 33 Approvers voted, 24 in favour of 
the no confidence vote, 9 against. This means that the no-confidence vote 
passed the required quorum of 2/3 of the votes as defined in QUIP-2.

The detailed voting results by moniker are listed at the end of the email 
again, so people can verify that their own vote got counted correctly.

This result means that the Qt Project doesn’t have confidence in Ossi as an 
Approver and we will therefore remove his general Approver rights. According to 
the voting procedure outlined in the thread starting at 
https://lists.qt-project.org/pipermail/development/2021-October/041833.html 
there is a 14 days period for possible objections, so the change in Approver 
rights will be implemented once that period has passed.

It’s also important to note that Ossi is the Maintainer of qttranslations. He 
will keep the Maintainer and Approver rights for this module, as we have lots 
of precedence where individuals are Maintainers for a specific module without 
having Approver rights for the Qt Project as a whole.

Best regards,
Lars


pale-comparison false
tangy-help  true
subsequent-frametrue
puny-expansion  true
permissible-hammer  true
elastic-needle  true
near-fanfalse
peaceful-look   false
ugliest-reactiontrue
assorted-plot   true
yummy-heart true
frequent-value  true
strange-owner   true
doubtful-flesh  true
dramatic-power  true
humorous-frogs  true
male-bells  true
military-bead   true
dispensable-experience  true
profuse-deertrue
swift-magic true
drab-patch  false
knowing-deerfalse
cheerful-bridge true
petite-rifletrue
energetic-umbrella  true
gifted-volleyball   true
sudden-porter   true
curved-cub  true
finicky-plantation  false
nimble-tablefalse
fluffy-window   false
wakeful-cracker false




On 19 Oct 2021, at 09:57, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:


Hi all,

We had a request for a vote of no confidence against Oswald Buddenhagen by Ivan 
Komissarov some weeks ago (*). Such a vote can be asked for by another Approver 
according to our governance model (**).

As this was the first time this passus got invoked, we had to do some work to 
put a voting system in place. Thanks to work by Daniel, this is now in place 
and we can now proceed with the request for a vote of no confidence.

The actual voting is open to all Approvers and Maintainers and happens on 
https://governancevoting.qt-project.org/voting. Voting is anonymous, but you 
will get a random moniker assigned after voting. Please store that moniker 
somewhere, as it’ll allow you to verify that your vote has been correctly 
counted when the voting period ends.

I’d like to urge everybody who is going to cast a vote to make themselves 
familiar with the full mailing list thread in (***) and read through the 
relevant parts of QUIP-2 before voting. Voting will be open for one week and 
closes on Monday, 25.10.21 at 23:59 CET.

Best regards,
Lars

(*) 
https://lists.qt-project.org/pipermail/development/2021-September/041799.html
(**) http://quips-qt-io.herokuapp.com/quip-0002.html, How to become an Approver
(***) 
https://lists.qt-project.org/pipermail/development/2021-September/041750.html
___
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org<mailto: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] Jira and issues left "In Progress"

[Lars Knoll]

+1 from my side. If nothing has happened to the task for 3 months, it’s very 
likely there’s no progress.

Cheers,
Lars

> On 28 Oct 2021, at 15:44, Alex Blasche  wrote:
> 
> Hi,
> 
> We have a growing problem with Jira issues forgotten in the "In Progress" 
> state. For the 10 most important  Jira projects we currently have 600+ issues 
> being stuck in the mentioned state. Since we recognize "In Progress" as a 
> blocking state (not open for take over by other engineers), I believe we 
> should keep the numbers small and mostly constraint to limited time frames.
> 
> By historical standard this is still much better than past times and I 
> attribute most of it to the "Fixed" git tag which automatically closes Jira 
> issues. Nevertheless of those "In Progress" issues about 170+ have not been 
> touched (or were forgotten) for more than 3 months.
> 
> I would like to do something about this by adding some automation similar to 
> the "Need more Info" automation. Those forgotten issues are likely not in 
> progress anymore or were fixed a long time ago. I believe returning them to 
> the "Open" state would trigger a re-evaluation by assignees (you). You either 
> close them as already done or keep them in "Open" as you recognize them as 
> not being done yet. 
> 
> My proposal would be to return every "In Progress" issue to "Open" if there 
> was no change for 3 month. 
> 
> I'd appreciate your feedback.
> 
> --
> 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

Re: [Development] Qt Governance: Vote of no confidence

[Lars Knoll]

Hi all,

The vote has been closed on Tuesday night. 33 Approvers voted, 24 in favour of 
the no confidence vote, 9 against. This means that the no-confidence vote 
passed the required quorum of 2/3 of the votes as defined in QUIP-2.

The detailed voting results by moniker are listed at the end of the email 
again, so people can verify that their own vote got counted correctly.

This result means that the Qt Project doesn’t have confidence in Ossi as an 
Approver and we will therefore remove his general Approver rights. According to 
the voting procedure outlined in the thread starting at 
https://lists.qt-project.org/pipermail/development/2021-October/041833.html 
there is a 14 days period for possible objections, so the change in Approver 
rights will be implemented once that period has passed.

It’s also important to note that Ossi is the Maintainer of qttranslations. He 
will keep the Maintainer and Approver rights for this module, as we have lots 
of precedence where individuals are Maintainers for a specific module without 
having Approver rights for the Qt Project as a whole.

Best regards,
Lars


pale-comparison false
tangy-help  true
subsequent-frametrue
puny-expansion  true
permissible-hammer  true
elastic-needle  true
near-fanfalse
peaceful-look   false
ugliest-reactiontrue
assorted-plot   true
yummy-heart true
frequent-value  true
strange-owner   true
doubtful-flesh  true
dramatic-power  true
humorous-frogs  true
male-bells  true
military-bead   true
dispensable-experience  true
profuse-deertrue
swift-magic true
drab-patch  false
knowing-deerfalse
cheerful-bridge true
petite-rifletrue
energetic-umbrella  true
gifted-volleyball   true
sudden-porter   true
curved-cub  true
finicky-plantation  false
nimble-tablefalse
fluffy-window   false
wakeful-cracker false




On 19 Oct 2021, at 09:57, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:


Hi all,

We had a request for a vote of no confidence against Oswald Buddenhagen by Ivan 
Komissarov some weeks ago (*). Such a vote can be asked for by another Approver 
according to our governance model (**).

As this was the first time this passus got invoked, we had to do some work to 
put a voting system in place. Thanks to work by Daniel, this is now in place 
and we can now proceed with the request for a vote of no confidence.

The actual voting is open to all Approvers and Maintainers and happens on 
https://governancevoting.qt-project.org/voting. Voting is anonymous, but you 
will get a random moniker assigned after voting. Please store that moniker 
somewhere, as it’ll allow you to verify that your vote has been correctly 
counted when the voting period ends.

I’d like to urge everybody who is going to cast a vote to make themselves 
familiar with the full mailing list thread in (***) and read through the 
relevant parts of QUIP-2 before voting. Voting will be open for one week and 
closes on Monday, 25.10.21 at 23:59 CET.

Best regards,
Lars

(*) 
https://lists.qt-project.org/pipermail/development/2021-September/041799.html
(**) http://quips-qt-io.herokuapp.com/quip-0002.html, How to become an Approver
(***) 
https://lists.qt-project.org/pipermail/development/2021-September/041750.html
___
Development mailing list
Development@qt-project.org<mailto: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 Doris Verria as Approver

[Lars Knoll]

I’ve worked with her a lot on the new Qt Multimedia module for Qt 6 and 
completely agree with Volker. 

So +1 from my side :)

Cheers,
Lars

> On 27 Oct 2021, at 11:56, Volker Hilsheimer  wrote:
> 
> Hello World,
> 
> I’d like to nominate Doris Verria as approver in the Qt Project.
> 
> Doris has been working as a Software Engineer for The Qt Company for over a 
> year, and has made great contributions to Qt [0]. I have come to appreciate 
> her as a coder that bravely takes on new challenges, and as a thorough code 
> reviewer [1].
> 
> I’ll trust she’ll use the approver rights responsibly.
> 
> Disclaimer: Doris reports directly to me in The Qt Company.
> 
> Volker
> 
> 
> [0] https://codereview.qt-project.org/q/owner:doris.verria%2540qt.io
> [1] https://codereview.qt-project.org/q/reviewer:doris.verria%2540qt.io
> 
> 
> ___
> 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 Governance: Vote of no confidence

[Lars Knoll]

On 19 Oct 2021, at 20:56, Oswald Buddenhagen 
mailto:oswald.buddenha...@gmx.de>> wrote:

hello jury,

On Tue, Oct 19, 2021 at 07:57:39AM +, Lars Knoll wrote:
I’d like to urge everybody who is going to cast a vote to [...]

as lars' mail sadly doesn't provide any actual guidance what exactly you're 
supposed to base your vote on, here's my own stab at it:

That was certainly on purpose. People need to make up their own mind and I 
don’t want to advertise my own opinions here.

you need to decide
- whether my professional judgment (regarding a build tool, as qt's   former 
build system maintainer) deserves the contempt demonstrated by   mr. kandeler 
in both word and deed
- whether me getting rebellious against him was appropriate conduct   given the 
circumstances (which essentially depends on how   authoritarian your reading of 
the qt governance model is)

Voting will be open for one week

this doesn't matter much unless the vote is close, but this period is way too 
short - for example, the waiting period for new nominations is  15 work days.

Please see 
https://lists.qt-project.org/pipermail/development/2021-October/041840.html, 
where I proposed a 7 days voting period. This wasn’t contested by anybody.

Cheers,
Lars

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

Re: [Development] Qt Governance: Vote of no confidence

[Lars Knoll]

> On 19 Oct 2021, at 09:57, Lars Knoll  wrote:
> 
> 
> Hi all,
> 
> We had a request for a vote of no confidence against Oswald Buddenhagen by 
> Ivan Komissarov some weeks ago (*). Such a vote can be asked for by another 
> Approver according to our governance model (**). 
> 
> As this was the first time this passus got invoked, we had to do some work to 
> put a voting system in place. Thanks to work by Daniel, this is now in place 
> and we can now proceed with the request for a vote of no confidence. 
> 
> The actual voting is open to all Approvers and Maintainers and happens on 
> https://governancevoting.qt-project.org/voting. Voting is anonymous, but you 
> will get a random moniker assigned after voting. Please store that moniker 
> somewhere, as it’ll allow you to verify that your vote has been correctly 
> counted when the voting period ends.
> 
> I’d like to urge everybody who is going to cast a vote to make themselves 
> familiar with the full mailing list thread in (***) and read through the 
> relevant parts of QUIP-2 before voting. Voting will be open for one week and 
> closes on Monday, 25.10.21 at 23:59 CET.

Sorry, this should be Tuesday, 26.10.21 at 23:59 CET, so we have full 7 days 
for voting.

Lars

> 
> Best regards,
> Lars
> 
> (*) 
> https://lists.qt-project.org/pipermail/development/2021-September/041799.html
> (**) http://quips-qt-io.herokuapp.com/quip-0002.html, How to become an 
> Approver
> (***) 
> https://lists.qt-project.org/pipermail/development/2021-September/041750.html
> ___
> 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] Qt Governance: Vote of no confidence

[Lars Knoll]

Hi all,

We had a request for a vote of no confidence against Oswald Buddenhagen by Ivan 
Komissarov some weeks ago (*). Such a vote can be asked for by another Approver 
according to our governance model (**). 

As this was the first time this passus got invoked, we had to do some work to 
put a voting system in place. Thanks to work by Daniel, this is now in place 
and we can now proceed with the request for a vote of no confidence. 

The actual voting is open to all Approvers and Maintainers and happens on 
https://governancevoting.qt-project.org/voting. Voting is anonymous, but you 
will get a random moniker assigned after voting. Please store that moniker 
somewhere, as it’ll allow you to verify that your vote has been correctly 
counted when the voting period ends.

I’d like to urge everybody who is going to cast a vote to make themselves 
familiar with the full mailing list thread in (***) and read through the 
relevant parts of QUIP-2 before voting. Voting will be open for one week and 
closes on Monday, 25.10.21 at 23:59 CET.

Best regards,
Lars

(*) 
https://lists.qt-project.org/pipermail/development/2021-September/041799.html
(**) http://quips-qt-io.herokuapp.com/quip-0002.html, How to become an Approver
(***) 
https://lists.qt-project.org/pipermail/development/2021-September/041750.html
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Formal voting procedure for Qt Project

[Lars Knoll]

> On 7 Oct 2021, at 10:52, Edward Welbourne  wrote:
> 
> Lars Knoll (6 October 2021 15:33) wrote:
>> * voting will be open for 7 days to give everybody enough time to react
>> * The voting database will be deleted 2 weeks after voting ended
> 
> Suggested revision for the second:
> 
> * The voting database will be deleted 2 weeks after voting ended, unless
>  the outcome is contested, in which case it shall be retained for as
>  long as is needed to resolve disputes that can be answered by that
>  database.
> 
> Note that if the outcome is contested for reasons not related to the
> contents of the database (who voted, how many for which outcome) this
> lets the two week schedule stand.

This is clearer, so we’ll use this text. We should probably formalise this by 
putting the whole procedure into a QUIP.

In any case, since there were no further comments, the voting procedure is 
hereby approved.

Cheers,
Lars

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

Re: [Development] Formal voting procedure for Qt Project

[Lars Knoll]

There hasn’t been too much feedback on the proposal or the implementation so 
far. I’ll give it until the weekend, and unless further comments or issues come 
up, I’ll assume a lazy consensus on the proposal and start looking into taking 
the system into use next week.

There are two additional items that I propose to add:

* voting will be open for 7 days to give everybody enough time to react
* The voting database will be deleted 2 weeks after voting ended

Cheers,
Lars

> On 1 Oct 2021, at 19:43, Lars Knoll  wrote:
> 
> Hi all,
> 
> As you might have seen, we had a request for a formal vote of no confidence 
> on an Approver status according to the last paragraph in QUIP-2/How to become 
> an Approver(*) in the recent QBS thread(**).
> 
> This is the first time we will need such a formal vote, which also means that 
> we so far have not implemented a detailed process on how to do that. So 
> before we proceed with such a vote, we will need to solve the problem of how 
> to vote. This doesn’t require changes our governance model, we simply need to 
> define a process on how to implement it.
> 
> Our governance model makes it clear that most decisions are reached through 
> lazy consensus. However, I do not want such sensitive matters as a vote of no 
> confidence to be handled by public vote. Therefore, I think we ought to find 
> a different solution - which, fortunately, can be decided on with lazy 
> consensus.
> 
> I’ve been talking to a few people for ideas, and this basically turned up 
> three proposals. Here they are together with my thoughts on them:
> 
> 1. Use the mailing list. 
> 
> I do not like this idea, when it touches sensitive matters such as a 
> no-confidence vote. These kind of votes should in my opinion never be public. 
> So this is something I do not consider to be a good option. See also 
> https://lists.debian.org/debian-vote/2021/04/msg00032.html for a recent 
> similar discussion in the Debian community.
> 
> 2. Approvers vote by sending me a private mail.
> 
> This would be possible, but is in my opinion far from ideal. I would need to 
> manually keep track of things running some risk of miscounting. In addition, 
> all individual votes would still be visible to me, with the risk of the voter 
> not participating due to the perceived social cost of doing so. People might 
> for example refrain from voting if they believe their opinion is not in line 
> with my thoughts.
> 
> 3. We have some automated system (a voting bot).
> 
> This sounds like the best option to me. Daniel Smith came up with the idea 
> and implemented a first version based on top of the cherry-pick bot that we 
> already use. You can find the implementation at 
> https://codereview.qt-project.org/c/qt/qtqa/+/373742 and a test instance at 
> https://qt-cherry-pick-bot-staging.herokuapp.com/voting/. It’s for now still 
> work in progress (you should e.g. not see the result before the end of the 
> voting period), but this is something we should be able to fix before we go 
> live.
> 
> The solution would have the following advantages:
> 
> * We can easily wipe the individual data some time after the vote is finished 
> and only keep the final result to comply with data privacy regulations and 
> keep the vote secret
> * The allowed group for voting (Approvers or Maintainers) can be defined and 
> is connected to our gerrit Approver and Maintainer groups.
> * It automatically counts the results
> * It can be made anonymous (Current implementation allows gerrit admins to 
> manually look into the database, so we need to govern access or improve that 
> part of the implementation)
> 
> I’d like to propose that we implement a voting procedure using this voting 
> bot. We need it for this one case, but would also benefit from having such a 
> tool in other cases, where the lazy consensus model might not be the best 
> solution.
> 
> We wouldn’t be the first ones to do that, there are other open source 
> communities out there that have secret voting procedures in place.
> 
> Please let me know what you think.
> 
> Cheers,
> Lars
> ___
> 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] Formal voting procedure for Qt Project

[Lars Knoll]

Hi all,

As you might have seen, we had a request for a formal vote of no confidence on 
an Approver status according to the last paragraph in QUIP-2/How to become an 
Approver(*) in the recent QBS thread(**).

This is the first time we will need such a formal vote, which also means that 
we so far have not implemented a detailed process on how to do that. So before 
we proceed with such a vote, we will need to solve the problem of how to vote. 
This doesn’t require changes our governance model, we simply need to define a 
process on how to implement it.

Our governance model makes it clear that most decisions are reached through 
lazy consensus. However, I do not want such sensitive matters as a vote of no 
confidence to be handled by public vote. Therefore, I think we ought to find a 
different solution - which, fortunately, can be decided on with lazy consensus.

I’ve been talking to a few people for ideas, and this basically turned up three 
proposals. Here they are together with my thoughts on them:

1. Use the mailing list. 

I do not like this idea, when it touches sensitive matters such as a 
no-confidence vote. These kind of votes should in my opinion never be public. 
So this is something I do not consider to be a good option. See also 
https://lists.debian.org/debian-vote/2021/04/msg00032.html for a recent similar 
discussion in the Debian community.

2. Approvers vote by sending me a private mail.

This would be possible, but is in my opinion far from ideal. I would need to 
manually keep track of things running some risk of miscounting. In addition, 
all individual votes would still be visible to me, with the risk of the voter 
not participating due to the perceived social cost of doing so. People might 
for example refrain from voting if they believe their opinion is not in line 
with my thoughts.

3. We have some automated system (a voting bot).

This sounds like the best option to me. Daniel Smith came up with the idea and 
implemented a first version based on top of the cherry-pick bot that we already 
use. You can find the implementation at 
https://codereview.qt-project.org/c/qt/qtqa/+/373742 and a test instance at 
https://qt-cherry-pick-bot-staging.herokuapp.com/voting/. It’s for now still 
work in progress (you should e.g. not see the result before the end of the 
voting period), but this is something we should be able to fix before we go 
live.

The solution would have the following advantages:

* We can easily wipe the individual data some time after the vote is finished 
and only keep the final result to comply with data privacy regulations and keep 
the vote secret
* The allowed group for voting (Approvers or Maintainers) can be defined and is 
connected to our gerrit Approver and Maintainer groups.
* It automatically counts the results
* It can be made anonymous (Current implementation allows gerrit admins to 
manually look into the database, so we need to govern access or improve that 
part of the implementation)

I’d like to propose that we implement a voting procedure using this voting bot. 
We need it for this one case, but would also benefit from having such a tool in 
other cases, where the lazy consensus model might not be the best solution.

We wouldn’t be the first ones to do that, there are other open source 
communities out there that have secret voting procedures in place.

Please let me know what you think.

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

Re: [Development] Qbs development

[Lars Knoll]

Hi all,

Just wanted to give a quick heads-up that this hasn’t been forgotten. But I’ve 
been sick with the flu the last week and simply didn’t manage to push things 
forward.

As we have so far not had the need for such a vote, there’s some things we’ll 
need to sort out to make it happen. I’ll follow up with a more detailed email 
in a separate thread hopefully tomorrow after the 6.2 release is out.

Cheers,
Lars

On 16 Sep 2021, at 19:53, Иван Комиссаров 
mailto:abba...@gmail.com>> wrote:

I believe there were several other cases, both in gerrit and discord.
I think, we should proceed with a formal vote.

Ivan

16 сент. 2021 г., в 14:50, David Skoland 
mailto:david.skol...@qt.io>> написал(а):



On 15 Sep 2021, at 16:52, Oswald Buddenhagen 
mailto:oswald.buddenha...@gmx.de>> wrote:
your arrogance, dismissiveness, and cynicism are duly noted, as usual.

I believe this constitutes a personal attack, which is in violation of the Qt 
Code of Conduct: 
http://quips-qt-io.herokuapp.com/quip-0012-Code-of-Conduct.html (Paragraph: Be 
respectful)

Cheers,

David Skoland
___
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] Qbs development

[Lars Knoll]

Hi,

I think this discussion about details is pretty much irrelevant.

The original problem is that using a -2 to block a change that has been 
approved by the module maintainer is basically abusing gerrit to break our 
governance model. QUIP-2 clearly states that the maintainer has decision power 
in case no agreement can be reached. 

You might disagree with that +2, but it is *not* your decision at that point. 
As an Approver you are expected to know our governance model and work within 
its frame. So if the maintainer gives a +2, you are abusing the system by 
continuing to block the change and violating our governance model. 

Lars

> On 16 Sep 2021, at 01:06, Oswald Buddenhagen  
> wrote:
> 
> On Thu, Sep 16, 2021 at 12:40:37AM +0300, Иван Комиссаров wrote:
>> 15 сент. 2021 г., в 14:03, Oswald Buddenhagen  
>> написал(а):
>>> for example, he plainly admits that his documentation doesn't match
>>> the code.
>> 
>> That’s not true.
>> 
> for it not being true you're making a _remarkable_ effort to establish
> that it would be _just fine_. ;)
> 
>> And if it is, feel free to submit patches, if you want the perfect
>> documentation
>> 
> it's not about perfect docu, it's about docu that even remotely matches
> the actual behavior. your argument was that my criticism of your patch
> is unjustified because the code actually does what i'm asking for, even
> though the docu _clearly_ says something else.
> 
> i don't actually care which it is, because either one justifies a -1.
> 
>> I am not interested in translating from C++ to English in order to
>> mention every small detail about implementation
>> 
> are you aware of point 1.1 of the qt commit policy?
> (and yes, qbs' documentend behavior is equivalent to qt's api in that
> regard.)
> 
>> (which you chose not to review despite being directly asked to do so.
>> Several times).
>> 
> that's entirely correct. i refuse to review code (which takes an order
> of magnitude more effort to do properly) when the documentation already
> tells me that what the code does is wrong. that's *reasonable*.
> 
>> The rest of the community is not interested either.
>> 
> which is quite unfortunate. but at least they are not the maintainers.
> 
>> It is not boring, it is irrelevant to the patch - I haven’t done any
>> global changes to the patch in a YEAR constantly pleasing you desire to
>> discuss the bigger picture.
>> 
> it's funny that you say that, because the very existence of the property
> whose precise semantics we're debating so hotly now is actually wholly
> my idea, and it took me long enough (that aforementioned year) to
> convince you that it is a necessary and good one (the review logs refer
> to it as QBS-61, prior to factoring it out to QBS-1604).
> 
> you have also convinced me of two things just recently, so you know it's
> possible if you just do it properly.
> ___
> 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] Qbs development

[Lars Knoll]

Hi Ivan,

I also would very much like you to stay here. QBS is great project and 
something that came out of the Qt work and still has very strong ties to it.

I am fully with Tuukka that what we want is to make it a good experience and 
easy for people to work here in the project. Blocking other peoples work is 
certainly not in line with this.

The governance model has the ’no confidence’ clause for a reason and if you 
have tried other means before, I can and will of course arrange such a vote.

Cheers,
Lars


On 15 Sep 2021, at 12:18, Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:

Hi,

I would not like Qbs development to move away from the Qt project. It is very 
unfortunate that you have had bad experience and misbehavior from one approver. 
We want to constantly improve the experience of working within the Qt project 
and naturally this kind of incidents are not doing that. Therefore, it is very 
good that you have raised the topic in the mailing list, as many were not aware 
of it earlier. On the positive side, I do not think there is any general 
hostility towards Qbs within the Qt projects – on the contrary I can see a lot 
of good co-operation.

Yours,

Tuukka


From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Иван Комиссаров mailto:abba...@gmail.com>>
Date: Tuesday, 14. September 2021 at 20.49
To: Lars Knoll mailto:lars.kn...@qt.io>>
Cc: Qt development mailing list 
mailto:development@qt-project.org>>
Subject: Re: [Development] Qbs development
Thanks for the response.
I can provide a third option - we can move Qbs out of the Qt Governance Model 
by moving to GitHub. I have raised this topic on our Discord server and the 
community overall seems positive - there were several votes for the migration 
and no votes against. This migration might be healthy to Qbs as a lot of 
newcomers are not familiar with Gerrit but familiar with GitHub and it’s 
pull-request model.
Also, it will clearly separate who can approve/reject patches to Qbs and to the 
rest of Qt world.
If there are no objections, I will create an INFRA issue about the migration - 
it should not be very hard to do.

Ivan


14 сент. 2021 г., в 17:33, Lars Knoll 
mailto:lars.kn...@qt.io>> написал(а):
 Hi,

Let’s also take up the formal part of the request.


On 13 Sep 2021, at 22:59, Иван Комиссаров 
mailto:abba...@gmail.com>> wrote:
Also, some actions might be taken to prevent from happening in the future - if 
technically possible, I’d like to request the revoke of his approver rights on 
the Qbs project as per this part of the Qt Governance Model:
«In extreme circumstances Approver privileges can be revoked by a vote of no 
confidence, proposed by an existing Approver or Maintainer and arranged by the 
Chief Maintainer. Privilege revocation requires a two-thirds majority vote of 
those Approvers and Maintainers who express an opinion.» [3]



On 14 Sep 2021, at 12:34, Richard Weickelt 
mailto:rich...@weickelt.de>> wrote:
The question is whether this is an abuse of approver rights.

This is a relevant question for the Qt project. Any person with approver
rights has the ability to cause a production stop. Ivan is asking for help
in this particular case and I am seconding his request.


Ivan and Richard, do I understand you correctly that you’d like to have a 
formal vote of no confidence according to QUIP-2? Please understand that this 
clause is meant as a last resort, when other solutions have failed.


We will also need to consider that the Qt Governance Model only defines global 
Approver rights for all of the Qt Project. The request was however limited to 
QBS, so we would need to find a way to handle this. I can only see two options 
there, either we start extending our governance model here (can be done with a 
lazy consensus on that extension), or change the scope to the whole project 
having much more severe implications.




Ossi, I (and probably others on this mailing list) would also like to hear your 
view on this. As I stated in my previous mail in this thread, I strongly 
believe, that the people doing the actual work decide on the direction and 
individual changes. The Governance model states the same, the maintainer takes 
the decision in case no agreement can be reached. As far as I can see, your 
actions are conflicting with this.


Thank you,
Lars

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

Re: [Development] Qbs development

[Lars Knoll]

Hi,

Let’s also take up the formal part of the request.

On 13 Sep 2021, at 22:59, Иван Комиссаров 
mailto:abba...@gmail.com>> wrote:
Also, some actions might be taken to prevent from happening in the future - if 
technically possible, I’d like to request the revoke of his approver rights on 
the Qbs project as per this part of the Qt Governance Model:
«In extreme circumstances Approver privileges can be revoked by a vote of no 
confidence, proposed by an existing Approver or Maintainer and arranged by the 
Chief Maintainer. Privilege revocation requires a two-thirds majority vote of 
those Approvers and Maintainers who express an opinion.» [3]


On 14 Sep 2021, at 12:34, Richard Weickelt 
mailto:rich...@weickelt.de>> wrote:
The question is whether this is an abuse of approver rights.

This is a relevant question for the Qt project. Any person with approver
rights has the ability to cause a production stop. Ivan is asking for help
in this particular case and I am seconding his request.

Ivan and Richard, do I understand you correctly that you’d like to have a 
formal vote of no confidence according to QUIP-2? Please understand that this 
clause is meant as a last resort, when other solutions have failed.

We will also need to consider that the Qt Governance Model only defines global 
Approver rights for all of the Qt Project. The request was however limited to 
QBS, so we would need to find a way to handle this. I can only see two options 
there, either we start extending our governance model here (can be done with a 
lazy consensus on that extension), or change the scope to the whole project 
having much more severe implications.


Ossi, I (and probably others on this mailing list) would also like to hear your 
view on this. As I stated in my previous mail in this thread, I strongly 
believe, that the people doing the actual work decide on the direction and 
individual changes. The Governance model states the same, the maintainer takes 
the decision in case no agreement can be reached. As far as I can see, your 
actions are conflicting with this.

Thank you,
Lars

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

Re: [Development] Qbs development

[Lars Knoll]

> On 14 Sep 2021, at 12:34, Richard Weickelt  wrote:
> 
> 
>> Just for the sake of clarity, who *is* the Maintainer of QBS ?
>> Our wiki's [[Maintainers]] page only mentions Christian Kandeler as
>> maintainer of Qt Creator's integration with it.  I gather Ivan is a/the
>> principal developer of QBS in practice.  Is Ossi co-Maintainer, or are
>> you really talking about his Approver rights (which, IIUC, suffice to
>> make a +2 significant) ?
>> 
>> Before we resort to [0] QUIP 2's "extreme circumstances" provisions,
>> please let's do what we can to work our way through the steps that come
>> before that - for which we first need to settle the question of who *is*
>> The Maintainer (or who are The Maintainers, if more than one) of QBS.
>> 
>> [0] http://quips-qt-io.herokuapp.com/quip-0002.html
> 
> Christian Kandeler is the only maintainer. Ivan Komissarov is the most
> active developer in that repository and has approver rights as well.
> 
> We are talking here about the situation that the maintainer has given a +2
> while a person unrelated to that particular repository has stopped the patch
> with a -2. On the other hand, that person has neither shown any intention to
> implement that feature nor has the person contributed to the codebase during
> the last couple of years.

I think this makes the situation very clear. The maintainer of a module has the 
right to overrule negative reviews. So if Christian thinks this change is ok to 
go in, it is his full right to overrule a -1 and also a -2 from someone else.

We should all of us be careful in giving -2s on code reviews. I don’t think 
anybody should give a -2 unless you are the maintainer/deeply involved in the 
code in question or the commit violates some of our policies. 
> 
> The question is whether this is an abuse of approver rights.

Blocking a change in an area you aren’t actively working on against the 
expressed wishes of the maintainer would in my opinion be such an abuse. Giving 
a -2 directly after the maintainer approved the change is getting very close to 
that.
> 
> This is a relevant question for the Qt project. Any person with approver
> rights has the ability to cause a production stop. Ivan is asking for help
> in this particular case and I am seconding his request.

Any such system has to be built to a good degree on trust that people do the 
right thing and have good intentions. We do have gerrit admins that can help in 
such cases and remove a block.

As a general rule to everybody: Please do not make the perfect the enemy of the 
good. We shouldn’t block changes that improve an existing situation even if 
they aren’t covering everything one can think of. The question has to be 
whether the change improves on the current base and doesn’t cause regressions. 
Of course this requires that the change itself doesn’t leave loose ends someone 
else might have to clean up.

If you think something’s missing, you can point those out, also give a -1 if 
you feel they are important. But please also respect the work others are doing. 
If someone contributing says is not willing to push it further (or wants to do 
in later), that should be ok as well (given the conditions above).

Cheers,
Lars



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

Re: [Development] Nominating Kaj Grönholm as approver

[Lars Knoll]

Another +1 from my side.

Cheers,
Lars

> On 5 Aug 2021, at 13:29, Andy Nichols  wrote:
> 
> +1 from me as well.  Managed to miss this nomination while I was on vacation, 
> but Kaj has been making excellent contributions to the Qt Graphics stack for 
> multiple years and I think approver status in his case is overdue.
> 
> --
> Andy Nichols
> 
> -Original Message-
> From: Development  On Behalf Of Volker 
> Hilsheimer
> Sent: Monday, July 12, 2021 10:38 AM
> To: development@qt-project.org
> Subject: [Development] Nominating Kaj Grönholm as approver
> 
> Hi,
> 
> 
> I’d like to nominate Kaj Grönholm as an approver for the Qt Project.
> 
> Kaj has been working primarily on Qt 3D Studio and Qt Quick 3D, most recently 
> on the particle effects support in Qt 6.
> 
> He has authored the following patches:
> 
> https://codereview.qt-project.org/q/owner:kaj.gronholm%2540qt.io
> 
> and reviewed these:
> 
> https://codereview.qt-project.org/q/reviewer:kaj.gronholm%2540qt.io
> 
> 
> Cheers,
> Volker
> 
> ___
> 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] Temporarily preventing changes being staged in the dev branch of qtquickcontrols2

[Lars Knoll]

> On 27 Jul 2021, at 07:19, Jani Heikkinen  wrote:
> 
>> -Original Message-
>> From: Mitch Curtis 
>> Sent: perjantai 23. heinäkuuta 2021 17.12
>> To: Alexandru Croitor 
>> Cc: development@qt-project.org; Qt Releases 
>> Subject: Re: [Development] Temporarily preventing changes being staged in
>> the dev branch of qtquickcontrols2
>> 
>> Thanks for bringing this up. It's a good point I hadn't thought about. I 
>> wonder
>> if it's too late to do the merge in 6.2 instead... that would save a lot of 
>> hassle
>> in the long term.
> 
> 
> Well, this kind of changes should have been done before FF. But on the other 
> hand doing this change should help us to keep dependency updates more stable 
> instead. I can't see this causing big risks for Qt 6.2 schedule either and I 
> agree doing this also in 6.2 would make things easier in the future. So I am 
> not against this change if we are really sure this won't cause delays to the 
> 6.2.0 release. But of course it is Lars who needs to approve this change in 
> '6.2'.

If we merge those repos, we should really do it for 6.2 as well. Otherwise, 
we’re making it unnecessarily hard to work with bug fixes that need to go into 
6.2.

So fine for me to do the merge in both 6.2 and dev.

Cheers,
Lars

> 
> br,
> Jani Heikkinen
> Release Manager
> 
> 
> 
>> 
>> On 23/7/21, 4:02 pm, "Alexandru Croitor"  wrote:
>> 
>>Hi
>> 
>>> On 20/7/21, 2:10 pm, "Development on behalf of Mitch Curtis"
>> 
>> wrote:
>>> 
>>>   Hi.
>>> 
>>>   I'd like to request that we temporarily prevent changes from being
>> staged in the dev branch of qtquickcontrols2 in preparation for merging it
>> into qtdeclarative, as otherwise changes could be missed in the merge.
>>> 
>>>   I'm sending this to both the release team and the development mailing
>> list as a heads up.
>>> 
>> 
>>As i understand the current intention is to merge qtquickcontrols2 dev
>> branch into qtdeclarative dev branch, which is Qt 6.3 at the moment.
>> 
>>That leaves qtuickcontrols2 and qtdeclarative separate in 6.2 LTS branch.
>> 
>>The current cherry-pick bot can't handle cross-repo cherry-picks.
>> 
>>Which means any qqc2 code changes in qtdeclarative repo 6.3, 6.4, 6.5,
>> branch will have to be replicated with a more manual process to 6.2 branch of
>> qtquickcontrols2 repo, because 6.2 is LTS.
>> 
>>Can these cherry-picks be done automatically somehow? Is the manual
>> process the one we want / are stuck with?
>> 
>>Is this enough justification to do the qqc2 -> qtdeclarative merge in 6.2
>> branch instead?
> 
> ___
> 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] Mirror IRC channels on KDE's Matrix Instance

[Lars Knoll]

Another +1. 

Cheers,
Lars

> On 28 Jun 2021, at 15:24, Ulf Hermann  wrote:
> 
> +1
> 
> On 6/28/21 12:51 PM, Cristián Maureira-Fredes wrote:
>> Hello everyone,
>> Context
>> ---
>> After the "Improve the contributor experience" session at the past Qt
>> Contributors Summit, many ideas came out related to an overall
>> improvement to the contribution experience, mainly focused on new
>> people joining the Qt Project.
>> One of the topics was Communication,
>> from which we (qt project people) discussed together with some KDE folks
>> and agreed that bringing the Qt and KDE communities closer was a good
>> idea, mainly based on the good experience KDE has currently on the
>> platform.
>> We have a good opportunity to do this via a bridge from our newly
>> created Libera.chat IRC channels, to KDE's Matrix Instance.
>> During the QtCS,
>> we tried this out, and mirrored the #qt-cs IRC channel
>> to Matrix: https://go.kde.org/matrix/#/#qt-cs:kde.org
>> and according to the people that participated in the session the
>> experience was nice, and it might be worth to bridge all the other
>> #qt-* channels on IRC.
>> Read more about Matrix: https://matrix.org/
>> Read more about KDE's Matrix Instance: https://community.kde.org/Matrix
>> Implications
>> 
>> If you prefer IRC, it's totally fine,
>> this change would only imply that you will get more people
>> on IRC to interact with.
>> If you want to move to Matrix completely, this change will enable
>> you to stay in touch with folks on the IRC channels.
>> Permissions work different on Matrix than IRC,
>> but with the current list of moderators in the #qt- domain
>> we can easily assign permissions to people on the Matrix
>> channels accordingly.
>> Let's keep the discussion of other communication platforms
>> outside this thread, while they might be valid, it's
>> out of the scope of this proposal.
>> Question
>> 
>> I would like to ask the Qt Project if you agree or disagree
>> with the proposal to mirror all the #qt-* channels from Libera.chat
>> to KDE's Matrix Instance.
>> If we don't have unresolved disagreements, I'd say we can
>> proceed with the mirroring Monday next week, but if there are
>> concerns, I would prefer to address them first.
>> Cheers
> ___
> 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] Windows maintainer change

[Lars Knoll]

Another +1 and a big thanks to Friedemann for his work on the Windows port over 
all the years!

Cheers,
Lars

> On 16 Jun 2021, at 11:18, Morten Sørvig  wrote:
> 
> +1 from me as well, and I’d like to thank Friedemann for his work on Qt on 
> Windows through the years.
> 
> Morten
> 
>> On 15 Jun 2021, at 11:13, Tor Arne Vestbø  wrote:
>> 
>> Hear hear! +1
>> 
>>> On 15 Jun 2021, at 11:05, Shawn Rutledge  wrote:
>>> 
>>> +1
>>> 
>>> Thanks for the work that all 3 of you have put into it over the years.
>>> 
 On 15 Jun 2021, at 09:27, Oliver Wolff  wrote:
 
 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 ;)
>>> 
>>> ___
>>> 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

[Development] Feature freeze and CI load

[Lars Knoll]

Hi all,

This is a short reminder that feature freeze for 6.2 is coming up tomorrow 
evening. There is still time over the weekend to merge pending changes that 
didn’t make it until Friday evening, but those days should only be used to 
merge changes that are already approved but still pending on gerrit.

We do have a few exceptions to the feature freeze though:
* Qt WebEngine still has some work that needs to be finished to get especially 
cross-compilation working with cmake. That work can continue past the feature 
freeze.
* Qt Multimedia has missing features for the Android and Windows backends and 
needs some more API changes that will happen after the feature freeze
* The QML cmake API changes that are pending on gerrit can proceed to get in 
(see 
https://codereview.qt-project.org/q/topic:%22qml-cmake-api%22+(status:open%20OR%20status:merged)
 ). But let’s try to get those done as quickly as possible, ideally until 
Monday, so that those changes don’t delay the branching

To help with that, I’d like to ask everybody to help reduce load on CI for 
things that are unrelated to the feature freeze. Especially, please think twice 
or three times before pressing the ‘precheck’ button in gerrit. Every such run 
adds quite some load to CI and we’ve been having a huge amount of those lately. 
If the run is not critical for the feature freeze consider waiting until the 
branching of 6.2 has happened. For those working inside the Qt Company, please 
also consider using the internal coin status check page and limit the precheck 
to one or two platforms. 

Thanks,
Lars

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

Re: [Development] Multi-Selection behavior of item views breaks drag'n'drop UX - options

[Lars Knoll]

Of course. The +1 only applies to Qt 6, and not any versions of Qt 5 :)

Cheers,
Lars

> On 1 Jun 2021, at 14:58, David Skoland  wrote:
> 
> To be clear: +1 to changing default behavior in 6.2.
> 
>> On 1 Jun 2021, at 14:57, David Skoland  wrote:
>> 
>> Not thrilled about subtle default behavior changes like this, there’s no 
>> knowing how it may break certain apps. I suppose most people will be 
>> upgrading from 5 to 6.2 and will to some degree expect having to make some 
>> adjustments and the proposed behavior is definitely desirable, so I’m giving 
>> this a +1.
>> 
>>> On 28 May 2021, at 13:10, Volker Hilsheimer  wrote:
>>> 
>>> Hey Widget fans,
>>> 
>>> I need your opinions on https://bugreports.qt.io/browse/QTBUG-59888
>>> 
>>> The UX resulting from our (strange) choice to trigger selection changes on 
>>> mouse press rather than mouse release is indeed quite horrible, as 
>>> explained in the ticket.
>>> 
>>> The options to fix that seem to be:
>>> 
>>> 1) change the default behavior - always change selection on mouse release
>>> 2) change the default behavior if drag (as per dragDropMode)
>>> 3) make the "selection trigger" a property
>>> 
>>> None of those options would IMHO result in a change that qualifies for 
>>> stable branches. I’ve for now implemented option 3. This introduces new 
>>> API, so if we agree that this is the way to go then it would ideally be 
>>> merged before 6.2 feature freeze next Friday.
>>> 
>>> https://codereview.qt-project.org/c/qt/qtbase/+/351595
>>> 
>>> However, the possible property values seem oddly specific to this problem, 
>>> and give that this is a 6.2 only change anyway, perhaps it would be best to 
>>> simply change the default, which would then also make Qt matching native 
>>> UIs better (ie Windows Explorer or macOS Finder)?
>>> 
>>> Cheers,
>>> Volker
>>> 
>>> ___
>>> 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] Multi-Selection behavior of item views breaks drag'n'drop UX - options

[Lars Knoll]

On 28 May 2021, at 16:37, Konstantin Shegunov 
mailto:kshegu...@gmail.com>> wrote:

On Fri, May 28, 2021 at 2:13 PM Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:
Hey Widget fans,

Hola,

I need your opinions on https://bugreports.qt.io/browse/QTBUG-59888

The UX resulting from our (strange) choice to trigger selection changes on 
mouse press rather than mouse release is indeed quite horrible, as explained in 
the ticket.

The options to fix that seem to be:

1) change the default behavior - always change selection on mouse release
2) change the default behavior if drag (as per dragDropMode)
3) make the "selection trigger" a property

Personally, I'd go for 1). This is rather usual from the user point of view. 
That's how buttons and other UI elements typically operate - by handling the 
behaviour whenever the release occurred over the element of interest.

Another +1 for changing the default behavior.

Cheers,
Lars


Also this thread[1] may be of interest to you. Implementing 1) is also probably 
going to make the hack to change the selection back moot.

[1] 
https://forum.qt.io/topic/126692/reordering-rows-of-qtableview-with-drag-and-drop

Kind regards,
Konstantin.
___
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] Moving IRC from Freenode to Libera.Chat, voting thread

[Lars Knoll]

Thanks a lot for this, Peppe!

Btw, do you know is there’s a policy with regards to nicknames one had 
registered on Freenode? Just wondering as someone registered my old nick on 
Libera.

Cheers,
Lars

> On 29 May 2021, at 19:27, Elvis Stansvik  wrote:
> 
> Thanks for taking care of this Peppe.
> 
> Elvis
> 
> Den lör 29 maj 2021 kl 18:24 skrev Giuseppe D'Angelo via Development
> :
>> 
>> Hi,
>> 
>> On 28/05/2021 00:06, Giuseppe D'Angelo via Development wrote:
>>> On 22/05/2021 03:06, Giuseppe D'Angelo via Development wrote:
 == DEADLINE FOR VOTING ==
 
 23.59 CEST of Thursday 27 May 2021.
>>> We have unanimous consent.
>> 
>> == Update ==
>> 
>> This is now in effect. We have control over the #qt-* channels on
>> Libera. Our official presence is there now.
>> 
>> Most of the channels in the #qt-* namespace have been re-registered,
>> incl. #qtwebkit, #qtwebengine, #qbs. Please contact me (in private
>> email) if you want to manage some of those.
>> 
>> The online communities wiki page has been updated.
>> 
>> 
>> == What does this mean for me ==
>> 
>> Simply make your IRC client to irc.libera.chat/6697 (TLS), join the same
>> channels. If you prefer Matrix, a bridge has been set up.
>> 
>> The first time you connect, consider re-registering your nick, and
>> configure your client to authenticate there. That's it.
>> 
>> 
>> == Next steps ==
>> 
>> 1) I'd like some volunteers as backup community contacts, so I'm not the
>> SPOF of the whole operation. Please write to me (in private email) if
>> you're interested.
>> 
>> 2) We'll (slowly) rebuild the ACLs. Approvers and other channel
>> "owners", if you wish, please write to me (in private email!) telling me
>> your nick registration on Libera, so I can give you powers on #qt-labs.
>> Similarly please tell me if you want a hostname cloak.
>> 
>> 3) I'm not changing topics nor auto-join messages in the Freenode
>> channels, for a few more days at least, to give people an opportunity
>> to move quietly. It seems that the sole mention of Libera.Chat is
>> sufficient for the Freenode staff to forcibly take the channels over,
>> and I would like to avoid "drama" if possible. Still, this is an active
>> threat, so the sooner people move, the better.
>> 
>> https://i.imgur.com/laFn6MM.png (#qt-fr being seized)
>> 
>> https://www.devever.net/~hl/freenode_abuse2
>> 
>> 
>> 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

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

Re: [Development] New Qt Multimedia

[Lars Knoll]

> On 28 May 2021, at 10:27, Samuel Gaist  wrote:
> 
> 
>> On 28 May 2021, at 10:09, Lars Knoll  wrote:
>> 
>>> On 28 May 2021, at 09:15, Alberto Mardegan  
>>> wrote:
>>> 
>>> Hi Lars,
>>> 
>>> On 26/05/21 15:09, Lars Knoll wrote:
>>>> The hope is that we can change that for Qt 6. To make this possible, we 
>>>> have changed not only parts of the public API, but completely redone its 
>>>> internal architecture, especially how multimedia connects to the platform 
>>>> specific backends. Apart from cleaning up the backend API and greatly 
>>>> simplifying it, I also chose to make it private and remove the plugin 
>>>> architecture around it. The backend is now selected at compile time, and 
>>>> we’re now only supporting one backend per platform.
>>> 
>>> can you please clarify what this would mean for projects (like Ubuntu
>>> Touch) which are using their own QtMultimedia plugins?
>>> Supporting one plugin per platform seems reasonable, but making the
>>> plugin API private and selecting the plugin at compile time probably
>>> means that all multimedia backends must be made part of QtMultimedia git
>>> repository, right?
>> 
>> For the moment that is correct. The reason is that it greatly simplifies 
>> maintenance of the module, something we’ve been struggling with for the 
>> whole lifetime of Qt 5.
>> 
>> Having a public API for the backend was one of the main problems that made 
>> it extremely difficult to work and maintain the module. And plugins for the 
>> backend didn’t make much sense once the backend API is private.
>> 
>> A public backend API with a BC promise is simply not an option IMO, as it 
>> will make it significantly harder to implement new functionality for Qt MM 
>> in the future.
>>> 
>>> Or is it so that the backend is selected at compile time, but it can
>>> still be dynamically loaded from a separate plugin binary?
>> 
>> No, selection is done at compile time right now.
>>> 
>>> This has the potential to make things harder to develop, especially for
>>> smaller projects like ours. I'm especially thinking of:
>> 
>> Before we go into the topics below, can we take a step back, please? I’d 
>> first like to know *why* you were developing and maintaining your own 
>> multimedia backend.
>> 
>> Cheers,
>> Lars
>> 
> 
> There might also be a need to define exactly what "multimedia backend" means 
> here.
> 
> I have implemented several custom QCamera backends for hardware that were not 
> accessible through the system multimedia API.
> 
> For example network cameras, AJA capture cards, BlackMagic capture cards, etc.
> 
> Would that still be possible with the Qt 6 implementation ?

How have you implemented those? If you implemented a gstreamer element for 
those cameras, and gst-device-monitor lists them correctly, we’ll simply pick 
them up.

Cheers,
Lars

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

Re: [Development] New Qt Multimedia

[Lars Knoll]

> On 28 May 2021, at 09:15, Alberto Mardegan  
> wrote:
> 
> Hi Lars,
> 
> On 26/05/21 15:09, Lars Knoll wrote:
>> The hope is that we can change that for Qt 6. To make this possible, we have 
>> changed not only parts of the public API, but completely redone its internal 
>> architecture, especially how multimedia connects to the platform specific 
>> backends. Apart from cleaning up the backend API and greatly simplifying it, 
>> I also chose to make it private and remove the plugin architecture around 
>> it. The backend is now selected at compile time, and we’re now only 
>> supporting one backend per platform.
> 
> can you please clarify what this would mean for projects (like Ubuntu
> Touch) which are using their own QtMultimedia plugins?
> Supporting one plugin per platform seems reasonable, but making the
> plugin API private and selecting the plugin at compile time probably
> means that all multimedia backends must be made part of QtMultimedia git
> repository, right?

For the moment that is correct. The reason is that it greatly simplifies 
maintenance of the module, something we’ve been struggling with for the whole 
lifetime of Qt 5.

Having a public API for the backend was one of the main problems that made it 
extremely difficult to work and maintain the module. And plugins for the 
backend didn’t make much sense once the backend API is private.

A public backend API with a BC promise is simply not an option IMO, as it will 
make it significantly harder to implement new functionality for Qt MM in the 
future.
> 
> Or is it so that the backend is selected at compile time, but it can
> still be dynamically loaded from a separate plugin binary?

No, selection is done at compile time right now.
> 
> This has the potential to make things harder to develop, especially for
> smaller projects like ours. I'm especially thinking of:

Before we go into the topics below, can we take a step back, please? I’d first 
like to know *why* you were developing and maintaining your own multimedia 
backend.

Cheers,
Lars

> 
> 1) The QtProject might even flatly refuse to include a backend which is
> only used in a minor platform
> 2) It will be hard (if not impossible) to run CI on it, we'll only be
> able to test the Qt builds in our own CI, but that might be too late (I
> mean, it's not really CI anymore)
> 3) Licensing issues (well, this is not a problem for our specific case,
> I think)
> 
> Ciao,
>  Alberto
> 
> -- 
> http://www.mardy.it - Geek in un lingua international
> ___
> 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] New Qt Multimedia

[Lars Knoll]

On 27 May 2021, at 16:18, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:
On 27 May 2021, at 15:34, Eike Hein mailto:h...@kde.org>> wrote:

May 27, 2021 2:51 PM, "Samuel Gaist" 
mailto:samuel.ga...@idiap.ch>> wrote:
I think one of the main use case I have seen for custom GStreamer pipelines is 
to be able to get
rtsp or other network streams in Qt applications.

This is my personal use case as well. With the addition that I also have
some pipelines where I need to deal with RTP without the convenience of
an RTSP session setup around it (in https://kirogi.org, which is
currently on gst-qmlsink for Qt Quick integration - drones do all sorts
of funky streaming things).

we accept a url as the source for the media. For gstreamer we use uridecodebin 
to decode that URL. Afaik that automatically gives you rtp and rtsp support (at 
least if the required gstreamer plugins are installed)

Just did a check with the player example and

./player rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov

works just fine. Hope that solves that problem :)

Cheers,
Lars


You can also specify a QIODevice as the source. I’m that case we’re using a 
GstAppSrc together with a decodebin.

Cheers,
Lars


Cheers,
Eike
___
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org<mailto: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] New Qt Multimedia

[Lars Knoll]

> On 27 May 2021, at 15:34, Eike Hein  wrote:
> 
> May 27, 2021 2:51 PM, "Samuel Gaist"  wrote:
>> I think one of the main use case I have seen for custom GStreamer pipelines 
>> is to be able to get
>> rtsp or other network streams in Qt applications.
> 
> This is my personal use case as well. With the addition that I also have
> some pipelines where I need to deal with RTP without the convenience of
> an RTSP session setup around it (in https://kirogi.org, which is
> currently on gst-qmlsink for Qt Quick integration - drones do all sorts
> of funky streaming things).
> 
we accept a url as the source for the media. For gstreamer we use uridecodebin 
to decode that URL. Afaik that automatically gives you rtp and rtsp support (at 
least if the required gstreamer plugins are installed)

You can also specify a QIODevice as the source. I’m that case we’re using a 
GstAppSrc together with a decodebin. 

Cheers,
Lars
> 
> 
> Cheers,
> Eike
> ___
> 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] New Qt Multimedia

[Lars Knoll]

On 27 May 2021, at 15:25, Rodrigo Gonçalves de Oliveira 
 wrote:


Also, this is how I define and change different audio devices ("gst-pipeline: 
... audio_sink=\"alsasink device=%1\") on demand.
Are there plans to have an easy way to change the output audio device? Think on 
an embedded system, within a media app and multiple audio devices, where the 
user want to change the audio output device at any time.

Have a look at QMediaDevices that lets you discover different inputs/outputs. 
You can also get notifications when a new output becomes available (eg. because 
you connected a headset).

QMediaPlayer and QMediaCaptureSession have an API that let you choose the 
output you want based on the available devices you can get from QMediaDevices.

Cheers,
Lars

On Thu, May 27, 2021 at 9:54 AM Samuel Gaist via Development 
mailto:development@qt-project.org>> wrote:

> On 27 May 2021, at 14:35, Lars Knoll 
> mailto:lars.kn...@qt.io>> wrote:
>
>> On 27 May 2021, at 14:25, Eike Hein mailto:h...@kde.org>> 
>> wrote:
>>
>> May 27, 2021 8:14 AM, "Lars Knoll" 
>> mailto:lars.kn...@qt.io>> wrote:
>>> The one thing I want to avoid is what we had in Qt 5, where you could force 
>>> Qt MM to use a
>>> different/custom gstreamer pipeline based on environment variables. That 
>>> part made maintaining the
>>> code base extremely hard. Other than that I’m of course open for patches 
>>> and improvements. If some
>>> integration points are needed, we can discuss those separately, but unless 
>>> they are trivial, they
>>> will probably need to wait until after 6.2.
>>
>> Hmm - does that mean the `gst-pipeline:` URL scheme for `setMedia`/the 
>> `source`
>> prop is getting dropped as well?
>
> That’s correct. It’s has honestly been a huge cludge, and something we didn’t 
> have anywhere else. I’d rather see that we fix issues inside Qt MM instead of 
> working around them with hacks such as this one.
>>
>> If memory serves right, this was possible accidentally at some point and then
>> was raised to the status of Official Footgun in 5.12+:
>>
>> https://doc.qt.io/qt-5/qmediaplayer.html#setMedia
>
> Footgun is probably the right name for it, and a reason I don’t want to 
> continue with it for Qt 6.
>>
>> A potential troublemaker for sure, but also very powerful. With QtGStreamer
>> being deprecated (an old set of Qt bindings to GStreamer API - also something
>> at least one KDE app I'm aware of still carries an internal fork of, sadly),
>> a QtMM w/ custom pipeline support sort of the next best thing.
>
> Lets rather have a look at the use cases that people want to have supported 
> and how we can get those working.
>
> Cheers,
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org<mailto:Development@qt-project.org>
> https://lists.qt-project.org/listinfo/development

I think one of the main use case I have seen for custom GStreamer pipelines is 
to be able to get rtsp or other network streams in Qt applications.

Best regards

Samuel

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


--
Rodrigo Oliveira
Florianópolis, Brazil
rodrigo.gol...@gmail.com<mailto:rodrigo.gol...@gmail.com>
+55 48 91605760
http://br.linkedin.com/in/rodrigogoliveira
___
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] New Qt Multimedia

[Lars Knoll]

> On 27 May 2021, at 14:25, Eike Hein  wrote:
> 
> May 27, 2021 8:14 AM, "Lars Knoll"  wrote:
>> The one thing I want to avoid is what we had in Qt 5, where you could force 
>> Qt MM to use a
>> different/custom gstreamer pipeline based on environment variables. That 
>> part made maintaining the
>> code base extremely hard. Other than that I’m of course open for patches and 
>> improvements. If some
>> integration points are needed, we can discuss those separately, but unless 
>> they are trivial, they
>> will probably need to wait until after 6.2.
> 
> Hmm - does that mean the `gst-pipeline:` URL scheme for `setMedia`/the 
> `source`
> prop is getting dropped as well?

That’s correct. It’s has honestly been a huge cludge, and something we didn’t 
have anywhere else. I’d rather see that we fix issues inside Qt MM instead of 
working around them with hacks such as this one.
> 
> If memory serves right, this was possible accidentally at some point and then
> was raised to the status of Official Footgun in 5.12+:
> 
> https://doc.qt.io/qt-5/qmediaplayer.html#setMedia

Footgun is probably the right name for it, and a reason I don’t want to 
continue with it for Qt 6.
> 
> A potential troublemaker for sure, but also very powerful. With QtGStreamer
> being deprecated (an old set of Qt bindings to GStreamer API - also something
> at least one KDE app I'm aware of still carries an internal fork of, sadly),
> a QtMM w/ custom pipeline support sort of the next best thing.

Lets rather have a look at the use cases that people want to have supported and 
how we can get those working.

Cheers,
Lars

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

Re: [Development] New Qt Multimedia

[Lars Knoll]

> On 26 May 2021, at 17:30, Eike Hein  wrote:
> 
> Exciting!
> 
> Are there any plans to officially support the GStreamer backend on Android 
> down the line (with building GStreamer as an acceptable exercise left to the 
> user) or would work in that direction be appreciated by the module maintainer?

I don’t think I want to officially support it right now, but build fixes to 
make it work and selectable on Android are welcome.
> 
> At KDE, we have a couple of apps that use GStreamer API directly in 
> conjunction with gst-qmlsink, as GStreamer enables some advanced pipelines 
> not functionally supported by Android's native media framework (e.g. RTP 
> without RTSP). Naturally, using Qt Multimedia is far more ergonomic than 
> mixing GStreamer's C API into the code, however.

The one thing I want to avoid is what we had in Qt 5, where you could force Qt 
MM to use a different/custom gstreamer pipeline based on environment variables. 
That part made maintaining the code base extremely hard. Other than that I’m of 
course open for patches and improvements. If some integration points are 
needed, we can discuss those separately, but unless they are trivial, they will 
probably need to wait until after 6.2.

Cheers,
Lars

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

Re: [Development] New Qt Multimedia

[Lars Knoll]

On 26 May 2021, at 21:00, Arnaud Vrac 
mailto:raw...@gmail.com>> wrote:

Le mer. 26 mai 2021 à 14:11, Lars Knoll 
mailto:lars.kn...@qt.io>> a écrit :
[snip]

Hi Lars,

Thanks for the updates. One feature that I've always waited for is the
possibility to list and select audio/subtitle tracks from qml. Now
that the feature is implemented in C++, it seems not much would be
missing to also support this officially in QML. Is this planned ?

The plan is to support everything we have on the C++ side for QML as well. All 
that’s missing right to get this working is actually a test case written in QML 
and adding a couple of Q_PROPERTY declarations in QMediaPlayer.

Cheers,
Lars

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

Re: [Development] New Qt Multimedia

[Lars Knoll]

> On 26 May 2021, at 18:14, Jason H  wrote:
> 
>>> 4. On the removal of QAbstractVideoFilter AND QVideoProbe: Disappointed to 
>>> hear this. I previously used this for read-only frames for analysis, i.e. 
>>> Barcode reading and object detection. How do we do that now?
>> 
>> You can get full access to the video data from a QVideoSink through the 
>> newVideoFrame() signal and mapping the video frame (or converting it to a 
>> QImage). With that you should have the access to the data that you need. (A 
>> small detail that’s still missing right now but that I hope to have in place 
>> for 6.2 is the ability to connect several sinks to a media player or capture 
>> session, but it’s not really required as you can connect several slots to 
>> the signal). If you feel like to need more than that, let me know what it is.
> 
> So the most common case I need supported is getting the video frame for 
> processing while maintaining the full-speed live preview. Is this the 
> multi-sink scenario?

You can work with one sink by connecting to it’s newVideoFrame() signal. The 
only thing that’s a bit more cumbersome in that case it how to get to the video 
sink, but neither that should be  large problem.

Multiple sinks are mainly required to be able to support multiple video output 
surfaces in a generic way on the framework level.

> Typically, With Camera connected o a VideoOutput, I use QVideoProbe to throw 
> the frame (pixel data as QByteArray, because the library doesn't care) to a 
> thread for multicore async processing. A typical 1 megapixel image on 
> RaspberryPi4 takes ~150ms using ZBar or ZXing (I find ZXing is more like 
> 100ms), so this gets about 6 processed frames a second, which seems 
> responsive enough to the user because they are looking at the live display.
> 
> Since you asked for actual code, attached is the code I use to do this. It 
> may not be perfect code (long story made short, I just rewrote this from 
> memory) but it is what I whipped up, and works reasonably well for now.  I've 
> used this approach for barcodes and OpenCV.
> 
> If it matters: I disclaim any copyright for the attached 
> files.

Thanks for the snippet. I think this should be perfectly doable. Connect to the 
signal, then map the QVideoFrame and copy out the Y channel.

Cheers,
Lars

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

Re: [Development] New Qt Multimedia

[Lars Knoll]

> On 26 May 2021, at 16:47, Alexander Akulich  
> wrote:
> 
> On Wed, May 26, 2021 at 5:25 PM Jason H  wrote:
>> 
>> 4. On the removal of QAbstractVideoFilter AND QVideoProbe: Disappointed to 
>> hear this. I previously used this for read-only frames for analysis, i.e. 
>> Barcode reading and object detection. How do we do that now?
> 
> I second that. QAbstractVideoFilter used for read-only video (camera)
> data access for QR-code recognition. On mobile platforms, it is very
> important to lower resource usage and zero-copy is very important. We
> barely get 30 FPS on low-end devices.
> Is there an alternative API for that?

See also my answer to Jason. The API offsers a way to lower the resolution of 
the camera if required using QCameraFormat, and the architecture should allow 
to pass the data through more or less without copying. From an implementation 
point of video, this might not yet all be perfect though. But I’d be happy to 
get some use cases, sample code that you’ve been using and other feedback so 
that we can make the API work as good as possible.

Cheers,
Lars

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

Re: [Development] New Qt Multimedia

[Lars Knoll]

> On 26 May 2021, at 16:24, Jason H  wrote:
> 
>> There are still open issues and gaps in the implementation that need fixing, 
>> but the code is now in a decent enough shape to merge it back to dev and 
>> continue on that branch. We will however now have everything ready in Qt 
>> Multimedia for the 6.2 feature freeze, and will be working with an exception 
>> on this module. Especially the support for camera and media capture on 
>> Windows and the Android backend still need more work. The gstreamer backend 
>> for Linux and AVFoundation for iOS and macOS should be in a pretty decent 
>> shape. QNX support is missing right now, and is planned after 6.2.
> 
> So the changes listed in the bullet points look great!
> 
> As someone who has attempted to work with Qt Multimedia on the mobile 
> platforms, I can say that I was looking forward to this.
> 
> I do have a few questions (mobile focused):
> 
> 1. On Android, it looks like you're using the old Camera API and not Camera2? 
> (https://developer.android.com/reference/android/hardware/camera2/package-summary)
>  I found that Camera2 paralleled AVFoundation, so between Camera being 
> deprecated and Camera2 resembling AV Foundation, I am surprised Camera (old) 
> was targeted?

That’s purely because the old code base from Qt 5 used Camera and we didn’t yet 
find time to change that. The intention is to upgrade to Camera2 at some point, 
but we simply didn’t have enough time to do that change until now.
> 
> 2. Recording WAV on Android was a problem.  I get that this was not Qt's 
> fault, but having universal WAV recording would be good. Is it in scope? 
> (Solution was to just do it in Java, grabbing raw PCM data), but iOS could 
> deliver WAV if you told it to in the container format.

There’s a QWavDecoder class in Qt 6 multimedia that can handle both decoding 
and encoding of WAV files. I don’t really want it to become public API, but I 
do think we should have an integrated solution that can be used as a fallback.
> 
> 3. Support for image/video depth data? On iOS, these are mini-images embedded 
> within the image itself. Is it in scope? (Can be from disparity or LIDAR, IR, 
> etc)

Not for 6.2 at least.
> 
> 4. On the removal of QAbstractVideoFilter AND QVideoProbe: Disappointed to 
> hear this. I previously used this for read-only frames for analysis, i.e. 
> Barcode reading and object detection. How do we do that now?

You can get full access to the video data from a QVideoSink through the 
newVideoFrame() signal and mapping the video frame (or converting it to a 
QImage). With that you should have the access to the data that you need. (A 
small detail that’s still missing right now but that I hope to have in place 
for 6.2 is the ability to connect several sinks to a media player or capture 
session, but it’s not really required as you can connect several slots to the 
signal). If you feel like to need more than that, let me know what it is.

Cheers,
Lars





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

Re: [Development] New Qt Multimedia

[Lars Knoll]

> On 26 May 2021, at 14:09, Lars Knoll  wrote:
[snip]
> There are still open issues and gaps in the implementation that need fixing, 
> but the code is now in a decent enough shape to merge it back to dev and 
> continue on that branch. We will however now have everything ready in Qt 
> Multimedia for the 6.2 feature freeze, and will be working with

Of course the ‘now’ was meant to be a ‘not’.

> an exception on this module. Especially the support for camera and media 
> capture on Windows and the Android backend still need more work. The 
> gstreamer backend for Linux and AVFoundation for iOS and macOS should be in a 
> pretty decent shape. QNX support is missing right now, and is planned after 
> 6.2.
> 
> Volker has done a smaller API review round already, but I’d now appreciate 
> more eyes on the code base, both on the API side and implementation. Let me 
> know what you think, and also what doesn’t work.
> 
> Cheers,
> Lars

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

[Development] New Qt Multimedia

[Lars Knoll]

Hi all,

After 5 months of work, I am now preparing to merge the new API and 
implementation for Qt Multimedia back into the development branch.

You can find the first iteration of a merge commit here: 
https://codereview.qt-project.org/c/qt/qtmultimedia/+/351108

With this, Qt Multimedia is probably the module that is changing most between 
Qt 5 and Qt 6. The reason for that is that we had large issues maintaining Qt 
Multimedia during the Qt 5 lifetime, and never really got to a point where it 
offered a consistent experience across all platforms.

The hope is that we can change that for Qt 6. To make this possible, we have 
changed not only parts of the public API, but completely redone its internal 
architecture, especially how multimedia connects to the platform specific 
backends. Apart from cleaning up the backend API and greatly simplifying it, I 
also chose to make it private and remove the plugin architecture around it. The 
backend is now selected at compile time, and we’re now only supporting one 
backend per platform.

The architectural cleanup lead to huge simplifications in the code base. The 
module went from 140k LOC in 5.15 to 73k LOC in Qt 6, while keeping 90% of the 
functionality we had in 5.15 and adding a few things that were missing there. 
This should make it significantly easier to maintain and further develop the 
module over the lifetime of Qt 6.

Here’s the list of largest changes (copy from the commit log of the merge 
commit above):

* New QMediaDevices API to discover available input/output devices
  and get notifications about changes
* New QMediaFormat API to query for supported codecs and file formats
* Refactored playback API, QMediaPlayer and playlist handling are
  fully separated (and can be connected on the app level)
* Simplified QMediaPlayList API to use QUrl instead of the
  QMediaContent/QMediaResource pair.
* Support for multiple audio/video/subtitle streams when playing back
  media
* Better meta data support for audio/video files and individual streams
  inside the file
* New QMediaCaptureSession API as a central class to handle media capture
* QCamera, QMediaEncoder and QMediaImageCapture are to be used together
  with the capture session to define a capturing pipeline
* Removed QCameraFocus, QCameraExposure and QCameraImageProcessing
  and merged those features into QCamera itself
* New QMediaEncoder class to connect to a capture session for encoding
  captured audio/video.
* new QMediaEncoderSettings class to define the audio/video codecs and
  file format to be used when encoding.
* Larger changes to the QML API, it is not symmetric to the C++ API,
  and to the largest part simply uses the public C++ classes
* Rewritten video output pipeline. The new QVideoSink class is the
  main interface between the media player/capture session and an
  output surface.
* Built in support for rendering more uncompressed video formats
  (RGB and YUV), both through QPainter and shaders
* Support for conversion of video frames in all formats to a QImage
* Support for HW accelerated rendering through RHI for the QML
  VideoOutput element
* Support for HW accelerated decoding in many cases
* Cross platform support for audio decoding through QAudioDecoder
* The backend API is now private, so we can adjust it as needed to
  implement new functionality
* Removed the QMediaService/QMediaObject abstraction
* Removed the plugin architecture for backends, backends are now
  chosen at compile time
* Removed the QAudioProve/QVideoProbe APIs
* Removed QSound. Use QSoundEffect instead.
* Removed the Radio API
* Removed QAudioRecorder. Use QMediaCaptureSession/QMediaEncoder
  or QMediaRecorder instead.
* Removed QAbstractVideoFilter. For filtering QML video, use
  shader effects instead.
* Removed QAbstractVideoSurface. QVideoSink replaces it.
* QVideoSurfaceFormat has been renamed to QVideoFrameFormat.
* Significantly reduced the API surface of the backend API (from
  ~40 to 13 classes)
* Fully rewritten gstreamer backend that only relies on base and good
  plugins plus codecs.
* Windows uses WMF exclusively, added camera support through WMF

There are still open issues and gaps in the implementation that need fixing, 
but the code is now in a decent enough shape to merge it back to dev and 
continue on that branch. We will however now have everything ready in Qt 
Multimedia for the 6.2 feature freeze, and will be working with an exception on 
this module. Especially the support for camera and media capture on Windows and 
the Android backend still need more work. The gstreamer backend for Linux and 
AVFoundation for iOS and macOS should be in a pretty decent shape. QNX support 
is missing right now, and is planned after 6.2.

Volker has done a smaller API review round already, but I’d now appreciate more 
eyes on the code base, both on the API side and implementation. Let me know 
what you think, and also what doesn’t work.

Cheers,
Lars

__

Re: [Development] Nominating Andreas Buhr as approver

[Lars Knoll]

Another +1. All reviews of my patches that Andreas has done have been really 
good and thorough :)

Cheers,
Lars

On 29 Apr 2021, at 08:44, Andrei Golubev 
mailto:andrei.golu...@qt.io>> wrote:

+1.

Indeed, Andreas does a great job daily.

--
Best Regards,
Andrei

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Fabian Kosmale mailto:fabian.kosm...@qt.io>>
Sent: Thursday, April 29, 2021 8:29 AM
To: Paul Wicking mailto:paul.wick...@qt.io>>; development 
mailto:development@qt-project.org>>
Subject: Re: [Development] Nominating Andreas Buhr as approver

+1

Andreas has been tremendously helpful in the work on the property system, and 
had contributed both patches and reviews to various other areas. I'm sure he'll 
do a good job as an approver.

--
Fabian Kosmale
Software Engineer

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
fabian.kosm...@qt.io
+49 1638686070
http://qt.io


Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

--


Von: Development  im Auftrag von Paul 
Wicking 
Gesendet: Donnerstag, 29. April 2021 08:20
An: development
Betreff: [Development] Nominating Andreas Buhr as approver

Hi all,


I’d like to nominate Andreas Buhr as approver for the Qt Project.

Andreas has been working with Qt since he joined the Qt Company as a full-time 
employee in Germany about a year ago. I believe his patches [0] spesk for 
themselves. He has also participated actively in reviewing others’ work [1]. My 
impression is that Andreas holds quality in high regard in production code, 
tests, and in documentation, and that he tirelessly works to further our 
quality in all these areas.

I trust he'll use the approver rights responsibly.

[0] - https://codereview.qt-project.org/q/owner:andreas.buhr%2540qt.io
[1] - https://codereview.qt-project.org/q/reviewer:andreas.buhr%2540qt.io

//! Paul
___
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] State of "binary JSON" in 5.15+?

[Lars Knoll]

Hi Brett,

The binary JSON support is deprecated and only there for backwards 
compatibility. It had some issues (e.g. it couldn’t handle large JSON files), 
that’s why we deprecated it. It’s gone in Qt 6. I guess the docs need some 
adjustment though.

Cheers,
Lars

On 13 Apr 2021, at 15:43, Stottlemyer, Brett (B.S.) 
mailto:bstot...@ford.com>> wrote:

Hi,

I was at the Contributor’s Summit where it was discussed, so I know there were 
good reasons to deprecate the binary json format.  The actual changes looks to 
have been done in https://codereview.qt-project.org/c/qt/qtbase/+/265312.

IIUC, the original intent was that parsing the JSON creates a lookup table to 
speed up subsequent access, and the binary format saved that table to disk (or 
for streaming).  This allowed “opening the JSON” (technically no longer JSON?) 
much more quickly.

Is such a mechanism still available currently?  Or is parsing the data from 
scratch necessary now?

For reference, I tried the deprecated calls and also used the conversion tool 
to convert to CBOR and tried reading that.  With a particular (~20MB) JSON file 
from a REST call, parsing the CBOR version of the file was about twice as fast 
as JSON, while the binary JSON format was about 2.5x *slower* than parsing the 
JSON (just measuring the document creation time).

FWIW, if the capability is no longer available, the overview for Qt JSON 
(https://doc.qt.io/qt-5/json.html) should probably have “It also contains 
support for saving this data in a binary format that is directly "mmap"-able 
and very fast to access” removed.

Thanks!
Brett


___
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] Changes to the property system

[Lars Knoll]

Hi all,

As you all know, we’ve been doing a lot of work for Qt 6.0 to bring the concept 
of property bindings into Qt Core and make it accessible from C++ 
(https://www.qt.io/blog/property-bindings-in-qt-6). Unfortunately, we lacked 
the time to do extensive porting of existing properties to the new system 
before we released 6.0.

A lot of that porting effort has now happened or is ongoing for both 6.1 and 
6.2. In general, the new property system does its job very well, but we did 
find a couple of items that required changing. Fortunately all of those changes 
can be done in a way that is binary compatible with 6.0.

The binding system in Qt 6.0 tries to evaluate bindings lazily, ie. when the 
property is being read. The advantage of such a system is that bindings would 
not get re-evaluated multiple times if several of the properties the binding 
depended upon got changed, leading in theory to less computations.

What we already found out before 6.0 times was that some of our existing 
properties could not easily be ported to a lazy binding system, as the property 
setters were executing code that triggered certain side effects. Thus we did 
include a private class called QObjectCompatProperty in 6.0 already that did 
evaluate bindings immediately, leading to a hybrid between immediate (eager) 
and lazy binding evaluations for the system.

During porting, we now found that

* A lot of existing properties (probably as much as 50%) require immediate 
binding evaluation for a straightforward port
* Changing those properties to be compatible with lazy binding evaluation 
requires in many cases a complete rewrite of the class in question, amounting 
to huge amounts of work and lots of potential regressions
* As many properties can not be lazy, there is a lot less benefit of lazy 
binding evaluation than we hoped for
* The Qt Quick architecture uses a rendering thread to decouple QML item 
changes and rendering. There is a sync point between both threads where the 
rendering thread reads out properties from the main thread to update itself. 
That sync point needs to be kept minimal to allow both threads to run as 
independent as possible. Lazy binding evaluation would cause the bindings to 
get evaluated during that sync period and from the wrong thread.

All of this lead us to revisit parts of the internal architecture of the new 
C++ binding system over the last two months. The conclusion we came up with was 
to remove the lazy binding evaluation and instead add a feature that would 
allow us to dynamically group property updates together and only update 
bindings once all property updates inside the group are done.

This system will allow us to avoid repeated binding evaluations for most cases 
where they appear today (e.g. when instantiating new components or when doing 
timed updates through animations). The advantage is that this will work for all 
properties, not only for part of them as with the mixed lazy/eager system that 
we have in Qt 6.0.

You can find those changes in 
https://codereview.qt-project.org/c/qt/qtbase/+/332557/34 and related patches. 
We’re currently working on merging those for Qt 6.2. 

They should have little direct impact on anybody using C++ based property 
bindings and keep the main benefits we are getting from the new property 
system: A C++ API for bindings, faster binding execution compared to what we 
had in the QML engine in Qt 5.15 and the ability to use bindings without a QML 
engine in place.

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

Re: [Development] New features in CI

[Lars Knoll]

> On 27 Mar 2021, at 11:23, Giuseppe D'Angelo via Development 
>  wrote:
> 
> Hi,
> 
> On 12/03/2021 17:22, Tor Arne Vestbø wrote:
>> We we please improve this by:
>>  1. Attempt to cherry-pick the commits in the tested branch into dev, before 
>> falling back to a merge commit (if needed)
>>  2. If we need to merge:
>>- Reflecting the CI as the author of the merge commit
>>- Reflecting the set of commits in the merge commit message, e.g. based 
>> on git shortlog
>>- Using a commit message subject that explains what’s going on, eg.
> 
> This situation is getting a bit out of hand, with a now almost half of 
> commits in qtbase/dev being merge commits. I'm not quite convinced this is a 
> good thing.

I agree that it looks messy and shouldn’t be required in 90% of the cases. 
Let’s try to improve this and cherry-pick where possible, please.

Cheers,
Lars

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

Re: [Development] User-defined literals for QString (and QByteArray)

[Lars Knoll]

On 5 Mar 2021, at 12:08, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:


On 3 Mar 2021, at 16:53, Andrei Golubev 
mailto:andrei.golu...@qt.io>> wrote:

QString hello = u"Hello"; // oops, compilation error

This seems like a bug though? From an API point of view, I’d expect this simple 
assignment to JustWorkTM, without requiring syntactic sugar all over the place. 
Shouldn’t we fix this, so we don’t need (or leave optional) an explicit _qs 
suffix?

The explicit _qs suffix would basically replace QStringLiteral. We can’t have a 
generic QString(char16_t *) constructor that doesn’t copy the data.

I wish we had a good way of adding that overloaded constructor to QString. 
Unfortunately, we have lots of API that is overloaded on both QString and 
QStringView. Adding the constructor to QString will then cause ambiguities 
wherever we have overloaded API taking both a QString and a QStringView.

I wish there was a way to tell the compiler to prefer one conversion over the 
other ("if you have the choice, always use QStringView and not QString”), but 
C++ doesn’t have a way to do that.

Cheers,
Lars

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

[Development] New features in CI

[Lars Knoll]

Hi all,

While the CI maintenance break today took a little longer than usual, it also 
came with two very nice new features that will hopefully make everybody’s life 
easier.

First of all, you can now find a ‘Precheck' button in gerrit. That button 
triggers a full CI test run of the Sha1 in the change and will post back the 
result of that run as a comment. This should make it a lot easier to test some 
of your changes before manual reviews start or at any other time when you need 
them. But please be aware that those runs do consume resources from the CI 
system, so you shouldn’t just hit that button for anything.

Secondly, we have now added a new mode on how CI integrations work. So far all 
changes that got staged since the last CI run would be tested together. This 
had the downside that we would be testing a large amount of independent changes 
together in one CI run. If one of those changes had a problem, all changes 
would get rejected. Worse, many people would then simply hit the ‘Stage’ button 
once again assuming it wasn’t their change that caused the problem. You 
probably have all experienced this in some form or another.

To fix this, we have now added a new feature (called parallel staging 
branches), where CI rounds are not serialised anymore. Instead, COIN will start 
a new CI run 15 minutes after a change (or a set of changes) got staged. It 
will start that run independently of whether another CI run is currently 
happening. If a staging branch passes, all the changes contained in that branch 
will be merged into the target branch (can be a fast-forward merge). If the 
merge produces a conflict, the staging branch will get rejected even if it 
passed CI.

This means that COIN will usually only test changes that are being staged 
together. The advantages are that you can more easily pin down a change that 
caused a CI failure, and that your changes will not get rejected because a 
buggy change got staged in the same CI run (at least it’s a lot less likely).

The one drawback is that we can in some rare cases end up with a repository in 
a state where two staging branches passed CI and didn’t conflict when merging 
them, but the merged state does not pass CI anymore for some reason. 

In that case the branch will be blocked until someone stages a fix for the 
problem. But we do expect this to happen rather seldom, so I do believe that 
the benefits far outweigh the drawback.

For now this feature is only enabled in qtbase/dev, but if it works out well, 
we will most likely enable it for further repositories and branches.

Last, but not least I’d like to thanks Toni Saario and Jukka Jokiniva for doing 
all the the hard work :)

Enjoy!
Lars





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

Re: [Development] Qt 6.1 Feature Freeze is in effect now

[Lars Knoll]

Ok, as long as they have a low risk of breaking modules depending on qtbase :)

Cheers,
Lars

> On 1 Feb 2021, at 14:27, Giuseppe D'Angelo  wrote:
> 
> Il 01/02/21 14:03, Lars Knoll ha scritto:
>> Do you have a list of pending features that you think should still go into 
>> 6.1?
> 
> Just 3-4 patches of mine which have been sitting around approved, but 
> couldn't get merged due to CI trouble last week.
> 
> 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

Re: [Development] Qt 6.1 Feature Freeze is in effect now

[Lars Knoll]

Hi Guiseppe,

> On 1 Feb 2021, at 13:48, Giuseppe D'Angelo via Development 
>  wrote:
> 
> Il 01/02/21 13:34, Jani Heikkinen ha scritto:
>> Qt 6.1 Feature Freeze is in effect now. So please do not add any new 
>> features, API changes ect in 'dev' anymore until we have done branching from 
>> 'dev' to '6.1'. We are trying to do branching from 'dev' to '6.1' as soon as 
>> possible but at first we need to get full dependency update round done.
> 
> Can we get a week of delay for this, given the CI has been down last week? Or 
> at least a window to retarget approved 6.1 features into the 6.1 branch.

Do you have a list of pending features that you think should still go into 6.1?

Let’s have a look at what’s missing and then decide on exceptions :)

Cheers,
Lars

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

Re: [Development] Request to rename module qtscxml to qtstatemachine

[Lars Knoll]

> On 21 Jan 2021, at 11:14, Edward Welbourne  wrote:
> 
> Karsten Heimrich (21 January 2021 10:49) wrote:
>> [...] I would like to propose/request to rename the module to
>> qtstatemachine to reflect the widened code base. Jira task:
>> QTBUG-89837
> 
> Sounds like a more accessible name to me - I'd have had to look up SCXML
> to find out what it means, where the proposed name gives me a fairly
> good clue to what it means.  So
> 
> +1

Another +1.

Cheers,
Lars

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

Re: [Development] Nominating Max Goldstein as an approver

[Lars Knoll]

+1

Cheers,
Lars

> On 14 Dec 2020, at 11:21, Cristián Maureira-Fredes 
>  wrote:
> 
> +1
> 
> Additionally:
> Max managed to solve many issues on the Python+QML integration for Qt6.
> 
> Cheers
> 
> On 12/14/20 9:13 AM, Ulf Hermann wrote:
>> Hi,
>> I would like to nominate Max Goldstein as an approver for the Qt Project.
>> Max has been contributing to the Qt project for a while now. He wrote the 
>> qmlformat tool, implemented the JavaScript URL object for QML, and 
>> contributed to pyside.
>> Here is the list of his changes on gerrit: 
>> https://codereview.qt-project.org/q/owner:max.goldstein%2540qt.io
>> Disclaimer: I'm working in the same area and if we weren't working from home 
>> we'd share an office.
>> best regards,
>> Ulf
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
> 
> -- 
> Dr. Cristián Maureira-Fredes
> R&D Manager
> 
> The Qt Company GmbH
> Erich-Thilo-Str. 10
> D-12489 Berlin
> 
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Jouni Lintunen
> 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] Timeline to require GCC 11 in MinGW

[Lars Knoll]

> On 9 Dec 2020, at 21:34, Thiago Macieira  wrote:
> 
> They've finally fixed the thread_local problem
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562
> 
> So when can we require a fixed version of GCC or require Clang for MinGW?

Good question. Is there a chance to move over to one of those for Qt 6.1?

Cheers,
Lars

> 
> https://codereview.qt-project.org/c/qt/qtbase/+/234362
> https://codereview.qt-project.org/c/qt/qtbase/+/234364
> https://codereview.qt-project.org/c/qt/qtdeclarative/+/234360
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel DPG Cloud Engineering
> 
> 
> 
> ___
> 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] Making Binary Incompatible Changes after Qt 6.0

[Lars Knoll]

> On 9 Dec 2020, at 18:49, Thiago Macieira  wrote:
> 
> On Wednesday, 9 December 2020 02:00:29 PST Benjamin TERRIER wrote:
>> Back to the topic, wouldn't it be acceptable to break BC before 6.2 release?
>> I mean Qt 6 isn't really complete until 6.2, so if a break is required it
>> kind of makes sense to make it happen before everyone has made the switch
>> from Qt 5 to Qt 6.
> 
> That would effectively mean 6.0 and 6.1 are duds and should not be used. We 
> should have called them 5.98 and 5.99 then.
> 
> No, we either break BC before May 2021, before adoption really starts, or we 
> wait until 2025. Anything in-between is not acceptable.

I agree with that. If we have good enough reasons, we can consider this for 
6.1, but I would not want to do it after that.

But we can of course consider shortening our time between major releases. As 
Volker mentioned, we were doing major versions more often in the past, and 3-4 
years instead of 7-8 is something we should really consider.

Cheers,
Lars

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

[Development] Qt 6.0 RC and timelines for 6.1 and 6.2

[Lars Knoll]

Hi all,

First of all, I wanted to thank everybody for the hard work towards getting Qt 
6.0 out of the door. We now have a first RC out, so we’re definitely getting 
very close to the 6.0.0 release.

With that and the fact that we now have a 6.0 branch, it’s also time to start 
looking a bit ahead towards 6.1 and 6.2.

We have long discussed, that the timing of our feature releases to be just 
before summer and Christmas vacation is a bit unfortunate, as we have little 
slack for delays without going into the vacation period. Especially the 
releases in December have sometimes been difficult in that respect. So we’d 
like to push the schedule a bit and move the minor releases towards a 
Spring/Autumn schedule.

A somewhat shorter release cycle directly after 6.0 is probably a good idea 
anyway, as we will probably still need to do changes/fixes that don’t quite fit 
with our policy for patch level releases.

So the idea is to shorten the release cycle for Qt 6.1 a bit and focus mainly 
on bug fixing and stability for that release. We’d aim for a feature freeze by 
the end of January, and a final Qt 6.1.0 release end of April.

6.2 would then also happen a bit earlier, with a feature freeze in June and a 
release end of September.

Content wise, I believe we’ll start seeing more and more of the add-ons from Qt 
5 being supported over the next 6-9 months, and I believe that with Qt 6.2 we 
will have brought most modules that we supported in Qt 5.15 over to Qt 6. 

Cheers,
Lars

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

Re: [Development] QVariant comparison in Qt6 (URGENT)

[Lars Knoll]

> On 23 Nov 2020, at 09:57, Giuseppe D'Angelo via Development 
>  wrote:
> 
> Hi,
> 
> On 22/09/2020 16:17, Thiago Macieira wrote:
>> And especially if there's no impact to how the user uses the API.
>>> 1)
>>> std::optional compare();
>>> 
>>> 2)
>>> enum class Ordering { Less = -1, Equal = 0, Greater = 1, Unordered = 0xff
>>> };
>>>  Ordering compare();
>>> 
>>> 3)
>>> Implement a Qt replacement for std::partial_ordering (could use the std
>>> stuff if C++ 20 is available) and use that.
>> I'd rather stay simple and allow extending for  where more details
>> are necessary.
>> For that, I think #1.
> 
> I'm reopening this old thread (which I somehow missed) because eventually #1 
> was implemented. But optional is the wrong API for a comparison result.
> 
> I've quickly implemented 3) and pushed it here. It's only missing docs.
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/322900
> 
> (includes the rationale of why optional is the wrong datatype)
> 
I like this approach.
> 
> Still in time to target 6.0.0?

I guess it’s now or never ;-)

Have you checked that it doesn’t cause issues in other modules? The API is new, 
so I doubt it’s used widely. 

Cheers,
Lars

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

Re: [Development] Qt 6 co-installability with Qt 5

[Lars Knoll]

On 18 Nov 2020, at 00:41, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

On Tue, 17 Nov 2020 at 14:09, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

On Tuesday, 27 October 2020 09:34:44 PST Thiago Macieira wrote:
Have we fixed it?

I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any
binary with the same name as Qt 5 did.

Lars and I just had a quick discussion on IRC about this and here's what we
propose. Ground rules and caveats:

1) MOST tools do not need to be in $PATH for most users. We developers are not
most users. For us, setting PATH is acceptable. We're also likely the only
audience to have more than one 5.x or 6.x Qt version installed.

2) This recommendation need not be supported by the buildsystem in time for
6.0.0, but needs to be as early as possible and by 6.1 at the latest. This
recommendation allows Linux distributions to apply workarounds meanwhile,
other buildsystems to adjust (read: Meson), and for us to write docs and QUIP.

3) there's a question of cross-compilation relating to qmake and host tools,
which I have not followed and do not understand the current state of. Need
input here.

With that in mind, our recommendation is as follows:

a) ALL tools be installed to a binary directory that is not $prefix/bin
b) SOME tools be symlinked/hardlinked/stubbed into $prefix/bin, with a suffix
 (we recommend a simple "6" instead of "-qt6")
c) ADDITIONALLY, some further tools can be present unsuffixed

Thinking a bit more about this, I wonder how many applications _really_ need a 
version.

To start with, I think it’s important to recognise a difference between 
developer oriented tools and tools targeting end users.

Most of our developer oriented tools are (or can be) dependent on the exact 
version of Qt installed. Thus the problem is larger than just a Qt 5 vs Qt 6 
thing.

Those tools should just stay in a version specific directory and should IMO not 
be exposed in the generic path for end users (moc should for example never end 
up in /usr/bin). Instead the correct version is found by the build system and 
called from there. And developers needing direct access to them should adjust 
their path to include those tools.

For most end user facing tools, I wonder whether we actually need to support 
co-installation. The examples listed just below (linguist etc.) are backwards 
compatible, and it should be ok to simply install the latest version, similar 
to what is done with qtcreator.

Once we have that, the question is what is left that actually has to have a 
versioned name?


The question is what tools are those in lists (b) and (c). Starting with the
easiest (c):
- linguist
- qdbus
- qdbusviewer

Those are user-facing tools that definitely do not depend on Qt version. It's
up to the implementer to decide which Qt version they want these tools to be
and any choice is fine. My guess is that for two of the three, it will depend
mostly on Look-and-Feel with the desktop. But since these are an implementer's
choice, Qt installation never installs those tools with the unsuffixed names
by default.

Agreed to all above.

Then there's the question of which tools we recommend be in $PATH with a
suffix (list (b)). Please expand on this list if necessary, with a reason.
Here's the minimum list:

qmake6 entry point for building qmake-based applications, situation
   similar to /usr/bin/python (see [1])

I am not yet 100% convinced it is. This is a build tool after all, and even 
changes with minor versions of Qt. I know Linux distributions do only ship one 
minor version, but many of our users have to manage multiple minor versions of 
Qt as well. And renaming qmake with every minor version is a no-go.

qml6   I don't understand why, but I'm told it's necessary

It’s a runtime for running qml files without a C++ entry point. But we can 
actually decide that this is a developer oriented tool and not have it linked 
into /usr/bin.

qtdiag6entry point for debugging problems with Qt 6
qtpaths6   because knowing the path in order to run the tool to get
   paths sounds weird. Having this in $PATH allows us to
   help users get to the other, debugging tools (qtplugininfo,
   qmlplugindump, etc.)

Possibly also:

assistant6 for reading Qt 6 help files when not using Qt Creator
designer6  for those not using Qt Creator and needing to use Qt 6 plugins

Offtopic, but I wonder how much those standalone apps are still being used 
today.

Also agreed. I would consider assistant6 and designer6 to be included
in list (b) due to past experience.

Tools I don't know if they should or shouldn't be in this list:

- pixeltool: it's a screen magnifier, never used it before, but
clearly not something used at build time. Sounds like a user-facing
app for me.

- qtplugininfo: I sincerely don't know how it's being used.

- qtwaylandscanner: same as above.

- tracegen: same as a

Re: [Development] What's Q_PRIMITIVE_TYPE for?

[Lars Knoll]

> On 13 Nov 2020, at 18:49, Thiago Macieira  wrote:
> 
> On Friday, 13 November 2020 00:19:41 PST Lars Knoll wrote:
>> I would hope that we’ll get mechanism to move them and help from the
>> compiler  and/or C++ standard here. This is especially needed for
>> relocatable objects, as that makes a huge performance difference, but make
>> a big difference for primitive types as well.
> 
> For relocating, I'm sure the language will provide a solution and compilers 
> will likely give us a grace period to adjust. I don't think there are many 
> people (I don't know any) that oppose the idea of relocating objects, even if 
> they oppose the actual solution chosen to do that (like a core language 
> extension to provide a destructive move constructor or a moving destructor).
> 
> Actual C++ primitive types won't be affected because they are trivial. My 
> point again is that we are doing that for non-trivial types.

And we’ve been doing that for 15 years now. Changing the implementation we’re 
using can be done in a minor release, so I’d say we fix it when there’s a need 
to fix it. It does work currently, and if new compilers or language features 
require fixes let’s do those once the compilers or language features are 
available.

Cheers,
Lars

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

Re: [Development] What's Q_PRIMITIVE_TYPE for?

[Lars Knoll]

> On 13 Nov 2020, at 09:06, Thiago Macieira  wrote:
> 
> On Thursday, 12 November 2020 23:45:35 PST Lars Knoll wrote:
>> Huh? In a release build assertions also expand to nothing. So it does remove
>> many checks. Opposed to that, a debug build or one with address sanitiser
>> enabled, could check those kind of things more thoroughly.
> 
> Sorry, we may be miscommunicating. Let me be clear on what I meant:
> 
> Compilers are likely to implement object lifetime tracking in the near future 
> and make strict aliasing and dead code elimination passes based on the 
> dynamic 
> type of a memory object. This is without extra memory consumption -- it's not 
> ASan. Since our containers and the Standard Library's are templates, the 
> majority (or entirety) of the code is available for the compiler to make 
> analyses of.
> 
> Therefore, skipping the proper constructor calls can cause miscompilation in 
> the near future. This is what I meant by this paragraph, saying we can ignore 
> now, but will need to deal with it.

I would hope that we’ll get mechanism to move them and help from the compiler  
and/or C++ standard here. This is especially needed for relocatable objects, as 
that makes a huge performance difference, but make a big difference for 
primitive types as well.
> 
>>> I propose we ignore the lifetime issues *for* *now*. We need a proper
>>> language solution to declare objects' lifetime has started when we do
>>> either of the three operations above, without loss of performance
>>> afforded by the memcpy / memset. So either the language gives us a
>>> std::launder-like interface to bless the fait accompli or the compilers
>>> give us equivalent performance without such an interface. The relocation
>>> of non-trivially copyable types will likely have a language update
>>> because the current direction seems to include adding a destructive move
>>> operation.
> 
> [cut]
>> I agree that (1) is probably not be worth it, especially if it means that we
>> have to largely cut down on the amount of classes that can be marked as
>> primitive by default.
>> 
>> (2) and (3) are clearly worth it. And for types with trivial copy/move
>> operations, the standard even says that memcpy’ing them is ok.
> 
> It does, for trivially copyable types. The problem is that Q_DECLARE_TYPEINFO 
> with Q_PRIMITIVE_TYPE allows us to apply the same code path to non-trivial 
> types. This may run afoul of compiler optimisations in a year or two.
> 
> With that in mind, how much risk do we want to accept?

How likely is that though? I’d say let’s fix it when it happens. It’s possible 
to restrict when to apply those optimisations in a later minor/patch release.

Cheers,
Lars

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

Re: [Development] What's Q_PRIMITIVE_TYPE for?

[Lars Knoll]

> On 13 Nov 2020, at 07:48, Thiago Macieira  wrote:
> 
> On Thursday, 12 November 2020 07:07:53 PST Lars Knoll wrote:
>> So except for the memset(0) for default construction, Primitive and Trivial
>> have the same conditions in your list here. My proposal would be to drop
>> the memset(0) optimisation and with that unify those two groups.
> 
> Not exactly. The distinctions come up at these points (see 2 and 3):
> 
> 1) extending the container with new elements (resize() with sufficient 
> capacity already allocated or constructor with element count): memsettable 
> types can benefit from memset(0), as can most trivial types, except those 
> containing pointer-to-member-object.
> 
> 2) reallocating the container: relocatable types (which include all trivially-
> copyable types) can be relocated by memcpy, which in turn means they can be 
> relocated by realloc().
> 
> 2b) relocating elements without reallocating (insertion): same as #2
> 
> 3) detaching: trivially copyable types can be copied with memcpy(), but 
> relocatable ones cannot
> 
> Q_PRIMITIVE_TYPE is currently something more restrictive than trivial type 
> because of #1.

Correct, that’s exactly what I said. So if we remove the memset() optimisation 
(that is pretty much only used for resize()), all trivial types can be treated 
as primitive. resize() is not really a very common operation, so we wouldn’t  
loose a lot even if the compiler doesn’t manage to fully optimise it. 
> 
>> (Note: I'm completely ignoring the lifetime issues at just blessing a block
>> of memory and saying "there are N objects here". Thiago is right, we
>> shouldn't ignore that. But I'm not sure how, except by biting the bullet
>> and calling constructors/destructors, then relying on the compiler to do
>> the right thing.)
>> 
>> Those lifetime issues need to be tackled differently. One option could be to
>> abandon all our optimizations in a checked build, and only enable them in
>> release mode.
> 
> We have to assume that any build with optimisations turned on means a checked 
> build. Therefore, your proposal is self-contradictory.

Huh? In a release build assertions also expand to nothing. So it does remove 
many checks. Opposed to that, a debug build or one with address sanitiser 
enabled, could check those kind of things more thoroughly.
> 
> I propose we ignore the lifetime issues *for* *now*. We need a proper 
> language 
> solution to declare objects' lifetime has started when we do either of the 
> three operations above, without loss of performance afforded by the memcpy / 
> memset. So either the language gives us a std::launder-like interface to 
> bless 
> the fait accompli or the compilers give us equivalent performance without 
> such 
> an interface. The relocation of non-trivially copyable types will likely have 
> a language update because the current direction seems to include adding a 
> destructive move operation.
> 
> But we will not be able to ignore the problem forever and I think the bill 
> will come due before the end of the Qt 6 lifetime. For that reason, I am 
> asking we decide which of the above is worth. I think:
> 
> 1) not worth memsetting and very likely the compilers can be fixed to 
> optimise. The benefit of memset compared to the whole operation (including 
> malloc()) may not be worth the hassle
> 
> 2) worth it because the language seems to be going in the direction we want 
> and have showed the way for the last 15 years (relocatable types, destructive 
> move)
> 
> 3) uncertain; if the compilers do #1, it's likely they'll do #3 too.

I agree that (1) is probably not be worth it, especially if it means that we 
have to largely cut down on the amount of classes that can be marked as 
primitive by default.

(2) and (3) are clearly worth it. And for types with trivial copy/move 
operations, the standard even says that memcpy’ing them is ok.

Cheers,
Lars

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