Cristián Maureira-Fredes (26 March 2021 10:15) wrote:
> I haven't get any critical comment regarding
> this being a bad idea, so I would like to take your +1s
> and continue with the next steps.
>
> I would like to request a new repository:
>
> Name: Qt Project Web
> Description: Repository for
Hi all,
I'd like to nominate Andrei Golubev as an Approver.
He has been doing sterling work reviewing changes for the last year.
Here's a list of what he's reviewed
https://codereview.qt-project.org/q/reviewer:andrei.golubev%2540qt.io
and his own changes
On 3 Mar 2021, at 16:53, Andrei Golubev
mailto:andrei.golu...@qt.io>> wrote:
>> QString hello = u"Hello"; // oops, compilation error
Tor Arne Vestbø (5 March 2021 12:08) replied:
> This seems like a bug though? From an API point of view, I’d expect
> this simple assignment to JustWorkTM, without
On Mon, Mar 01, 2021 at 01:25:50PM +, Lars Knoll wrote:
>> 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.
Oswald Buddenhagen (1 March 2021 17:02)
Joerg Bornemann (26 February 2021 16:07)
> I noticed that we still have fixqt4headers.pl in our bin directory.
> For the uninitiated, this is it's documentation:
> https://doc.qt.io/qt-5/portingcppapp.html
>
> That page is already gone in Qt6.
>
> Can fixqt4headers.pl be removed from Qt6?
Seems
On 2/4/21 12:20 PM, Volker Hilsheimer wrote:
>>> The 6.1 branch’s sha1 is whatever the sha1 in dev was when the
>>> branch was created. Things start to diverge from there, but at
>>> branching sha1, the new branch’s consistent set is whatever
>>> .qtmodules and dependencies.yaml states at that
> I like the simplicity. No bot fiddling and no "imminent not-yet-created
> branch" concept.
+1
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On 3 Feb 2021, at 09:31, Joerg Bornemann wrote:
>> Let's say I have a change for qtbase's dev branch that is supposed to
>> be cherry-picked to 6.1. What happens if this change hits qtbase
>> between those two points in time:
>>
>> - final dependency update sha1s are fixed, full update round
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
Nibedit Dey (14 January 2021 22:18) wrote:
>>> We will wait for the Qt maintainers to take a call on this topic and
>>> let us know the decision.
On Fri, Jan 15, 2021 at 3:17 PM Edward Welbourne wrote:
>> Well, this mailing list *is* where and how the Qt maintainers ma
Nibedit Dey (14 January 2021 22:18) wrote:
> Qt5 repo contains many branches and some have ambiguous names with
> respect to the Qt version. e.g: It is not clear whether the dev branch
> is applicable to Qt5 development or Qt6.
That ambiguity, at least, would go away if the module were called
Volker Hilsheimer (14 January 2021 10:50) wrote:
> The init-repository script does some extra work that is supposed to
> give people a leg up though, such as setting up commit hooks and
> remotes in all submodules.
It also provides mechanisms for selecting what set of modules you want
checked
Volker Hilsheimer (13 January 2021 14:37) wrote:
> Let me make a more radical proposal:
>
> The information about which modules depend on which others modules
> lives in each module’s dependency.yaml file. This information includes
> the sha1 of the modules it has last been successfully tested
NIkolai Marchenko (13 January 2021 13:07)
> that's ... kinda what you're supposed to avoid... at least as far as I
> understand the convo earlier. so that two major versions aren't pushed
> to the same repo confusing people.
ah, I think I see the source of the confusion. IIUC, Qt 4 was a
On Mittwoch, 13. Januar 2021 12:31:50 CET Eric Lemanisser wrote:
that's the obvious choice, if it was not already used by qt4.
On 13 Jan 2021, at 12:38, Allan Sandfeld Jensen
mailto:k...@carewolf.com>> wrote:
>>> Then rename the qt4 repo, it is not actively maintained anymore and
>>> only
I just wrote:
> let's create a ticket in Jira and sketch out what we can do.
and I now see you've filed that ticket while I was writing, QTBUG-89824,
so let's take any further discussion there,
Eddy.
___
Development mailing list
Wang Gary (25 December 2020 17:40) wrote:
> Hello,
Hello Gary, likewise.
As Thiago already said, you came to the right place,
albeit while many of us were on vacation.
> The first issue is, in order to get QCalendar support a new calendar
> system, it seems like I need to subclass
Jani Heikkinen (22 December 2020 09:29)
> Lars made a new proposal, see his comment in
> https://codereview.qt-project.org/c/qt/qtbase/+/324440
>
> Basic idea would be
>* We will create one release note for the release instead of
> separate changes file in each submodule
>* Release
>>> I'm guessing you meant generic / special. I'm more keen on keeping
>>> everything deprecated, but with a special macro. (Or maybe just bump
>>> the deprecation version to 6.0 instead of 5.15?)
On 24/11/2020 16:29, Edward Welbourne wrote:
>> I think changing th
On 23/11/2020 08:48, Fabian Kosmale wrote:
>> I think we should at least_somehow_ deprecate operator<; but I'm not
>> sure if it should be a special deprecation macro, or a special one.
Giuseppe D'Angelo (23 November 2020 15:47) wrote:
> I'm guessing you meant generic / special. I'm more keen on
Lars Knoll (29 September 2020 20:48) wrote:
>> I hope that Eddy can create an updated header diff for the modules
>> that are part of 6.0 to make reviewing easier.
On 1 October 2020 at 18:51 I wrote
> Done.
> Only qtbase, qtdeclarative, qttools, qtwayland and qt3d have changes
> relative to the
Lars Knoll (29 September 2020 20:48)
>> I hope that Eddy can create an updated header diff for the modules
>> that are part of 6.0 to make reviewing easier.
On 1 October 2020 18:51 I replied:
> Done.
Just a note on the qtbase review, since this has caught a few of us out
(and it took me a while
Lars Knoll (29 September 2020 20:48)
> I hope that Eddy can create an updated header diff for the modules
> that are part of 6.0 to make reviewing easier.
Done.
Only qtbase, qtdeclarative, qttools, qtwayland and qt3d have changes
relative to the previous patch set, though.
The code to treat
Jani Heikkinen (24 September 2020 09:44) wrote:
> Qt 6.0 new feature page (https://wiki.qt.io/New_Features_in_Qt_6.0) is
> empty! Please fill most important items there immediately; we should
> have most of things there already in Alpha release even polishing can
> happen also in Beta phase
I've
On 17 Sep 2020, at 11:37, André Hartmann wrote:
>> I like to propose Alex Trotsenko as approver.
Samuel Gaist (17 September 2020 11:51)
> +1
Also +1 - and there was I thinking he surely was an approver already.
Definitely way past time to catch up on that,
Eddy.
Alex Blasche (7 September 2020 09:58)
> I suggest we exclude reviews for the modules which are not part of Qt
> 6. It greatly reduces the effort. When a module comes back
> (e.g. during 6.2) then we have to run a complete 5.15..6.2 review
> anyway.
Sounds fair enough. At first sight.
Now I just
Hi all,
I have just pushed the first commits for the Qt 6 API change review.
https://codereview.qt-project.org/q/topic:api-change-review+status:open
These commits are generated by scripts in qtqa/scripts/api-review/,
which have some updates to (among other things) ignore as boring:
* additions
Martin Koller (14 August 2020 17:06) wrote:
> I found myself getting an empty list when using
> QHelpEngineCore::documentsForIdentifier(id) but getting 1 element when
> using the deprecated QHelpEngineCore::linksForIdentifier(id).
Definitely sounds like a bug, although I find no
Il 25/08/20 07:49, Thiago Macieira ha scritto:
>> But how about models? This is an honest question. Does it make sense
>> for tables and lists that big? Note that an item*view* has a purpose
>> of being viewed, so how does one display such a huge list, tree or
>> table?
Giuseppe D'Angelo (25
Jani Heikkinen (11 August 2020 07:09)
> if the correct behavior is the first one then the script doesn't need any
> change?
That sounds plausible for everything after the first release of each
branch, but less convincing for the .0 release: when Qt 6.0 is released,
surely we don't want to repeat
On 7/23/20, 3:13 PM, "Volker Hilsheimer" wrote:
>> But why would we calculate the volume if nobody cares about the volume? :)
Stottlemyer, Brett (24 July 2020 13:45) replied:
> Qt Remote Objects. I've got a headless service on one device, and a
> remote UI for interacting with it. When signals
On Thu, 16 Jul 2020 10:32:08 +
Edward Welbourne wrote:
>>> [...] let me first give an introduction here, and answer some of your
>>> question.
>>
>> I have turned a large chunk of that into
>> https://wiki.qt.io/QProcess
Christian Kandeler (16 July 20
Il 16/07/20 12:43, Volker Hilsheimer ha scritto:
>> For pre-C++20 (where it’s possible to have zero-size structs), and
>> for compilers that don’t respect the [[no_unqiue_address]] attribute,
>> all these struct-instances are put into a union. In that case, a
>> class using QProperty will be
Thiago asked about QProperty, particularly
requesting an update to a wiki page about library coding conventions.
Ulf Hermann (16 July 2020 11:19) replied
> Do you mean https://wiki.qt.io/Coding_Conventions ?
Quite a few wiki pages could do with an update: most obviously:
Hi Bruno,
In addition to what Thiago said, about contributing in general, for
future reference, The Qt Project does also have a security policy [1],
which outlines the process for handling vulnerabilities. Given that
this discussion has happened in public already, the confidentiality
aspects of
Am 01.07.2020 um 23:21 schrieb Thiago Macieira:
>>> Re: https://bugreports.qt.io/browse/QTBUG-84739
>>> Summary: Qt 5.15 has an unintentional change in behaviour that has
>>> broken existing applications. We need to decide whether to:
>>> a) leave as-is
>>> b) revert permanently
>>> c)
>> BTW, any chance we can bait-and-switch, renaming QStringView to
>> QUtf16StringView and rename QAnyStringView into the newly liberated name?
Philippe (25 June 2020 08:40) asked:
> When we deal with strings, the "Uff" affix is unecessarily verbose.
>
> I mean,
>
> QStringView16
>
> is
Mitch Curtis (24 June 2020 10:49) wrote:
> Gerrit admins, can you please create the repository? :)
I believe the recommended process here is to open a Jira ticket.
You can reference your mail in the list's archive as evidence that
it's warranted. Probably QTQAINFRA has a Gerrit section.
Marc Mutz (24 June 2020 09:32) wrote
> My Qt 5-era changes to QLatin1String (adding QL1S::arg(), enabling
> QL1S as a type for date/time formats, overloading QtJSON functions for
> QL1S) have shown how dramatic the effect of 8-bit string values
> without constructing a QString first really is,
Kevin Kofler (16 June 2020 12:08)
>>> What "shiny new features"? All that a real-world application such as
>>> KWrite really needs from the operating system has been there at
>>> least since the 1990s, possibly since the 1970s.
Edward Welbourne wrote:
>&
Edward Welbourne wrote:
>> So my bad, I said our product would only work on an ancient O/S or
>> two, when it could indeed to made to work on a whole bunch of more
>> modern systems *on which it would be irrelevant* - and thus not worth
>> the significant effort of po
Edward Welbourne wrote:
>> If we *never* allow ourselves breaking changes, we'd still have a
>> nice stable product that worked great on an O/S or two from the last
>> century. Qt would thus be irrelevant.
Kevin Kofler (16 June 2020 01:36)
> Nonsense. We would have
Max Paperno (13 June 2020 03:28) wrote:
> I would restate my objection by pointing out again [1] that Win 7 is
> still the 2nd most popular desktop OS in the world, with 3x more users
> than all MacOS versions combined. Never mind Linux, which is on par
> with Win XP users (the previous "known
Hi all,
On [0] there is discussion of deprecating these two macros, or even
outright removing them in Qt 6. I see the sense of deprecation, on dev
at least, since we expect C++17, in which static_assert() does the whole
job. Since they're macros, I know of no way to tell the compiler to
warn
On 10. Jun 2020, at 04:39, André Pönitz wrote:
>> [...] at least in the early phases of a bisection one has to find out
>> what setup has to used to build a module, too.
Alexandru Croitor (10 June 2020 09:44) replied:
> Yes. But how could we improve this really? Do we create some file in
> the
On 6/9/20 7:22 AM, Bogdan Vatra via Development wrote:
>>> - if you'll not support/trash all .pro/.pri files how we'll push
>>> fixes for 5.15 branch ? Because right now we can't push fixes
>>> directly to 5.15. branch and all the fixes must go trough dev
>>> branch first.
În ziua de marți, 9
Alexandru Croitor (9 June 2020 10:41)
> I'll acknowledge that the current Qt Creator <-> Build Qt with CMake
> situation is sub-par.
Is there a P1 ticket open about that ?
Might even warrant P0, given ...
> We have to bite the bullet at some point.
In particular, the "Structure and platform
this is not something we can subject our users to.
On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote:
>>> orly? kde had been doing that for quite a while.
On 2020 May 27, at 17:50, Thiago Macieira wrote:
>> And I fixed QtCore to do the same.
>>
>> The only reason not to
>>>
>>> Given the potential for breaking existing code which expects the current
>>> behavior, my inclination would be to clarify the documentation to
>>> clearly state the existing behavior.
On 27/05/2020 04.34, Edward Welbourne wrote:
>> Yes, the docs do need updated
Matthew Woehlke (26 May 2020 18:15)
> The documentation is not clear if the scale, rotate, etc. methods of
> QTransform apply *before* or *after* whatever the QTransform is already
> doing. The bug report indicates that they are applied *first*.
>
> Given the potential for breaking existing code
On Tuesday, 26 May 2020 09:17:05 PDT Edward Welbourne wrote:
>> (Matrix multiplication isn't commutative.)
Thiago Macieira (26 May 2020 18:42)
> This more or less summarises all I remember from matrix classes from high
> school.
While I'm a linear algebraist ... and aware that t
Thiago Macieira (26 May 2020 18:06) wrote:
> Neither QMatrix nor QTransform have seen any change since the Qt 5.0
> repository import that was related to the underlying math. Only licensing
> and C++ updates.
>
> The task https://bugreports.qt.io/browse/QTBUG-84441 is claiming there's
> some wrong
On Friday, 22 May 2020 02:21:29 PDT Tony Sarajärvi wrote:
Now open for discussion:
https://bugreports.qt.io/browse/QTQAINFRA-3745 Based on Thiago’s
comment that we don’t want to keep supporting it for years:
https://codereview.qt-project.org/c/qt/qtdoc/+/269546
On Sat, 23 May
Thiago Macieira (23 May 2020 03:06) wrote:
> Update:
>
> As we're reviewing the changes Lars is making to get rid of
> QStringRef, Lars, Marc and I came to the conclusion that
> QUtf8StringView is required for Qt 6.0.
[snip]
Sounds sensible.
I would just call it QUtf8View, since (see below) I
On 14/05/2020 14.58, Thiago Macieira wrote:
>>> Which is:
>>> b) misspelling "iteratable"
On Thursday, 14 May 2020 12:34:54 PDT Matthew Woehlke wrote:
>> Be that as it may, that ship has sailed:
>>
>>https://www.google.com/search?q=iteratable
>>
>> Even Google thinks so, and if you insist
On 5/12/20 6:12 PM, Иван Комиссаров wrote:
>> So the question is - is it possible to allow to construct QString from
>> unicode literal?
Giuseppe D'Angelo (12 May 2020 19:48) replied:
> "Not yet", but adding a constructor from char16_t to QString makes sense.
>
> This creates a problem down the
Lars Knoll (12 May 2020 09:49) wrote:
> My high level goal for the string classes in Qt 6 was to complete the
> Unicode related changes that we started for Qt 5.0, where we made utf8
> and utf16 the main encodings, and simplify things. I believe it’s
> important to leave the non Unicode world
Jani Heikkinen (27 April 2020 14:05) wrote:
> And in addition to these normal release milestones we need to have
> earlier milestone (Structure and platform freeze) at the end of June
> (30.6.2020, just before summer holidays) to lock down modules, target
> platforms etc for the release. In that
On 4/23/20 11:10 PM, Vitaly Fanaskov wrote:
>>>> Moving to one year release approach doesn't equal to make Qt less
>>>> stable.
> Ville:
>>> Of course it does, if we now allow API breaks every year.
On Fri, 24 Apr 2020 at 13:38, Edward Welbourne wrote:
&
Giuseppe D'Angelo (24 April 2020 10:19) asked
>>> Which "one year release approach" are we talking about here?
On 4/24/20 12:36 PM, Edward Welbourne wrote:
>> That would be Vitaly's proposal to have major releases yearly.
Giuseppe D'Angelo (April 24, 2020 12:38)
>
Giuseppe said:
First and foremost, we have a problem of coding guidelines, which
demand simple pluralization of the entity returned, not "List"
suffixing:
and conforming with that would fix the *List naming problem, so by all
means let's do that during the lifetime of Qt6,
On 4/23/20 11:10 PM, Vitaly Fanaskov wrote:
>> Moving to one year release approach doesn't equal to make Qt less stable.
Ville:
> Of course it does, if we now allow API breaks every year.
Not necessarily: if we *allow* API breaks every year *but* are
restrained in our use of them - so that, in
André Pönitz (23 April 2020 10:52)
> "vector" in this context is a misnomer. It does not "carry" something
> from one place to another,
It is a container, in which values are carried from one piece of code to
another. The same can, of course, be said of every container.
However, that's all that
Volker Hilsheimer wrote:
>>> 1) we will shut down the forward-merging bot next week
>>>
>>> 3) we will turn on the cherry-picking bot for all repositories
>>>
>>> Expect this to happen in early May, but probaly not at the same time for all
>>> repos. We will update the commit template to
Mårten Nordheim (30 March 2020 10:09)
> I was planning to send this email when the process is done, but I have no
> idea when that is.
QUIP 2 [0] says 15 days after you were seconded, if there are no objections.
So the time has come (a while back).
[0]
Aapo Keskimölö (27 March 2020 08:35) wrote:
> I will be leaving the responsibility to capable hands
Good luck Toni,
Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Matthew Woehlke (10 March 2020 20:24) wrote:
> In an ideal world...
[snip]
> Note that I believe nothing needs to be done to "merge" the GitHub PR;
> if the commits become reachable from the target branch, it should
> automatically get marked as "merged".
Given that gerrit cherry-picks the change
On 26/02/2020 07.42, Tor Arne Vestbø wrote:
>>> As others have argued, a signal is not special, in the sense that any
>>> function can do anything, including emitting signals, so annotating it
>>> doesn’t seem critical, as we apparently are fine without in all other
>>> cases.
On Thursday, 27
On Monday, 24 February 2020 03:30:25 PST André Somers wrote:
You seem to assume everyone used QtCreator as their IDE of
choice. That is not a reasonable assumption I think.
On 27/02/2020 13.57, Thiago Macieira wrote:
>>> It is a reasonable feature request for ALL IDEs to understand what
Kai Köhne (27 February 2020 16:46) wrote:
> Another thing I'm wondering about is the use of QT_DEPRECATED_SINCE in
> Qt's .cpp files. I see the benefit of QT_DEPRECATED_SINCE in the
> headers, because these are compiled into the user code, who in turn
> can use QT_DISABLE_DEPRECATED_BEFORE.
Oliver Wolff (26 February 2020 15:10) wrote
[snip]
> it serves a purpose to me. "Look here a signal is emitted, so that other
> parts who are interested in this information might react". For me that's
> important information when reading code (be it while coding or in code
> reviews).
Indeed. As
Mitch Curtis (25 February 2020 10:23) elaborated on what he'd said earlier:
>> For some context and for those who don't know: within the company, we
>> now have weekly bug triaging where a team of two people prioritise
>> all unprioritised bugs. So new reports rarely go more than a few days
>>
Mitch Curtis (24 February 2020 13:22)
> I don't think anyone has explained what that harm is yet.
#define emit
causes problems when you import a header that declares
void emit(Type arg);
and the compiler sees
void (Type arg);
and throws a wobbly.
Eddy.
Hi Jack,
> Can someone remove me from this list please
Yes - you can.
Every mail to it ends in this footer:
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
The last line's link has a form on it that you can use to unsubscribe.
Do you
On Mon, 2020-02-17 at 09:13 +, Edward Welbourne wrote:
>> We currently have an "In Progress" state. In practice when I work on an
>> issue, I initially do the work, then put that up for review; the review
>> phase takes up fragments of my time for a while, unlike t
On 17/02/2020 10:13, Edward Welbourne wrote:
>> We currently have an "In Progress" state. In practice when I work on
>> an issue, I initially do the work, then put that up for review; the
>> review phase takes up fragments of my time for a while, unlike the
>>
On 20/2/20 3:46 PM, Timur Pocheptsov wrote:
>> I want to propose a colleague of mine, Mårten Nordheim, as a
>> co-maintainer of QtNetwork module with him becoming the maintainer of
>> „High-Level network access (HTTP)"* (which essentially means
>> QNetworkAccessManager and related classes/code,
other uses for the
"In Review" distinction, but my current purpose in proposing it is as a
way to make Jira's scrum boards more useful.
On Wed, Feb 19, 2020 at 09:45:48AM +0000, Edward Welbourne wrote:
>> I very much doubt the distinction between In Progress and In Review is
>> going to in
On Tue, Feb 18, 2020 at 01:11:29PM +1000, Lorn Potter wrote:
>> Stepping through the interim steps is not a requirement, so it is not that
>> much difference to go from Reported->In Progress to Reported->In Review,
>> really.
>>
>> So the list you have to select from has one more entry to choose
I (4 February 2020 16:02) wrote
> Twelve modules have (non-boring) changes to API-defining C++ headers
> between v5.14.0 and the current 5.15 branch:
to which I've now added a Topic to make them easier to find:
https://codereview.qt-project.org/q/topic:%2522api-review-5.15%2522
One down -
On Tue, 18 Feb 2020 19:35:53 +0800
Sze Howe Koh wrote:
>> See
>> https://forum.qt.io/topic/111473/maintenance-tool-error-cannot-open-file-for-writing-no-error/
I note that the code quoted is using rand(); the code in QTemporary file
switched to using QRandomGenerator at 5.10.0; that's what now
Thiago Macieira (17 February 2020 20:35) wrote:
> Sorry, this just occurred to me. This is a request for 5.15 feature freeze
> exception.
>
> Re: https://bugreports.qt.io/browse/QTBUG-17331
Closed: 30-07-2013 03:38, >9 years ago.
> Re: 97645478de3ceffce11f58eab140c4c775e48be5
> ("QProcess: use
On 18/2/20 6:03 AM, Thiago Macieira wrote:
>> I'm with Alexandru here:
I confess I'd understood Alexandru as saying he'd wanted similar in the
past but not been allowed it. Perhaps I misunderstood ...
>> all ideas to have more states in JIRA start with a good intentions,
>> but eventually
Hi all,
We currently have an "In Progress" state. In practice when I work on an
issue, I initially do the work, then put that up for review; the review
phase takes up fragments of my time for a while, unlike the main work
phase, which is closer to full-time. I have more control over (and a
On 05.02.2020 11:50, Edward Welbourne asked:
>>>> Do we allow changes approved before feature freeze to get past the
>>>> Coin hurdle, even if that happens after FF ? How much fixing of
>>>> the change (if it turns out to have problems integrating) is
>>
Alexander Akulich (6 February 2020 16:33) asked:
> Are we going to provide some Qt5 → Qt6 migration tool?
https://codereview.qt-project.org/c/qt/qtrepotools/+/289121
> It is trivial to grep the sources for
> "SIGNAL(error(QAbstractSocket::SocketError))" and print a warning
> about the dangerous
Shawn Rutledge (5 February 2020 14:14)
> So I’m strongly in favor of continuing to do deprecations as long as
> possible. A deprecation is not something that can break existing
> functionality, so it’s no real risk as long as we’re sure we really
> want to deprecate it.
A deprecation can break
On 4 Feb 2020, at 16:56, Volker Hilsheimer wrote:
>>> I’ve been struggling a bit more than expected with getting the
>>> implementation of "move a file or directory to the trash" pass
>>> CI. It’s a popular feature request:
>>>
>>> https://bugreports.qt.io/browse/QTBUG-47703
>>>
>>> The basic
Jani Heikkinen (3 February 2020 06:35)
> API review for Qt 5.15 will start soon as well.
Twelve modules have (non-boring) changes to API-defining C++ headers
between v5.14.0 and the current 5.15 branch:
https://codereview.qt-project.org/c/qt/qtbase/+/289203
Mikhail Svetkin (3 February 2020 08:15) proposed:
> I would like to make request to move qthttpserver from qt-labs
> namespace to a new namespace qt-addons or qt-extensions.
>
> The main reason is that it is not a research project anymore. I
> believe that the module is ready to become a self
Khuram Ali (29 January 2020 15:07) replied
> I haven't requested to reset my Qt Account password. It seems some malicious
> attempt. Please advise. thank you!
Indeed, this seems to have gone to the whole development list,
which looks suspiciously like the 'bot that generated it is doing
Il 29/01/20 09:52, Cristián Maureira-Fredes ha scritto:
>> Regarding the LTS decision, you can take it from another point of
>> view: 5.15 will only have 2 or 3 bug fixing releases, and so will all
>> the LTS versions in the future. Since TQtC has commercial costumers,
>> we will internally fork
Sona Kurazyan (24 January 2020 10:29)
> Previously there were discussions that we need to have a new module in Qt 6
> for the Qt 5 classes that will be no longer maintained in Qt 6.
>
> Here are some candidates to be moved there in Qt 6 (see
> https://bugreports.qt.io/browse/QTBUG-80312):
>
> *
Jaroslaw Kobus (24 January 2020 11:02)
> So it looks like there is a need to have something like Eigen in Qt,
> at least for Qt 3D purposes (faster, better optimized classes, more
> complete API). So either we use it directly (this option is rather not
> possible, looking at the previous feedback:
Dmitriy Purgin (14 January 2020 10:10) wrote:
> I'm afraid I did something incorrectly when submitting my first
> contribution to the Qt project and I would love to get a feedback if I
> did it wrong.
[snip]
> Is there something I've missed? Should I have created a ticket in Jira
> first? Or
Lorn Potter (12 December 2019 11:11)
> Qt WebAssembly is a new platform that is bringing Qt and Qt Quick apps
> directly to the web. See https://www.qt.io/qt-examples-for-webassembly
>
> To better coordinate the platform tasks, I would like to nominate Morten
> Sørvig as co maintainer.
>
> Morten
Martin Smith (11 December 2019 15:52) wrote:
> I will now formally step down as QDoc maintainer. [...]
> Topi Reiniö wants very much to take over the maintainer role, and I
> think he is the best person to guide QDoc through its next phase of
> development, which will be significant.
+1 for that
Volker Hilsheimer wrote:
>> Sounds nice, but the reality is that this has not been the
>> case. Forward-merging hasn't worked without a fair bit of
>> hand-holding; one big difference is that forward-merging is a
>> centralized process, so the hand-holidng had to be done by the merge
>> master who
Volker Hilsheimer (26 November 2019 15:42) wrote:
[snip]
> If I understood and remember the discussion, then the proposed flow
> would be:
>
> * we make changes to e.g changes-5.12.7 in the 5.12 branch
> * once 5.12.7 is released, release team copies the file into dev, and
> makes a separate
Il 21/11/19 13:13, Robert Loehning ha scritto:
>> ** [https://doc.qt.io/qt-5/qregularexpression.html QRegularExpression]
Giuseppe D'Angelo (22 November 2019 18:17) replied:
> This should mostly be fuzzing libpcre itself...
... which Google is probably already doing.
> Note that users should
101 - 200 of 553 matches
Mail list logo
