https://bugreports.qt.io/browse/QTBUG-66153 was fixed in 5.11-alpha1.
Which sha1 of qtbase are you building?
Tor Arne
> On 26 Mar 2018, at 08:15, Mitch Curtis wrote:
>
> You might be running into https://bugreports.qt.io/browse/QTBUG-66153
>
> Try setting QT_LOGGING_TO_CONSOLE=1
>
> On 3/26
> On 26 Mar 2018, at 13:31, Igor Mironchik wrote:
>
>
>
> On 26.03.2018 14:22, Tor Arne Vestbø wrote:
>> https://bugreports.qt.io/browse/QTBUG-66153 was fixed in 5.11-alpha1.
>>
>> Which sha1 of qtbase are you building?
>
> 4ca0d764546908dd31fc3794d
>
> I cannot run the compiler on the target platform due to memory and CPU
> speed constraints so I need to cross-compile everything [3].
> Is there any existing mechanism to run the unit tests on a machine
> other than the compilation host?
Mount the tests on the device (sshfs e.g.), and run the
> On 17 May 2018, at 10:14, Alex Blasche wrote:
>
> Hi,
>
> The naming conventions for enums state that each enum value name must repeat
> a part of the enum Type name (for details see
> https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values)
>
> In case of scoped enums this
> On 13 Jun 2018, at 14:07, Simon Hausmann wrote:
>
> Hi,
>
> While it's true that show(), etc. don't have the focus object as a parameter,
> you do have a three ways of tracking the focus object, via QWindow and
> QGuiApplication's signal as well as via setFocusObject in the input context
> On 15 Jun 2018, at 13:31, Arnaud Clère wrote:
>
[snip]
> Most user-defined bind methods would be very simple and the type system would
> guarantee that data is well-formed (no sequence or record left open...):
>
>struct Person {
>QString m_firstName, m_lastName;
>int m_
How about we also start with only one or two obvious rules that everyone
agrees on? I don’t want Qt development to turn into Python PEP8 type rigid
rules that makes you jump through a million hoops. If the latter is the goal
here then I’m against enforcing clang-format, and it should be impleme
imagining it used only to verify style, not to auto-format.
Still, starting out with a few non-controversial rules would be a good thing.
Tor Arne
>
> Lars
>
>> On 20 Jun 2018, at 11:52, Tor Arne Vestbø wrote:
>>
>> How about we also start with only one or two obvio
> On 2 Jul 2018, at 12:56, Svenn-Arne Dragly wrote:
>
> There are also many nice options set in the clang-format config found in Qt
> Creator's sources[2] which I think are interesting. For instance,
> "BinPackParameters: false" and "BinPackArguments: false" makes sure you to
> either put al
> On 2 Jul 2018, at 16:49, Lars Knoll wrote:
>
>
>> On 2 Jul 2018, at 13:35, Tor Arne Vestbø wrote:
>>
>>
>>> On 2 Jul 2018, at 12:56, Svenn-Arne Dragly wrote:
>>>
>>> There are also many nice options set in the clang-format config f
> On 3 Jul 2018, at 10:26, Lars Knoll wrote:
>
>> On 2 Jul 2018, at 16:52, Tor Arne Vestbø wrote:
>>
>>
>>
>>> On 2 Jul 2018, at 16:49, Lars Knoll wrote:
>>>
>>>
>>>> On 2 Jul 2018, at 13:35, Tor Arne Vestbø
On 3 Jul 2018, at 13:42, Lars Knoll wrote:
>
> To some extent it might introduce new ones, but the idea was to aim for a
> format file that is very close to our existing rules.
It seems the extent is wider than first outlined. And even if it’s very close
to the existing rules, those rules wil
> On 11 Jul 2018, at 18:21, Thiago Macieira wrote:
>
> On Monday, 9 July 2018 07:31:27 PDT Alexandru Croitor wrote:
>> I believe that's something for the macOS maintainers to decide.
>
> Thanks. Any opinions?
>
> The fix for XCode 8.2 broke XCode 9.
>
> Can we PLEASE drop XCode 8.2? Like, rig
> On 15 Jul 2018, at 20:39, Thiago Macieira wrote:
>
> Twice an integration of mine resulted in
>
> ..\..\..\..\shared/emulationdetector.h:62:13: warning: 'bool
> EmulationDetector::isRunningArmOnX86()' defined but not used [-Wunused-
> function]
> static bool isRunningArmOnX86()
>
> On 31 Jul 2018, at 13:43, Kai Koehne wrote:
>
> I can think of 3 approaches to tackle this:
>
> a) Prefix all symbols with 'q', like we do for exported symbols.
>
> This requires some bigger patches. See e.g.
> https://codereview.qt-project.org/#/c/235631/ for renaming all logging
> categ
> On 31 Jul 2018, at 15:58, Konstantin Shegunov wrote:
>
> On Tue, Jul 31, 2018 at 2:43 PM, Kai Koehne wrote:
> Hi,
>
> I'm wondering how we can avoid symbol clashes in static Qt libs + user code.
>
> a) Prefix all symbols with 'q', like we do for exported symbols.
>
> This requires some b
> On 1 Aug 2018, at 15:45, Kai Koehne wrote:
>
> Alright, so it seems we have to prefix the symbols we can't hide by static or
> anonymous namespaces ...
>
> For logging categories, I'd like to start using 'qlc' as prefix. See also
> change https://codereview.qt-project.org/#/c/235631/ for q
On 7 Aug 2018, at 11:46, Frederik Gladhorn wrote:
>
> Hi all,
>
> I've spend a bit of time writing a script that monitors gerrit and the git
> repositories to update JIRA statuses. It's not quite done yet, but getting
> there.
> Basically it should be able to set the fixed version and close ta
> On 7 Aug 2018, at 16:06, Frederik Gladhorn wrote:
>
> On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote:
>> On Tue, Aug 07, 2018 at 11:46:12AM +0200, Frederik Gladhorn wrote:
>>> I've spend a bit of time writing a script that monitors gerrit and the git
>>> repositories to upda
Bringing this up again in light of e.g.
https://codereview.qt-project.org/#/c/235167/
When I gave my support to this I thought we were talking about global enums. I
do not think that using class enums inside existing classes is a win for code
readability/writability:
When you have
switch (p
On 13 Aug 2018, at 18:12, Giuseppe D'Angelo via Development
wrote:
>
> Il 13/08/2018 16:40, Tor Arne Vestbø ha scritto:
>> Or:
>> if (event->device()->pointerType() != QQuickPointerDevice::Finger
>> Gives me all the info I need, and having to type or r
> On 14 Aug 2018, at 09:16, Alex Blasche wrote:
>
>> I
>> do not think that using class enums inside existing classes is a win for code
>> readability/writability:
>>
>> When you have
>>
>> switch (point->state()) {
>>
>> It's pretty obvious what case QQuickEventPoint::Pressed: refers to. bei
> On 14 Aug 2018, at 12:13, Alex Blasche wrote:
>
>
>
>> -Original Message-
>> From: Tor Arne Vestbø
>> That circular logic 😊 Or at least arguing that we should maintain the policy
>> not
>> because it makes sense, but just because we’
> On 14 Aug 2018, at 13:13, Eike Ziller wrote:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf states the
> problems that were the driver for creating strongly typed enums:
>
> 1. Implicit conversion to integer
> 2. Inability to specify underlying type
https://en.cpprefe
promoting a warning to an error, and as such shouldn’t block us
moving forward with #1.
Cheers,
Tor Arne
> On 14 Aug 2018, at 15:00, Eike Ziller wrote:
>
>
>
>> On 14. Aug 2018, at 13:18, Tor Arne Vestbø wrote:
>>
>>
>>> On 14 Aug 2018, at 13:13, Eike
> On 14 Aug 2018, at 15:29, Allan Sandfeld Jensen wrote:
>
> I agree, at least in most cases. There are still cases where I would prefer
> unscoped enums. For instance in my recent QColorSpace patch, I ended up using
> both types of enums under QColorSpace. The enum that represented specific
> On 15 Aug 2018, at 09:32, Alex Blasche wrote:
>
>
>
>> -Original Message-
>> From: Tor Arne Vestbø
>> 1. Scoped enums (enum class) for the sake of avoiding name clashes is useful
>> for
>> global enums, but when the enum lives insid
> On 16 Aug 2018, at 22:11, Thiago Macieira wrote:
>
> On Wednesday, 20 June 2018 06:05:35 PDT Arnaud Clère wrote:
>> Hi,
>> Thiago, did you decide on something regarding QCborValue in Qt5.12?
>
> Hello Arnaud, all
>
> No, I have not. I have not had the time to read your email yet and nor hav
> On 17 Aug 2018, at 17:08, Thiago Macieira wrote:
>
> On Friday, 17 August 2018 02:50:32 PDT Tor Arne Vestbø wrote:
>>> Unless someone can volunteer to test. I *think* my design is slightly
>>> better than QJsonValue, so the following should work:
>>>
On 17 Aug 2018, at 17:08, Thiago Macieira wrote:
>
> On Friday, 17 August 2018 02:50:32 PDT Tor Arne Vestbø wrote:
>>> Unless someone can volunteer to test. I *think* my design is slightly
>>> better than QJsonValue, so the following should work:
>>>
I think Simon’s reasoning in the review that spurred this discussion summarises
it nicely:
> On 31 Aug 2018, at 10:24, Simon Hausmann (Code Review)
> wrote:
>
> Simon Hausmann has posted comments on this change.
>
> Change subject: Convert QQEventPoint and QQPointerDevice enums to enum classe
Hey,
> On 31 Aug 2018, at 14:50, Jan-Arve Sæther wrote:
>
> For me it seems that enum classes can help us create a more structured API,
> because they also gives more semantic information, e.g:
> QQuickPointerDevice::PointerType::Finger
> gives more information than
> QQuickPointerDevice::Finge
> On 9 Sep 2018, at 12:25, Sze Howe Koh wrote:
>
> Hi Thiago,
>
> On Sat, 18 Aug 2018 at 01:51, Thiago Macieira
> wrote:
>>
>> On Friday, 17 August 2018 08:13:21 PDT Tor Arne Vestbø wrote:
>>>> Now, looking at the code, I don't think it does
Hey,
Nothing against your competence Samuel, but I think the qtmacextras module
should be maintained by the same maintained as macOS, Morten.
I also think that the extras modules have a risk of ending up as dumping
grounds for platform specific APIs we never really got around to integrating
wi
On 12 Sep 2018, at 11:02, Edward Welbourne wrote:
>> With the proposed solution of making platform plugins libraries with
>> their own private headers, we can have these apis closer to the
>> platform code, and without lots of plumbing and indirection.
>
> Sounds promising.
I don’t think I’ve wr
> On 12 Sep 2018, at 12:37, Tor Arne Vestbø wrote:
>>
>> Use of passive voice - "should be" - perhaps a better plan would be to
>> actively submit the patches to make it happen, or file a task in Jira
>> for it. Even if there's no release branch read
> On 12 Sep 2018, at 18:52, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>
> El miércoles, 12 de septiembre de 2018 12:38:03 -03 Thiago Macieira escribió:
>> On Wednesday, 12 September 2018 01:44:36 PDT Gatis Paeglis wrote:
With the proposed solution of making platform plugins libraries wi
> On 21 Sep 2018, at 12:47, Jedrzej Nowacki wrote:
>
> On Friday, September 21, 2018 9:07:14 AM CEST Sami Nurmenniemi wrote:
>> I committed this to 5.11 branch:
>> https://codereview.qt-project.org/#/c/240566/
>>
>> Now Gerrit Bot marked this as fixed in 5.11.0, which is not correct:
>> https:
> On 21 Sep 2018, at 13:32, Jedrzej Nowacki wrote:
>>
>> Shouldn’t that pick refs/heads/5.11?
>>
>> Tor Arne
>
> Yes, that is what happened. The first release branch for 5.11 is 5.11.0,
> therefore it marked 5.11.0 as fixed version.
That doesn’t make any sense. The 5.11 branch is constantly
Timur, this should be fixed by your patch right?
Tor Arne
> On 21 Sep 2018, at 15:36, Nils Jeisecke via Development
> wrote:
>
> Seems that "Shift" acts like "Ctrl+Shift".
>
> Am 21.09.2018 um 15:22 hat Nils Jeisecke via Development geschrieben:
>> not sure if this a mac only problem but I'
I 100% stand behind Mitch’s summary below. This is a real problem in this
project that not only makes it a less than great place to work, but is also
indirectly affecting the quality of the code, for those that care only about
that part.
Tor Arne
> On 25 Oct 2018, at 13:22, Mitch Curtis wrot
not going to go into
details about concrete cases. If the project/community can’t trust that these
are real concerns coming from long standing contributors, without airing dirty
laundry in the process, then we’re worse off than I thought.
Tor Arne
>
>
>
>
> On Thu, Oct 25, 2018 at
Happy new year Liang, excellent work!
tor arne
> On 22 Dec 2018, at 23:26, Liang Qi wrote:
>
> Merges
>
> * 5.11.3->5.11 merges are done, including qt5, so 5.11.3 branch could be
> nuked.
> * 5.12.0->5.12, qt5 one https://codereview.qt-project.org/#/c/248857/ is
> ongoing
> * 5.11->5.12, sti
> On 15 Jan 2019, at 09:24, Lars Knoll wrote:
>
> Can the Gerrit/CI folks please create that branch?
Going forward we will now have “dev” development in both Qt 5 and Qt 6.
Can we please use explicit version names instead of arbitrary named “dev” and
“qt6” branches?
dev ==> 5.13 -> 5.14, e
On 15 Jan 2019, at 11:26, Lars Knoll wrote:
>> On 15 Jan 2019, at 11:17, Tor Arne Vestbø wrote:
>>
>>
>>> On 15 Jan 2019, at 09:24, Lars Knoll wrote:
>>>
>>> Can the Gerrit/CI folks please create that branch?
>>
>> Going forward
> On 15 Jan 2019, at 11:54, Lars Knoll wrote:
>
> Ok, guess I misunderstood a bit. My idea was to keep ‘dev’ for 5.x
> development and ‘qt6’ for Qt 6 related development. At some point (when 5.15
> is branched) we’d basically rename qt6 to dev (because at that point there’s
> no 5.x anymore)
> On 15 Jan 2019, at 12:06, Tor Arne Vestbø wrote:
>
> If retiring the ‘dev’ branch in favour of explicit 5.13, 5.14, 5.15 etc, then
> at least we should choose a Qt 6 branch that is one of the two options above,
> either 6.0 or 6.x, not ‘qt6’.
That should be "If retir
> On 15 Jan 2019, at 12:13, Allan Jensen wrote:
>
> On Tuesday, 15 January 2019 12:06:17 CET Tor Arne Vestbø wrote:
>>> On 15 Jan 2019, at 11:54, Lars Knoll wrote:
>>>
>>> Ok, guess I misunderstood a bit. My idea was to keep ‘dev’ for 5.x
>&g
> On 15 Jan 2019, at 13:14, Allan Jensen wrote:
>
> On Tuesday, 15 January 2019 12:22:11 CET Tor Arne Vestbø wrote:
>>> On 15 Jan 2019, at 12:13, Allan Jensen wrote:
>>>
>>> On Tuesday, 15 January 2019 12:06:17 CET Tor Arne Vestbø wrote:
>>>
>
> On 15 Jan 2019, at 13:32, Lars Knoll wrote:
>
> We can (and should) rename it to dev once the last 5.x version (presumably
> 5.15) reaches feature freeze (ie. in a year from now).
Or just go with 6.x, or 6.0, like I’ve proposed.
Tor Arne
___
Dev
> On 15 Jan 2019, at 13:52, Lars Knoll wrote:
>
>
>
>> On 15 Jan 2019, at 13:44, Kari Oikarinen wrote:
>>
>> An alternative way of seeing (and perhaps handling) is in the same way as we
>> handle feature branches. The qt6/6/next/whatever branch would be for
>> development
>> that can't be
> On 15 Jan 2019, at 14:25, Lars Knoll wrote:
>
>>
>> On 15 Jan 2019, at 14:00, Tor Arne Vestbø wrote:
>>
>>
>>
>>> On 15 Jan 2019, at 13:52, Lars Knoll wrote:
>>>
>>>
>>>
>>>> On 15 Jan 2019, a
Picking up on this:
If we plan to standardise on our Qt source code being UTF8, can we please allow
QString(“Tor Arne Vestbø") without going through
QLatin1Literal/QStringLiteral/QLatin1String/etc etc?
Tor Arne
> On 18 Jan 2019, at 16:01, Jedrzej Nowacki wrote:
>
> Dnia środ
I actually would
>> stay with QT_NO_CAST_FROM_ASCII.
>
> Actually, what we should do is allow everywhere
>
> functionTakingString(u"Tor Arne Vestbø")
> // (note the u)
Yes, this would be awesome! Please let’s do this 😊
And I guess without QT_NO_C
> On 8 Feb 2019, at 10:43, Vitaly Fanaskov wrote:
>
> Hi,
>
> I've read QTBUG-47703 very carefully and I think that adding some file
> managers is overkill in this particular case.
I agree, QFile and QDir are natural places to look for such APIs.
Tor Arne
_
> On 13 Feb 2019, at 11:06, Simon Hausmann wrote:
>
> (1) Build a repo, install it, build the next repo, install it, etc.
Will there be a -developer-build option that doesn’t require install?
Tor Arne
___
Development mailing list
Development@qt-pr
> On 13 Feb 2019, at 14:58, Kevin Funk via Development
> wrote:
>
> make it more difficult for distros to co-install the CMake config files for
> different Qt versions.
This sounds like a generally useful feature for distros to have, not just for
major versions but for minor etc too?
I gue
> On 13 Feb 2019, at 16:13, Kevin Funk wrote:
>
> On Wednesday, 13 February 2019 15:40:15 CET Tor Arne Vestbø wrote:
>>> On 13 Feb 2019, at 14:58, Kevin Funk via Development
>>> wrote:
>
>>> make it more difficult for distros to co-install the CMake con
> On 13 Feb 2019, at 16:21, Tor Arne Vestbø wrote:
>
> Or, when building a distro-spesific package foo that depends on qt 5.12, the
> distro would set CMAKE_PREFIX_PATH to the correct prefix.
>
> I think the latter is what Homebrew does.
At least I think it does this fo
> On 19 Feb 2019, at 23:50, René J.V. Bertin wrote:
>
> Hi,
>
> I'm trying to understand why Qt4 applications on Mac do not correctly display
> "font emojis" while they do on Linux. Qt5 apps are fine so I should be able
> to satisfy my curiosity from the Qt5/Mac implementation of the relevan
> On 20 Feb 2019, at 00:22, Tor Arne Vestbø wrote:
>
>
>
>> On 19 Feb 2019, at 23:50, René J.V. Bertin wrote:
>>
>> Hi,
>>
>> I'm trying to understand why Qt4 applications on Mac do not correctly
>> display "font emojis" wh
> On 5 Mar 2019, at 11:27, Giuseppe D'Angelo via Development
> wrote:
>
> Il 05/03/19 08:14, Lars Knoll ha scritto:
>> One solution I thought about is to replace the QT_DEPRECATED(_X) macros with
>> something that also contains the version (similar to QT_DEPRECATED_SINCE).
>> Then the user c
https://doc.qt.io/qt-5/qscopeguard.html 😊
Tor Arne
> On 7 Mar 2019, at 18:01, Volker Hilsheimer wrote:
>
> Ahoy,
>
> In what little development I’ve done in golang, I appreciated the “defer”
> statement as a means to write cleaner code. Basically, defer schedules a
> statement for execution
> On 8 Mar 2019, at 06:47, Timur Pocheptsov wrote:
>
> Tor Arne +2! 😄
To be clear, qScopedGuard was contributed by Sérgio Martins
Sérgio Martins++ 😊
Tor Arne
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/li
> On 8 May 2019, at 16:47, Frederik Gladhorn wrote:
>
> Hello Vladimir,
>
> On onsdag 10. april 2019 14:21:21 CEST Minenko, Vladimir wrote:
>> Hi,
>>
>> I would like to request for a new repository:
>>
>> Name of the repository: qt-labs/qtuianalytics.git
>> Description: An plugin for Qt Quic
> On 10 May 2019, at 12:04, Kevin Funk wrote:
>
> Kind of inconsistent with the naming of all other Qt module repositories,
> which all start with a "qt”.
Right, that’s what I meant, sorry 😊
> On Friday, 10 May 2019 10:38:17 CEST Minenko, Vladimir wrote:
>> Hi,
>>
>> the current implement
+2
> On 16 May 2019, at 16:45, Volker Hilsheimer wrote:
>
> Hi,
>
>
> I’d like to nominate Mikhail Svetkin for Approver status. He’s been an active
> contributor since March 2018, working on C++11’ifying Qt, contributing to
> core QPA, network code, the QtHttpServer labs project, and right n
> On 20 May 2019, at 15:00, Jukka Jokiniva wrote:
>
> Bug reports and improvement ideas can be reported to bugreports.qt.io
> (project=QTQAINFRA component= Gerrit). Here is a tiny link:
> http://tiny.cc/new-qt-gerrit-issue
And here’s a filte for open issues https://bugreports.qt.io/issues/?f
On 6 Jun 2019, at 10:42, Mutz, Marc via Development
wrote:
>
> *But* it's not "hard to read" in the sense that you stare at it and can't
> figure out what the hell the code is doing.
You can insult my intelligence and CS credentials all you want, I’m still going
to claim that the STL-code in
> On 6 Jun 2019, at 15:41, Simon Hausmann wrote:
>
> Hi,
>
> I believe the code signing part is covered by existing CMake xcode support,
> as it is also for macOS.
>
> The support for fat binaries is something I don't have hands-on experience,
> but the upstream documentation suggests suppo
> On 6 Jun 2019, at 15:45, Lars Knoll wrote:
>
>
>
>> On 6 Jun 2019, at 15:33, Иван Комиссаров wrote:
>>
>> Sorry, but the iOS should be properly supported before making the final
>> decision.
>> Building something on macOS is easy, building smth for iOS is harder. From
>> the top of my h
> On 24 Jun 2019, at 14:43, Simon Hausmann wrote:
>
> I have two more numbers to add: Compressed (7z) the download size would
> be around ~44 MB. I measured on Windows with a Qt Creator built with
> WebEngine support and surfed a little through the docs. The memory
> consumption of the web e
The name qtplatformdefinitions will likely quickly be wrong once something else
needs to be dumped in there. How about just qtinfra?
Tor Arne
> On 25 Jun 2019, at 12:18, Jedrzej Nowacki wrote:
>
> As in: https://bugreports.qt.io/browse/QTQAINFRA-3068
>
> We need a repository for infrastructu
Or qtqainfra 😊
> On 25 Jun 2019, at 12:23, Tor Arne Vestbø wrote:
>
> The name qtplatformdefinitions will likely quickly be wrong once something
> else needs to be dumped in there. How about just qtinfra?
>
> Tor Arne
>
>> On 25 Jun 2019, at 12:18, Jedrzej N
> On 25 Jun 2019, at 21:30, Konrad Rosenbaum wrote:
>
> Pardon my lingo,
You should be able to communicate your points without that kind of lingo. Try
better.
> It is documentation for developers for crying out loud! Its purpose is not to
> win any design prices, but to educate the develope
> On 25 Jun 2019, at 22:53, André Pönitz wrote:
>
> On Tue, Jun 25, 2019 at 07:59:16PM +0000, Tor Arne Vestbø wrote:
>>> On 25 Jun 2019, at 21:30, Konrad Rosenbaum wrote:
>>>
>>> Pardon my lingo,
>>
>> You should be able to communicate your
> On 27 Jun 2019, at 16:10, Frederik Gladhorn wrote:
>
> On a related note, now that things are generally working with the new Gerrit,
> I was wondering if we want to consider plugins. There is one to add reviewers
> based on git blame
> https://gerrit-review.googlesource.com/admin/repos/plug
+1 !
> On 11 Jul 2019, at 17:27, Paul Wicking wrote:
>
> Hi all,
>
> I’d like to nominate Kavindra Palaraja as approver. She is a very active
> contributor and reviewer, in particular for documentation related changes,
> focusing on the Qt Automotive platform. She’s a former employee of Trol
> On 5 Aug 2019, at 12:35, Stottlemyer, Brett (B.S.) wrote:
>
> Hi,
>
> I’d like to request a new branch (“acme”) on QtCreator.
>
> The too short version: ACME is a simulation tool, allowing you to create a
> project that can run in QtCreator and quickly implement interfaces (e.g.,
> DBu
> On 12 Aug 2019, at 22:17, Thiago Macieira wrote:
>
>> On Monday, 12 August 2019 00:17:58 PDT Lars Knoll wrote:
>> As mentioned in my blog, it would be good to move forward with the C++
>> version we use for Qt 6 and ideally move it to C++17.
>
> Someone with iOS knowledge please address the
> On 13 Aug 2019, at 11:39, Tony Sarajärvi wrote:
>
> MacOS is another good example where we claim to support the latest 3
> available at the time of release. But in 4 years of an LTS release we
> actually don’t have a single one of those 3 left that were out when we
> released 5.x.0. Are we
> On 16 Aug 2019, at 12:26, Lars Knoll wrote:
>
> To reflect that and help us all understand that the development focus is now
> towards Qt 6, I would like to propose that dev becomes the Qt 6 branch after
> we branched away 5.14 (and we merge wip/qt6 back into dev). We can then
> either cre
> On 21 Aug 2019, at 11:50, Bogdan Vatra via Development
> wrote:
>
> Am I the only one which finds situations silly ? Of course there are more
> examples with the other String wrappers/functions in Qt, but I think is
> enough
> to show how crazy is the situation.
You are not!
I complete
> On 21 Aug 2019, at 16:47, Thiago Macieira wrote:
>
> On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:
>> This should just be test[“key”] = “value”. How do we get there?
>
> Do you mean "make this the most optimal?" If so, then we don'
> On 21 Aug 2019, at 16:55, Thiago Macieira wrote:
>
> On Wednesday, 21 August 2019 07:47:23 PDT Thiago Macieira wrote:
>> On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:
>>> This should just be test[“key”] = “value”. How do we get there?
>>
>
> On 21 Aug 2019, at 17:24, Konstantin Tokarev wrote:
>
>
>
> 21.08.2019, 18:22, "Tor Arne Vestbø" :
>>> On 21 Aug 2019, at 16:55, Thiago Macieira
>>> wrote:
>>>
>>> On Wednesday, 21 August 2019 07:47:23 PDT Thiago Macieira wr
> On 21 Aug 2019, at 17:39, Giuseppe D'Angelo via Development
> wrote:
>
> However, what I was referring about was the problem of using the wrong class
> to manage string-data: if tooling can reliably tell users that they're doing
> a mistake, this drastically reduces the chances of such mis
> On 21 Aug 2019, at 17:58, Thiago Macieira wrote:
>
> On Wednesday, 21 August 2019 08:16:42 PDT Tor Arne Vestbø wrote:
>> That’s what I was hoping. We have QFooLiteral today to let the compiler do
>> the work up front, isn’t it possible with newer c++ standards t
> On 21 Aug 2019, at 18:01, Thiago Macieira wrote:
>
> On Wednesday, 21 August 2019 08:49:52 PDT Tor Arne Vestbø wrote:
>> I agree that this would mitigate the problem somewhat, but imagine writing
>> your code and being reminded every second:
>
>> warning: u
> On 21 Aug 2019, at 18:30, Thiago Macieira wrote:
>
> On Wednesday, 21 August 2019 09:17:24 PDT Tor Arne Vestbø wrote:
>>> Remember that QStringLiteral today has a drawback: if you
>>> unload the plugin it came from, any left-over uses of it may crash. That's
> On 21 Aug 2019, at 18:32, Giuseppe D'Angelo via Development
> wrote:
>
> On 21/08/2019 18:21, Tor Arne Vestbø wrote:
>> I would not want to have those “you’re using a fast, but not optimal version
>> of the N string classes” warnings unless I was writing str
> On 22 Aug 2019, at 13:55, Lars Knoll wrote:
>
> The problem with our multitude of string classes is not only that we’re
> overcomplicating our API, but also that we’re adding implementation
> complexity for ourselves that we will need to maintain over the years to
> come. I would very much
> On 22 Aug 2019, at 15:11, Mutz, Marc via Development
> wrote:
>
> We need to collectively understand that implementing a library is different
> from the library's API and from use of the API. Anyone who thinks otherwise
> is invited to have a look at qmetatype.h or qtypeinfo.h. All users se
> On 22 Aug 2019, at 17:39, Mutz, Marc wrote:
>
> Aye, it's more to _think_ and to _write_, but we don't care about those
> metrics.
Don’t say “we”, when you mean “I”. This hits the nail on the head. You may not
care, but I for one do.
> The same goes for QList vs. QVector vs. std::vector. A
Also, looks like old components can now be archived!
- Tor Arne
> On 17 Sep 2019, at 09:08, Alex Blasche wrote:
>
> Hi,
>
> The server will be upgraded from Jira version 7.13 to 8.2. If all goes well,
> the process should take about 1 hour.
>
> --
> Alex
> ___
I can’t speak for Android, but on iOS you don’t want to show a non-native
keyboard. That would look extremely out of place on the platform.
Tor Arne
> On 9 Oct 2019, at 01:18, Alexander Ivash wrote:
>
> Quick search through Qt 5.13.1 code showed that
> 'QPlatformInputContextFactory::create' i
Awesome! CMake merge next! 😄
Tor Arne
> On 11 Oct 2019, at 11:55, Simon Hausmann wrote:
>
> Hi,
>
> Finally all changes from wip/qt6 have been merged into dev for all modules.
> I've filed QTQAINFRA-3273 for the Gerrit admins to close the branch. There
> are still open pending changes in s
Hi,
On 11/22/12 6:52 , Thiago Macieira wrote:
> That's the point: the conclusion was that the default on Mac is to *not* have
> frameworks anymore. It might have been the case in the past, but recently the
> trend has been to have regular libraries. Apple themselves are now preferring
> that way,
On 11/23/12 16:57 , Thiago Macieira wrote:
> On sexta-feira, 23 de novembro de 2012 14.20.31, Tor Arne Vestbø wrote:
>> Regarding the installation path, /Library/Frameworks makes more sense
>> than /usr/local/Qt to me. What's the benefit of switching that?
>
>
If you're writing the ChangeLog entry at commit time, not right before
the release, why can't your patch contain a change to dist/changelog
from the get-go which, can be reviewed and integrated along with the
code change?
tor arne
___
Development mail
1 - 100 of 299 matches
Mail list logo
