Re: [Development] QFuture and C++20

03.03.2021, 19:15, "Allan Sandfeld Jensen" : > On Mittwoch, 3. März 2021 09:32:33 CET Jason H wrote: >>  I saw Lars's Qt6 talk on youtube, where he said Qt6 requires C++17. He also >>  mentioned the new QFuture:: then() function... This is an improvement, but >>  it makes Qt code look like

Re: [Development] Building additional components with Conan for Qt 6

14.10.2020, 09:14, "Heikki Halmet" : > Hi, > > I'm not the expert when it comes to Conan so I'm asking what would be the > main gain we would achieve by using Conan instead of scripts we currently > have..? List of packages and versions in one place? With quick review this > would take lot of

Re: [Development] Building additional components with Conan for Qt 6

n.io/en/latest/howtos/collect_licenses.html >There seems to be a lot of research into conan by Iikka, but i cannot find any >related to building all the qt modules with it. I am sure it requires >developer attention also, related to the CMake changes that needs to be done. >

Re: [Development] Windows Timer Resolution: The Great Rule Change

08.10.2020, 11:46, "Philippe" : > On Wed, 7 Oct 2020 17:34:43 -0700 > Thiago Macieira wrote: > >>  Now, the question is how WaitFor{SingleObject,MultipleObjects} are affected. >>  Does this mean that asking for a timeout of 2 milliseconds could result in >>  being 13 seconds too late? > > I

Re: [Development] Building additional components with Conan for Qt 6

02.10.2020, 16:20, "Konstantin Tokarev" : > 02.10.2020, 15:53, "Toni Saario" : >>  One thing to check is that how much the provisioning it is possible to >> translate to Conan, I would believe that in the end it does not work for >> everything. >

Re: [Development] How to perform unattended installations of Qt? (Was: Changes to Qt offering)

04.10.2020, 01:03, "Croitor Alexandru" : > On Sat, Oct 3, 2020 at 11:07 PM Konstantin Tokarev wrote: >> For comparison, using simple python script from [1] (which was mentioned on >> the list a few times before) > > Hmm, maybe my search-foo is weak, but sear

Re: [Development] How to perform unattended installations of Qt? (Was: Changes to Qt offering)

03.10.2020, 20:26, "Croitor Alexandru" : > Hi all, > > I spent a bit of time trying to get a project of mine to build in Github > Actions with a Qt installed via the new online installer. > > I used Volker's script as a base, modified it a bit, and created a github > workflow that installs Qt

Re: [Development] Building additional components with Conan for Qt 6

ind them without any knowledge of Conan. I guess this way may be called "Ossi-friendly because Ossi was adamantly opposed to any explicit support of Conan in build system, see e.g. https://codereview.qt-project.org/c/qt/qtbase/+/184241, however this way indeed may cause dependency slips

[Development] http://download.qt.io/new_archive/qt/

Hello, Seems like a lot of files were removed today from http://download.qt.io/new_archive/qt/ Was it intentional? Are these archives available somewhere else? -- Regards, Konstantin ___ Development mailing list Development@qt-project.org

Re: [Development] Building additional components with Conan for Qt 6

have > installed an add-on package. > > Iikka Eklund > Senior Software Engineer > > iikka.ekl...@qt.io > http://qt.io > > > From: Konstantin Tokarev > Sent: Friday, October 2, 2020 12:15 PM > To: Richard Weickelt ; Ii

Re: [Development] Building additional components with Conan for Qt 6

01.10.2020, 16:16, "Konstantin Tokarev" : > 01.10.2020, 16:07, "Richard Weickelt" : >>  Hello Ilkka, >> >>  thanks for the heads up. I have some further questions: >> >>  1. Will Conan be used to manage dependencies of Qt as well? > >

Re: [Development] Building additional components with Conan for Qt 6

01.10.2020, 15:37, "Iikka Eklund" : > To make it easier to leverage new package manager functionality Qt Installer > starts providing conan(.exe) client (https://conan.io) > which can be used to build the additional libraries from source packages > along with your CMake project. FWIW, Conan

Re: [Development] Building additional components with Conan for Qt 6

01.10.2020, 16:07, "Richard Weickelt" : > Hello Ilkka, > > thanks for the heads up. I have some further questions: > > 1. Will Conan be used to manage dependencies of Qt as well? If this is the plan, note that there is infrastructure [1] for using Conan in provisioning images, with

[Development] How to debug segfaulting test in Coin

Hello, What is the usual procedure of debuggin test segfaults? As far as I can see now all configurations print "Skip uploading core files because CORE_FILES_PATH is not set in the environment" so it's not possible to get any further then fact that test finished with segmentation fault. Is

Re: [Development] QVariant comparison in Qt6

18.09.2020, 11:40, "Lars Knoll" : >>  On 18 Sep 2020, at 10:28, Albert Astals Cid >> wrote: >> >>  El divendres, 18 de setembre de 2020, a les 10:22:16 CEST, Lars Knoll va >> escriure: >>>  Sorting and equality are two different things. QVariant has never supported >>>  a lessThan operator.

Re: [Development] Applications using -fno-rtti

20.06.2020, 23:49, "Thiago Macieira" : > On Saturday, 20 June 2020 11:31:25 PDT Alberto Mardegan wrote: >>  I think I missed an announcement about Qt applications having to use >>  RTTI; on the opposite, I thought that the whole point of QMetaObject was >>  not to require RTTI support; has this

Re: [Development] Applications using -fno-rtti

20.06.2020, 22:12, "Allan Sandfeld Jensen" : > On Samstag, 20. Juni 2020 21:00:27 CEST Alberto Mardegan wrote: >>  On 20/06/20 21:42, Konstantin Tokarev wrote: >>  > Comparing metaObject() with staticMetaObject() is wrong because it would >>  > fail e

Re: [Development] Applications using -fno-rtti

20.06.2020, 21:34, "Alberto Mardegan" : > Hi all! >   A couple of days ago a bug was filed against a project of mine, which > has been built with -fno-rtti since Qt4 times: > >   https://bugzilla.opensuse.org/show_bug.cgi?id=1172904 > > The bug, it appears, is a crash in QProcess due to the use

Re: [Development] Patching QtWebView to use QtWebkit "rebooted"?

11.06.2020, 20:19, "René J.V. Bertin" : > On Thursday June 11 2020 12:43:11 Konstantin Tokarev wrote: > >> Main reason behind QtWebView is described in the root page of its >> documentation, and it's about mobile platforms, namely Android, iOS, and >> also W

Re: [Development] Patching QtWebView to use QtWebkit "rebooted"?

11.06.2020, 11:11, "René J.V. Bertin" : > On Thursday June 11 2020 04:31:59 Konstantin Tokarev wrote: > >> Whole point of QtWebView is to use platform specific backends on platforms >> where they do exist, at the cost of limited API. If you need to use >> p

Re: [Development] Patching QtWebView to use QtWebkit "rebooted"?

11.06.2020, 01:10, "René J.V. Bertin" : > Hi, > > Suppose I wanted to patch QtWebView so it will use WebKit2 from the rebooted > QtWebKit libraries instead of the QtWebEngine bloatware, how feasible would > that be? A rabbithole, a question of reparenting and changing a limited > number of

Re: [Development] Using dwz on Qt

14.05.2020, 13:34, "Allan Sandfeld Jensen" : > Hi Qt > > I recently discovered there is a binutils tools for size optimizing dwarf > debug symbols, and it really works. When applied to Qt debug symbol binaries > it makes them about 25% smaller on average (some up to 40% smaller). And that > is

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

14.04.2020, 22:18, "Ville Voutilainen" : > On Tue, 14 Apr 2020 at 12:31, Lars Knoll wrote: >>  What kind of argument is that? htons as a macro was worth considering, but >> the ones in Qt are not? >> >>  Fixing the htons macro also "only requires changing one place" in the >> System C

Re: [Development] Can QImage format plugins require QGuiApplication?

14.04.2020, 02:27, "Giuseppe D'Angelo via Development" : > Il 13/04/20 18:50, Kevin Kofler ha scritto: >>  Today, a user on #fedora-kde ran across a crash which resulted from: >>  * a GTK+/GNOME application (Jami) using (for some reason) QImage to load >> images, without a QGuiApplication

[Development] Coin: default build instructions in yaml format

Hello, Do "classic" qmake-based build instructions of Qt modules exist in a format suitable for module_config.yaml? If no, is it possible to write module_config.yaml which would "inherit" default build but specify custom "accept_configuration:" block? -- Regards, Konstantin

Re: [Development] GitHub Pull requests

15.03.2020, 05:30, "Thiago Macieira" : > On Saturday, 14 March 2020 09:11:39 EST Konstantin Tokarev wrote: >>  My feeling about the last item is quite opposite: >>  * UI cuts long lines, when I wanted to check if specific compiler flag is >>  actually in u

Re: [Development] GitHub Pull requests

12.03.2020, 23:31, "Robert Löhning" : > Hi, > > after having worked in a project in GitHub for a couple of months now > and seeing their CI from the user perspective, this sounds feasible to me. > ... > - the progress and results are comprehensible, you can look at the CI > run just like you

Re: [Development] GitHub Pull requests

13.03.2020, 08:55, "Thiago Macieira" : > For a complex set of needs like Qt's, you'l still need a dedicated person or > multiple people. And this isn't free either, despite there being a lot of free > CIs for open source projects: first, because it's meant to serve the > commercial version too

Re: [Development] GitHub Pull requests

11.03.2020, 15:18, "Oswald Buddenhagen" : > On Tue, Mar 10, 2020 at 02:40:41PM +, Cristian Adam wrote: >> What about Pull requests? > > before you continue reinventing the wheel, i recommend that you read the > comments on QTPM-314 (yes, all of them). "You can't view this issue It may have

Re: [Development] GitHub Pull requests

10.03.2020, 22:26, "Matthew Woehlke" : > On 10/03/2020 12.19, Cristián Maureira-Fredes wrote: >>  On 3/10/20 3:40 PM, Cristian Adam wrote: >>>  What stops us from accepting the contributions via GitHub? >>> >>>  Is it: >>> >>>   1. The CLA >>>   2. Qt Account >>> >>>  For the CLA one can simply

Re: [Development] GitHub Pull requests

10.03.2020, 19:25, "Cristián Maureira-Fredes" : > Hello, > > On 3/10/20 3:48 PM, Konstantin Tokarev wrote: >>  I think, lowering barrier of entry at expense of reviewers' convenience >> should >>  have its limits > > Totally agree, > so we should pl

Re: [Development] GitHub Pull requests

10.03.2020, 17:42, "Cristian Adam" : > Hi, > > With the “GitHub issues” E-Mail thread we made sure the Issues are gone > > from the projects. > > What about Pull requests? > > For example qtbase has 7 pull requests.  Usually people point out that > > the Qt project uses a different collaboration

Re: [Development] Github issues

06.03.2020, 17:07, "Alex Blasche" : > I fixed all of them up. What about setting issue template with warning in case situation repeats in future? To do this you create ".github" repository inside organization, and add ISSUE_TEMPLATE file there. -- Regards, Konstantin

Re: [Development] Github issues

06.03.2020, 14:04, "Alex Blasche" : >> Thanks for the heads up. Whoever is maintaining those repos (?) need to turn >> off issues: >> >https://help.github.com/en/github/managing-your-work-on-github/disabling-issues > > I wish this could be done via the parent organization. But there doesn't

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

28.02.2020, 21:34, "Thiago Macieira" : > On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: >>  If we had to do it over again, it might make sense to follow Python and >>  make signals *objects* instead of *methods*. Then the code would look like: >> >>    this->emptied.emit(...); >

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

26.02.2020, 19:28, "Alex Blasche" : >>  Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø: >>  > We don’t need one rule to rule them all either. Many signals are named >>  fooChanged(), and can perfectly well stand on their own, without >> annotations. >>  Corner cases like "emit pressed();” can be

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

26.02.2020, 16:34, "Simon Hausmann" : > Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø: >>>  We’re neither enforcing the use of ‘emit’ currently. And I honestly find >>> most of the alternatives to be worse than no annotation at all. >>  I agree. >> >>  As others have argued, a signal is not

Re: [Development] Priority field in Jira

Actually, priority field is not that useful. Anything except P0 and P1 can hang indefinitely in unsolved state, and I agree that assigning P0 or P1 should be restricted. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

24.02.2020, 18:19, "Allan Sandfeld Jensen" : > > Yeah you would need something like qEmit(_signal, Args..) or without & > using a macro. Or.. qEmit(std::bind(_signal, Args...)); FWIW, using lambda expression is almost always a better solution that std::bind. -- Regards, Konstantin

Re: [Development] Commercial support for Coin and related infrastructure

21.02.2020, 18:37, "Volker Hilsheimer" : >>  On 20 Feb 2020, at 16:28, Konstantin Tokarev wrote: >> >>  Hello, >> >>  Are there any options available for subject? I've tried to use official >> contacts page, but it forces use of corporate email,

Re: [Development] Gerrit comment "Continuous Integration: Running"

23.02.2020, 23:42, "Liang Qi" : > Please help to create ticket for Project:Coin(COIN) in jira, thanks. https://bugreports.qt.io/browse/COIN-514 -- Regards, Konstantin ___ Development mailing list Development@qt-project.org

[Development] Gerrit comment "Continuous Integration: Running"

Weird thing is happening with Coin or Gerrit - all integrating changes got "Continuous Integration: Running" comment. Restaging leads to "Continuous Integration: Running" posted again to gerrit with state changed back to Active. Affected changes:

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

21.02.2020, 16:18, "Ville Voutilainen" : > On Fri, 21 Feb 2020 at 14:58, Sérgio Martins wrote: >>  > Why do I need to know that it's a signal being emitted? How is that >>  > "vital information"? I could just as well >>  > invoke any other callback, but I find myself not exactly yearning for >>

[Development] Commercial support for Coin and related infrastructure

Hello, Are there any options available for subject? I've tried to use official contacts page, but it forces use of corporate email, but my request has nothing to do with any commercial development. -- Regards, Konstantin ___ Development mailing

Re: [Development] Co-maintainer of QtNetwork

20.02.2020, 08:48, "Timur Pocheptsov" : > Hi all, > > 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

[Development] Patch workflow in qt5 supermodule (provisioning)

Hello, In the light of recent changes, should provisioning patches be merged to dev first now and then cherry-picked, or previous workflow remains? -- Regards, Konstantin ___ Development mailing list Development@qt-project.org

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

12.02.2020, 12:36, "Vitaly Fanaskov" : >>  You seem to repeat your initial statements. > > Yes, because most of the participants of this discussion tend to agree, > as far as I can see. AFAIK, we don't have a procedure to make project-level decisions by majority vote. If we want to achieve

Re: [Development] Changes to Qt offering

28.01.2020, 19:57, "Matthew Woehlke" : > On 28/01/2020 11.07, Alberto Mardegan wrote: >>  But it will discourage contributions, and encourage competition from >>  other Qt consulting companies > > At this point, I'm not sure that's a *bad* thing... I'm pretty sure that "discourage

Re: [Development] Changes to Qt offering

27.01.2020, 21:30, "Tuukka Turunen" : > Hi, > > I do not know why the link does not work. But I remember that post very well. > > On hindsight, it was too much of a rush back then to ask everyone to create a > Qt account immediately. > > As I wrote in my earlier reply, situation is different

Re: [Development] Changes to Qt offering

27.01.2020, 17:36, "Lars Knoll" : > The second change is that a Qt Account will be in the future required for > binary packages. Source code will continue to be available as currently. This > will simplify distribution and integration with the Marketplace. In addition, > we want open source

Re: [Development] Moving math3d classes from GUI to CORE

23.01.2020, 15:56, "Laszlo Agocs" : > 4. Longer term, let's rather focus the energy on improving performance (via > SSE, NEON) in math3d, as that would probably bring more benefits to Qt Quick > and Quick 3D than spending effort on trying to get QtCore compete with > existing linear algebra

Re: [Development] QtCS19 Notes: Qt 6 Network Overview

26.11.2019, 16:11, "Mårten Nordheim" : > On 26.11.2019 13:54, Konstantin Tokarev wrote: >>  What about an elephant in the room, i.e. HTTP/3? Will it be implemented >> anytime soon? > > Given the size and requirements of QUIC (and http3) we plan to wait for &

Re: [Development] QtCS19 Notes: Qt 6 Network Overview

What about an elephant in the room, i.e. HTTP/3? Will it be implemented anytime soon? 21.11.2019, 10:55, "Maurice Kalinowski" : > Hi, > > Following the notes taken on the Networking session: > > - What to do in Networking for Qt 6 > ○

Re: [Development] QML 3 and JavaScript

11.11.2019, 13:35, "Kevin Kofler" : > Simon Hausmann wrote: >>  Am 11.11.19 um 09:10 schrieb Dmitriy Purgin: >>>  I understand that QML 2 is not going anywhere in Qt 6 but maintaining >>>  both QML 2 and QML 3 will be a burden for the developers of the Qt >>>  Framework, and I'm afraid QML 2

Re: [Development] Porting QT to new OS

07.11.2019, 18:08, "drwho" : > On 2019-11-07 12:42 a.m., Thiago Macieira wrote: >>  On Wednesday, 6 November 2019 20:41:10 PST martin ribelotta wrote: >> >>>  4) What about the memory footprint? >>  A couple of megabytes. > > I'd love to see a build how too that results in a couple of megabytes.

Re: [Development] When next Coin update can be expected?

ches are urgent then I think we can take those in as hotfixes if > production update keeps pending too long. That would be nice, thanks! > > Br > Heikki > > -Original Message- > From: Development On Behalf Of > Konstantin Tokarev > Sent: perjantai 1. marrask

Re: [Development] When next Coin update can be expected?

29.10.2019, 13:29, "Konstantin Tokarev" : > In particular, I'm interested in fixes for COIN-412 and COIN-421 Ping -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

[Development] When next Coin update can be expected?

In particular, I'm interested in fixes for COIN-412 and COIN-421 -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

[Development] Provisioning error on Ubuntu 18.04 image

Trying to provision Ubuntu 18.04 image with older commits of qt5 repo on 5.13.2 branch (so that image is not just taken from cache) results in the following reproducible error: + sudo apt-get install docker-ce -y Reading package lists... Building dependency tree... Reading state information...

[Development] qtwebglplugin fails to build in Coin on Windows (5.13.2 branch)

Following error had reproduced several times for me: qwebglintegration_p.h:43:10: fatal error: QtFontDatabaseSupport/private/qwindowsfontdatabase_p.h: No such file or directory Both MinGW and MSVC seem to be affected. Example build logs:

Re: [Development] The age-old T* foo vs. T *foo

18.10.2019, 19:11, "Sérgio Martins" : > On Thu, Oct 17, 2019 at 7:05 PM Ville Voutilainen > wrote: >>  Since we are about to do a major version upgrade, should be stop being >>  a special snowflake in the C++ world and start attaching pointer-stars >>  and reference-ampersands to the type

Re: [Development] The age-old T* foo vs. T *foo

17.10.2019, 21:06, "Ville Voutilainen" : > As a quick example of how our current style is just odd, consider > > for (auto & : oink) > > Sure, that's in accordance with our style. It looks very out of place when > coming back to our code after adventures in other code. Quick reading > of it

Re: [Development] Coming up: Coin production update

16.10.2019, 13:42, "Aapo Keskimölö" : > Hi Qt Developers, > > We are preparing for Coin production update to baseline version 1.2.0 > which will contain a major change that will force all builds to compile > their test binaries during build phase by default - unless they are > static builds

Re: [Development] Change in open-source licensing of Qt Wayland Compositor, Qt Application Manager and Qt PDF

11.10.2019, 04:09, "Kevin Kofler" : > I wrote: >>  Tuukka Turunen wrote: >>>  Qt PDF is a new module, which has not been released earlier despite the >>>  pre-release code being available. Changing the license to GPLv3 will >>>  allow The Qt Company to support the module going forward. >> >>  

Re: [Development] Where to find development snapshots of Qt

09.09.2019, 17:15, "Richard Weickelt" : > Hello, > > I would like to build and test Qbs against development snapshots of Qt in > order to prevent disasters like https://bugreports.qt.io/browse/QBS-1492 from > happening again. > > Are there any snapshots of the Qt SDK available in some form?

Re: [Development] Qt 6: inline namespace Qt

06.09.2019, 20:28, "Thiago Macieira" : > On Friday, 6 September 2019 09:04:09 PDT Giuseppe D'Angelo via Development > wrote: >>  I was actually proposing option A, to avoid clashes. The Qt:: namespace >>  at the moment is simply too big to reasonably claim that there will be >>  no conflicts. A

Re: [Development] Requiring minimum GCC 7/MinGW (was: Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral))

23.08.2019, 21:11, "Thiago Macieira" : > On Friday, 23 August 2019 09:04:55 PDT Konstantin Tokarev wrote: >>  > libgcc on pure MinGW doesn't use winpthreads, it uses Win32. >> >>  std::thread and co are not implemented for win32, so we use pthreads version >

Re: [Development] Requiring minimum GCC 7/MinGW (was: Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral))

23.08.2019, 18:11, "Thiago Macieira" : > On Friday, 23 August 2019 00:12:50 PDT Roland Winklmeier wrote: >>  Just for your awareness: There is an old bug related to thread_local in >>  MinGW which afaik was never fixed. It compiles correctly, but every >>  executable crashes during shutdown. Not

Re: [Development] HEADS-UP: QStringLiteral

22.08.2019, 17:14, "Edward Welbourne" : > Konstantin Tokarev (22 August 2019 15:48) wrote: >>  At least we need a wiki page with optimization guidelines > > Would a page in our documentation suffice ? > https://codereview.qt-project.org/c/qt/qtdoc/+/268079 > Sure,

Re: [Development] HEADS-UP: QStringLiteral

22.08.2019, 16:44, "Martin Smith" : > But Marc, your last paragraph calls for separating the API and implementation > discussions, but the paragraph just before it argues that the API to work > around our slowness is vital. > > If Qt developers must not forget Q_DECLARE_TYPEINFO, why isn't it

Re: [Development] HEADS-UP: QStringLiteral

22.08.2019, 02:39, "Kevin Kofler" : > André Pönitz wrote: >>  Traditionally, "ease of use" and "consistent API" have been a core values >>  of Qt, even consciously bought at the cost of some bytes and some cycles. >> >>  Of course, this has meant that in certain parts of certain types of >>  

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

21.08.2019, 22:39, "Henry Skoglund" : > Yes, I also used app-local deployment, problem is that Microsoft has not > committed 100% to allow it (as far as I know), instead they have a > seesaw approach, saying "you can temporarily use app-local deployment but.." > > Anyway, my ultimate goal is to

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

21.08.2019, 22:56, "Thiago Macieira" : > On Wednesday, 21 August 2019 12:29:29 PDT Massimo Callegari via Development > wrote: >>  Instead, please consider switching to MSYS2 for Qt6 > > MSYS2 is Cygwin-like. It tries to emulate a Unix on Windows. It's great for > porting Unix software to Windows

Re: [Development] HEADS-UP: QStringLiteral

21.08.2019, 19:02, "Thiago Macieira" : > On Wednesday, 21 August 2019 08:23:27 PDT Konstantin Tokarev wrote: >>  I hope that standard committee will never introduce implicit generation of >>  UTF16 literals from C string literals. > > You're over 10 years too lat

Re: [Development] HEADS-UP: QStringLiteral

21.08.2019, 18:29, "Tor Arne Vestbø" : >>  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: >>>&

Re: [Development] HEADS-UP: QStringLiteral

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 wrote: >>>  On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:  This should just be test[“key”] = “value”. How do we

Re: [Development] HEADS-UP: QStringLiteral

21.08.2019, 18:19, "Tor Arne Vestbø" : >>  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

Re: [Development] Accelerating deprecation of MSVC 2017

21.08.2019, 00:45, "Thiago Macieira" : > I'd like to propose we announce now that it will not be supported for Qt 5.15. > > Even if 2019 still has code generation problems. Does it mean that you recommend using 2015 instead? > We should assume that MS will > fix them soon. > > -- > Thiago

Re: [Development] Dev branch moving towards Qt 6

16.08.2019, 18:25, "Thiago Macieira" : > On Friday, 16 August 2019 03:26:09 PDT 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

Re: [Development] Supported compilers for Qt 6

14.08.2019, 23:53, "Allan Sandfeld Jensen" : > On Tuesday, 13 August 2019 18:13:05 CEST Thiago Macieira wrote: >>  On Tuesday, 13 August 2019 00:50:48 PDT Friedemann Kleint wrote: >>  > Hi, >>  > >>  > > VC++ 2019 >>  > >>  > Just for the record, this compiler still has a number of optimizer

Re: [Development] Qt PDF as a new TP module for Qt 5.14

12.08.2019, 21:01, "Thiago Macieira" : > On Monday, 12 August 2019 08:24:05 PDT Konstantin Tokarev wrote: >>  I guess bigger problem is that Poppler is GPL. PDFium is probably the only >>  permissively licensed PDF engine. > > And? If Poppler is a superior alternat

Re: [Development] Qt PDF as a new TP module for Qt 5.14

12.08.2019, 18:25, "Konstantin Tokarev" : > 12.08.2019, 18:19, "Thiago Macieira" : >>  On Monday, 12 August 2019 05:35:06 PDT Kai Köhne wrote: >>>   I suggest to promote Qt PDF to a Qt module. For Qt 5.14, it will be in >>> Tech >>

Re: [Development] Qt PDF as a new TP module for Qt 5.14

12.08.2019, 18:25, "Konstantin Tokarev" : > 12.08.2019, 18:19, "Thiago Macieira" : >>  On Monday, 12 August 2019 05:35:06 PDT Kai Köhne wrote: >>>   I suggest to promote Qt PDF to a Qt module. For Qt 5.14, it will be in >>> Tech >>

Re: [Development] Qt PDF as a new TP module for Qt 5.14

12.08.2019, 18:19, "Thiago Macieira" : > On Monday, 12 August 2019 05:35:06 PDT Kai Köhne wrote: >>  I suggest to promote Qt PDF to a Qt module. For Qt 5.14, it will be in Tech >>  Preview state, and Shawn Rutledge is volunteering to be the maintainer. >>  Although still staying an independent

Re: [Development] atomic reference counting implementation

07.08.2019, 21:02, "Mutz, Marc via Development" : > Hi Philippe, > > This was discussed in > https://codereview.qt-project.org/c/qt/qtbase/+/66118. See, in > particular, Olivier's comment. > > TL;DR: ref() is documented to be ordered, so cannot be changed. > > Consequently, I didn't merge it

Re: [Development] is it possible to increase the max. document size for the JSON parser?

07.08.2019, 02:21, "Sérgio Martins via Development" : > On 2019-08-06 22:49, Sérgio Martins via Development wrote: >>  On 2019-08-06 13:48, René J. V. Bertin wrote: >>>  Joerg Bornemann wrote: >>>  Unfortunately, this isn't possible at the moment.  This issue is tracked in

Re: [Development] Maybe add some kind of accessible pipeline for QSettings serialization in Qt6?

09.07.2019, 18:12, "NIkolai Marchenko" : > We (at our company) realy, REALLY don't like qsettings for a multitude of > reasons but are forced to deal with it because the details of how UI types > are saved are hidden deep in the qt's implementation and are subject to any > kind of changes qt

Re: [Development] Oslo, we have a problem [char8_t]

06.07.2019, 17:20, "Mutz, Marc via Development" : > On 2019-07-06 14:50, Fabian Kosmale wrote: > [...] >>   See https://godbolt.org/z/e6OinY for how this would look for a >>  trivial function. > > [...] > > Now also handle test(NULL) and extend to binary: > > test2([0, NULL, nullptr, "",

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

01.07.2019, 17:10, "Giuseppe D'Angelo" : > Il 01/07/19 15:56, Konstantin Tokarev ha scritto: >>  If we include assumption #4, we can just render document >> paragraph-by-paragraph, encode >>  resulting images of paragraphs to PNG and send to UI process.

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

01.07.2019, 13:30, "Ville Voutilainen" : > On Sat, 29 Jun 2019 at 14:34, Konstantin Tokarev wrote: >>  29.06.2019, 14:27, "Konstantin Tokarev" : >>  > 29.06.2019, 14:00, "Giuseppe D'Angelo" : >>  >> Il 29/06/19 12:59, Konstantin To

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

29.06.2019, 14:27, "Konstantin Tokarev" : > 29.06.2019, 14:00, "Giuseppe D'Angelo" : >>  Il 29/06/19 12:59, Konstantin Tokarev ha scritto: >>>>   This makes the exercise an couple of orders of magnitude harder, not >>>>   simpler. Whi

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

29.06.2019, 14:00, "Giuseppe D'Angelo" : > Il 29/06/19 12:59, Konstantin Tokarev ha scritto: >>>  This makes the exercise an couple of orders of magnitude harder, not >>>  simpler. Which cross platform, efficient, flicker-free, (possibly >>>  supporte

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

29.06.2019, 13:52, "Giuseppe D'Angelo via Development" : > Il 29/06/19 09:57, Cristian Adam ha scritto: >>  We could have the help plugin using an external process, this way that >> process can >>  use the software renderer by itself. > > This makes the exercise an couple of orders of

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

28.06.2019, 14:29, "Jedrzej Nowacki" : > On Friday, June 28, 2019 11:32:43 AM CEST Cristian Adam wrote: >>  Hi, >> >>  Some of you might have been familiar with white papers such as Qt QML v >>  HTML5 – a practical >>  comparison

Re: [Development] Assistant WebKit/WebEngine support

27.06.2019, 22:15, "André Pönitz" : > On Thu, Jun 27, 2019 at 06:57:08AM +0200, Richard Weickelt wrote: >>  Is it well known, how many QtCreator users are even using the integrated >>  help functionality? How many Qt users are using QtAssistant and how many >>  prefer the online documentation? >

Re: [Development] Moving to Gerrit 2.16.9

27.06.2019, 18:12, "Thiago Macieira" : > On Thursday, 27 June 2019 07:10:36 PDT Frederik Gladhorn wrote: >>  The only real challenge was upgrading Bazel, since every Gerrit version >>  seems to only compile with one exact Bazel version (roughly). > > Argument against home-cooked, not-widely-used

Re: [Development] Assistant WebKit/WebEngine support

26.06.2019, 02:57, "Bastiaan Veelo" : > On 26/06/2019 00:15, Jean-Michaël Celerier wrote: >> There's also Zeal which is a nice Qt-based documentation browser which >> covers much more than the current .qch offering: https://zealdocs.org/ & >> https://github.com/zealdocs/zeal >> >> I see it

Re: [Development] Assistant WebKit/WebEngine support

26.06.2019, 11:13, "Eike Ziller" : > I agree with Thiago that this also requires WebKit to be updated with > security fixes. It will potentially show downloaded content from anywhere, > and it’s not nice if someone can offer a malicious qch, using known security > issues in WebKit. And with

Re: [Development] Assistant WebKit/WebEngine support

25.06.2019, 22:32, "Bastiaan Veelo" : > On 21/05/2019 14:50, Konstantin Tokarev wrote: >>  21.05.2019, 15:47, "Bastiaan Veelo" : >>>  On 20/05/2019 19:02, Konstantin Tokarev wrote: >>>>    [...] Current version of QtWebKit from

Re: [Development] Assistant WebKit/WebEngine support

25.06.2019, 19:01, "Thiago Macieira" : > On Tuesday, 25 June 2019 06:43:06 PDT Eike Ziller wrote: >>  What is the state of QtWebKit(2) > > It hasn't been updated in years. Don't use it, since it's clearly not getting > security updates. New version is currently in development, and should be

  1   2   3   4   5   6   7   >