Re: [Development] New Chief Maintainer

Hi, I want to express my profound support for Allan (since I can't vote). He has deep deep roots in the world of Open Source communities and remains connected to KDE. I think he's a fantastic candidate and I'd think that it's very well possible for him to prioritize the needs of the Qt project as

Re: [Development] New property system

On Wed, 26 Aug 2020 at 09:20, Lars Knoll wrote: > > Hi all, > > After the long discussions a few weeks back about the new property system and > some trial to port the existing properties over to the new system, it became > somewhat clear to me that the approach we had tried so far won’t work and

Re: [Development] QProperty and library coding guide

Olivier Goffart schrieb am Fr. 17. Juli 2020 um 19:12: > On 17/07/20 19:00, Thiago Macieira wrote: > > On Friday, 17 July 2020 09:34:54 PDT Lars Knoll wrote: > >>> I'll just post this and let you ponder the consequences of this choice > for > >>> Linux: > >>> https://godbolt.org/z/nhex5x > >> > >

Re: [Development] QProperty and library coding guide

Thiago Macieira schrieb am Mi. 22. Juli 2020 um 17:46: > On Wednesday, 22 July 2020 00:05:34 PDT Simon Hausmann wrote: > > That said, this very construct that you're referring to, that is what > > has been in user > > code since QtDeclarative was been r

Re: [Development] QProperty and library coding guide

Hi, Thiago Macieira schrieb am Fr. 17. Juli 2020 um 19:57: > On Wednesday, 15 July 2020 13:20:33 PDT Thiago Macieira wrote: > > In addition, I'd like someone to explain here: > [snip] > > 5) How you're going to fix the UB in the code generated by moc. This > requires > a satisfactory answer of C

Re: [Development] Stepping down as moc maintainer.

Terrific choice! +1 Simon Lars Knoll schrieb am Di. 5. Mai 2020 um 09:44: > Hi all, > > I’m happy to say that I have a great candidate who’d be willing to take > over the maintainership. Fabian Kosmale would be interested in taking over > from Olivier. He has been working on a couple of featu

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

ehalf of Thiago Macieira Sent: Tuesday, April 28, 2020 17:42 To: development@qt-project.org Subject: Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems On Tuesday, 28 April 2020 07:20:33 PDT Thiago Macieira wrote: > On Monday, 27 April 2020 13:54:13 PDT Simon

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

:09 schrieb Simon Hausmann :  Hi, I can't really think of anything that's changed in the default macOS setup that would affect the locale encoding. The scripts that are run are here: https://code.qt.io/cgit/qt/qt5.git/tree/coin/provisioning/qtci-macos-10.14-x86_64 but I'

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

Hi, I can't really think of anything that's changed in the default macOS setup that would affect the locale encoding. The scripts that are run are here: https://code.qt.io/cgit/qt/qt5.git/tree/coin/provisioning/qtci-macos-10.14-x86_64 but I'm not even sure that it's possible to "misconfig

Re: [Development] Circular dependencies for Q_PROPERTY

Hi, I think the solution may involve keeping forward-declarations but adding visibility to the "other" types in moc generated code by using Q_MOC_INCLUDE in A to include B and vice versa. Does that make sense? Simon From: Development on behalf of Mike Krus vi

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

Charlottenburg, HRB 144331 B -- Von: Development im Auftrag von Simon Hausmann Gesendet: Donnerstag, 23. April 2020 10:52 An: Laszlo Agocs ; Jaroslaw Kobus ; Lars Knoll Cc: Qt development mailing list Betreff: Re: [Development] Proposal: Deprecate QVector in Qt 6 Hi, If we

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

rsday, April 23, 2020 15:52 To: development@qt-project.org Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 On Thursday, 23 April 2020 02:15:29 PDT Simon Hausmann wrote: > Proposed: > > template using QVector = QList; // mark deprecated > template class QList { $(

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

nt@qt-project.org Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 El dijous, 23 d’abril de 2020, a les 10:23:21 CEST, Simon Hausmann va escriure: > Hi, > > Yes, apologies, QList is an alias for QVector. I propose to switch that > around. But keeping which implementation? I.e.

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

, April 23, 2020 10:52 To: Simon Hausmann Cc: development@qt-project.org Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 Hi Simon, I think having a name that is close to the standard is very important as it makes it easy to find the Qt counterpart. Back in the days I had to ask a

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

ot concerned about the popularity of Qt in online forums but rather about the practical difficulties of developing with Qt. Simon From: Laszlo Agocs Sent: Thursday, April 23, 2020 10:41 To: Jaroslaw Kobus ; Lars Knoll ; Simon Hausmann Cc: Qt development mailin

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

Simon From: Dmitriy Purgin Sent: Thursday, April 23, 2020 9:53 To: Simon Hausmann Cc: development@qt-project.org Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 Hi Simon, I hope it's not a belated April's Fool joke? As far as I can remember

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

r in Qt 6 El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va escriure: > Hi, > > In dev we've had QVector being an alias for QList for a while now. For the > 6.0 release this particular topic (QList/QVector) suggests two goals (among > others): > > (

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

] Proposal: Deprecate QVector in Qt 6 El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va escriure: > Hi, > > In dev we've had QVector being an alias for QList for a while now. It's the other way around, isn't it? corelib/tools/qcontainerfwd.h: template using

[Development] Proposal: Deprecate QVector in Qt 6

Hi, In dev we've had QVector being an alias for QList for a while now. For the 6.0 release this particular topic (QList/QVector) suggests two goals (among others): (1) Use the same type throughout the public API of Qt. (2) Make it easy for our users to maintain a code base that works wi

Re: [Development] Coin: Maintainer has changed

Thank you so much Aapo for your work on Coin! And thank you Toni for stepping up :) Simon From: Aapo Keskimölö Sent: Friday, March 27, 2020 8:35 To: development@qt-project.org ; Qt CI ; Coin Team Cc: Olli Hirvonen ; Tuukka Turunen Subject: Coin: Maintainer

Re: [Development] Make Qt6 JNI API safer to use

Hi, I think it would be great to have a result type in the Qt API and use that, instead of C++ exceptions. In theory we could use std::variant, but I think the API inconvenient for the use-case of a result. That wouldn't prevent us from using it in the implementation though. Simon ___

Re: [Development] Qt5.15 deprecating & Qt6 removing QProcess::setupChildProcess

Hi, Declarative in 5.15 (5.14?) has public API taking a std::function and that appears to be okay so far :) Simon > Am 27.02.2020 um 18:53 schrieb Thiago Macieira : > > On Monday, 24 February 2020 03:07:00 PST Lars Knoll wrote: >>> On 21 Feb 2020, at 18:49, Thiago Macieira >>> wrote: >

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

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 special, in the sense that any > function can do anyt

Re: [Development] Migrate QStateMachine from Qt Core

Hi, I think moving the implementations into one git repo would be a good move. In that case you could also move the qml state machine bindings from qtdeclarative (See src/imports folder). I don’t think merging the implementations is a good idea, I find they serve different purposes. Just my tw

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

On 31.01.20 11:07, Vitaly Fanaskov wrote: > Hello everyone, > > We’ve been discussing for a while how Qt6 API can be improved with using > smart pointers. Recently we came into some conclusions and want to > discuss them with the community. Thanks for taking the discussion here, Vitaly :) > Sm

Re: [Development] Forgot your Qt Account password?

It appears that somebody thought it would be funny to create a Qt Account with the development@qt-project.org email address. Qt Account Support folks, "please delete the account" ;-) Simon From: Development on behalf of Khuram Ali via Development Sent: Wedne

[Development] Proposal for dev

Hi, We have two things going on in dev right now: (1) Quite many changes are going into qtbase right now that change fundamentals, in a very positive way, I'd say. And more changes are scheduled. These typically require follow-up fixes in other repositories, due to use of private API or re

Re: [Development] Changes to Qt offering

Am 27.01.20 um 17:13 schrieb Bogdan Vatra via Development: > Hi Lars, > > În ziua de luni, 27 ianuarie 2020, la 16:34:44 EET, Lars Knoll a scris: >> Hi all, > [...] >> One is a change in policy regarding the LTS releases, where the LTS part of >> a release is in the future going to be restricted t

Re: [Development] Qt Marketplace

Hi, Yeah it’s quite interesting:). We’re trying it with the combination market place, installer and Conan. So we don’t have quite all the answers yet but it’s actively being worked on. This is not (yet?) related to Qt or Qt 6 itself though. Perhaps they’ll also connect in the future, but for n

Re: [Development] Qt Shader Tools as proper Qt module for Qt 6.0

Hi, Great :) In the chain of dependencies, do you see this right after qtbase and before for example qtdeclarative? Or do you foresee any use of the shader compiler in qtbase itself? I suppose at least for some examples it would make sense, which makes me wonder if those examples should move

Re: [Development] Proposing CMake as build tool for Qt 6

arget has changed from wip/qt6 to dev, but otherwise we're looking at preparing a merge soon for wider review. Simon >> On 6 Jun 2019, at 14:43, Sérgio Martins wrote: >> >> On Thu, Jun 6, 2019 at 12:45 PM Simon Hausmann wrote: >>> Hi, >>> >>

Re: [Development] QTCS2019 Notes from QtQml session

On 26.11.19 11:48, André Somers wrote: > > On 26/11/2019 08:56, Ulf Hermann wrote: >>> We have some code that evaluates JS in custom QQmlContexts with certain >>> "magic" context properties set (sort of like the "index" or "modelData" >>> context properties in delegates like Repeater.delegate). >>

Re: [Development] QTCS2019 Notes from QtQml session

On 25.11.19 16:55, Robin Burchell wrote: > On Mon, Nov 25, 2019, at 3:53 PM, Ulf Hermann wrote: >> Yes, but the problems with this construct are the same as with generic >> context properties: Your QML component requires some context that it >> doesn't declare. Therefore your code is not reusable

Re: [Development] QTCS2019 Notes from QtQml session

On 25.11.19 12:15, Robin Burchell wrote: >> We could detect this in qmllint by just continuing the search for IDs >> even if we've found a property. > We could, but if I may gently suggest, I think I can count most of the people > who use qmllint on a regular, useful basis on one hand ;-). You'r

Re: [Development] QML 3 and JavaScript

Am 11.11.19 um 18:13 schrieb Jason H: > If not Javascript, then what? Python? This is the first I've heard of > this. Just wondering what it is if not javascript? This is a little tricky to answer just in email text. But what I think I can do safely is show you two snippets of code from our ex

Re: [Development] Qt World Summit 2019: Qt for MCUs – A Deep Dive

e it though, but I'm crossing fingers with you :) Simon From: Alexander Forsch Sent: Tuesday, November 12, 2019 10:50 To: development@qt-project.org ; Simon Hausmann Subject: Qt World Summit 2019: Qt for MCUs – A Deep Dive Hello Simon Hausmann, I have visited

Re: [Development] QML 3 and JavaScript

Am 11.11.19 um 09:10 schrieb Dmitriy Purgin: > Hi all, > > as we learned at the recent Qt World Summit in Berlin, we're getting > QML 3 with Qt 6. There are some cool features and changes to improve > the clarity and the performance of the QML part but there is one thing > that bothers me: the

Re: [Development] Merging wip/qt6 to dev

p/qt6+status:open to see if you have any pending changes that need to be re-targeted or abandoned. The dependencies.yaml propagation is almost through, webengine and webview are pending. Simon From: Simon Hausmann Sent: Wednesday, October 2, 2019 15:57 To: Qt develo

Re: [Development] Nominating Vitaly Fanaskov as Approver

+1 Simon From: Development on behalf of Shawn Rutledge Sent: Wednesday, October 2, 2019 13:22 To: Qt development mailing list Subject: [Development] Nominating Vitaly Fanaskov as Approver Hi all, I would like to nominate Vitaly Fanaskov as approver for the

Re: [Development] Merging wip/qt6 to dev

. Simon ____ From: Simon Hausmann Sent: Thursday, September 26, 2019 13:07 To: Qt development mailing list Subject: Re: [Development] Merging wip/qt6 to dev Hi, Brief update on the status of the merge: After qtbase, the direct leaf modules such as qtsvg, qtimageformats, etc. we

[Development] Nominating Fabian Kosmale as approver

Hi, I'd like to nominate Fabian as approver as well. He started about four months ago digging deep into pretty much all aspects of the Qml engine - from grammar fixes, public C++ API, ES promise implementation, new language features (required properties) all the way to a brand new linter. As a

[Development] Nominating Dominik Holland for approver status

Hi, I would like to nominate Dominik for approver status. He started contributing to Qt back in 2013 and has been working primarily on the Qt automotive and embedded related bits. After such a long time of steady contributions and code peer-review in the automotive "corner", I do trust him to b

Re: [Development] Property bindings in Qt 6

Am 01.10.19 um 15:18 schrieb Eike Ziller: > >> On 26. Sep 2019, at 17:02, Simon Hausmann wrote: >> >> Hi, >> >> Earlier this year, Olivier, Samuel, Auri and I worked on a project to >> re-evaluate how we could bring the declarative Qt Quick approach o

Re: [Development] Property bindings in Qt 6

debt and mark those as clean) to mitigate the problem? > > Best regards, > Chris. > >> On Fri, Sep 27, 2019 at 1:06 AM Simon Hausmann wrote: >> >> Hi, >> >> Earlier this year, Olivier, Samuel, Auri and I worked on a project to >> re-evaluate how we could

Re: [Development] Property bindings in Qt 6

Yeah that’s one way that should work for sure. Simon > On 26. Sep 2019, at 20:54, Thiago Macieira wrote: > > On Thursday, 26 September 2019 08:38:40 PDT Mitch Curtis wrote: >> https://code.qt.io/cgit/qt/qtquickcontrols2.git/tree/src/quicktemplates2/qqu >> ickslider.cpp#n355 >> >> In the end

Re: [Development] Property bindings in Qt 6

of my head would be that setters in JavaScript can throw. Simon > On 26. Sep 2019, at 18:14, Shawn Rutledge wrote: > >  >> On 26 Sep 2019, at 17:44, Simon Hausmann wrote: >> >> Hi, >> >> Yeah, custom setters are required. >> >>

Re: [Development] Property bindings in Qt 6

> On 26. Sep 2019, at 17:38, Mitch Curtis wrote: > >  >> >> -Original Message- >> From: Development On Behalf Of >> Simon Hausmann >> Sent: Thursday, 26 September 2019 5:03 PM >> To: development@qt-project.org >> Subject

[Development] Property bindings in Qt 6

Hi, Earlier this year, Olivier, Samuel, Auri and I worked on a project to re-evaluate how we could bring the declarative Qt Quick approach of doing user interfaces closer to C++, in order to allow building and running user interfaces in very memory and processor-power constrained environments.

Re: [Development] Merging wip/qt6 to dev

indicates that something is quite broken. Simon ____ From: Simon Hausmann Sent: Wednesday, September 18, 2019 11:47 To: Lars Knoll Cc: Qt development mailing list Subject: Re: [Development] Merging wip/qt6 to dev Hi, Okay, qt5's dev branch has now a s

Re: [Development] Add functionality to QPdfWriter

Hi Erik, I briefly looked at the two tickets and I think they are sensible use-cases and your proposed API additions look minimal and good to me, too :) Unless somebody else can see anything that really makes this not fit, I'd feel positive about this having a chance of being accepted. Simon

Re: [Development] INTEGRITY

project.org Subject: Re: [Development] INTEGRITY Il 18/09/19 13:52, Simon Hausmann ha scritto: > Since the problem seems urgent to you, do you have any suggestion what > kind of target built binary you'd add to qtbase's build coverage that > includes linkage? Random su

Re: [Development] INTEGRITY

Hi, I'm afraid that I don't have answers to all of your questions (due to lack of knowledge), but for some I may be able to provide insight. Am 18.09.19 um 12:29 schrieb Mutz, Marc via Development: > Hi, > > Can someone expand on the plan forward for the supported INTEGRITY > toolchains? > > La

Re: [Development] Merging wip/qt6 to dev

pinning. Simon From: Lars Knoll Sent: Tuesday, September 17, 2019 10:03 To: Simon Hausmann Cc: Qt development mailing list Subject: Re: [Development] Merging wip/qt6 to dev I’d say yes, let’s merge those into dev as well. Those are all platforms we don’t want to support

Re: [Development] Qt modules, API changes and Qt 6

Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen: > On Tue, Sep 17, 2019 at 06:56:39AM +0000, Simon Hausmann wrote: >> When the todo list is empty and there are no more pending updates, >> the batch update is complete. If during that update there were no >> failures, the Q

Re: [Development] Merging wip/qt6 to dev

15 To: Simon Hausmann Cc: Qt development mailing list Subject: Re: [Development] Merging wip/qt6 to dev Hi, Great to get the wip/qt6 branches merged back into dev. I’d simply try to take the dependencies.yaml into use at the same time instead of having to work around the CI. Cheers, Lars On 17 Sep

[Development] Merging wip/qt6 to dev

Hi, Now that the Qt 5.15 branches exist and dev is intended to become Qt 6.0.0, the time has come to begin merging the wip/qt6 branches into dev. A wip/qt6 branch has been created for pretty much all repositories in qt6.git that are active (essential, addon, etc.) and two types of changes have

Re: [Development] Qt modules, API changes and Qt 6

Hi, I would like to provide an update to this (old) thread based on the development in the past months and weeks. Am 15.02.19 um 10:30 schrieb Frederik Gladhorn: > Hi, > > On fredag 15. februar 2019 07:31:33 CET Lars Knoll wrote: >> Summing up the discussion here. It looks like people overall ag

Re: [Development] Nominating David Edmundson as approver

+1 Simon From: Development on behalf of Johan Helsing Sent: Friday, August 23, 2019 14:15 To: development@qt-project.org Subject: [Development] Nominating David Edmundson as approver Hi all, I'd like to nominate David Edmundson as approver for the Qt Projec

Re: [Development] Proposal for an efficient and robust (de)serialization mechanism working with Qt-supported data

Hi Arnaud, I think that perhaps this is also a topic worth discussing at the Qt Contributor Summit, if you can attend. During a face-to-face discussion we may be able to find a good understanding more efficiently of what exactly it is that we need in Qt. I'm interesting in discussing how we ca

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

Hi, I ran into the crash a while ago in the CI. See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562 . Simon On 23. Aug 2019, at 23:12, Thiago Macieira mailto:thiago.macie...@intel.com>> wrote: On Friday, 23 August 2019 00:12:50 PDT Roland Winklmeier wrote: Just for your awareness: The

Re: [Development] Nominating Sona Kurazyan as approver

+1 Simon From: Development on behalf of Alexandru Croitor Sent: Friday, August 9, 2019 12:47 To: Alex Blasche Cc: development@qt-project.org Subject: Re: [Development] Nominating Sona Kurazyan as approver +1 > On 9. Aug 2019, at 12:42, Alex Blasche wrot

Re: [Development] qtlottie build broken: "Missing CMake tests. Either create tests in tests/auto/cmake"

I think I fixed that last week. What’s your sha1? There is not C++ application linkage for the module in question so cmake app linkage tests don’t make sense IMHO. Simon > On 22. Jul 2019, at 21:16, Thiago Macieira wrote: > > [the "or" part of the either is not applicable] > > Can someone pl

Re: [Development] Grooming the merges?

Am 17.07.19 um 11:01 schrieb Edward Welbourne: > Mutz, Marc (17 July 2019 07:05) >> The qt5.git integration[1] hasn't happened for a month or so (ok two >> weeks) and the >> [1] https://codereview.qt-project.org/c/qt/qt5/+/267105 > There's also [a] which has similar problems beyond my fu to fix: >

Re: [Development] Grooming the merges?

Hi, I think the vacation time is slowing things down. That said, I’ll take care of the remaining declarative changes (thanks Mitch for fixing some!) — those are on my todo. Simon > On 17. Jul 2019, at 07:07, Mutz, Marc via Development > wrote: > > Hi, > > The qt5.git integration[1] hasn't

Re: [Development] Moving to Gerrit 2.16.9

That’s good news! Thanks for making the upgrades :) Simon > On 27. Jun 2019, at 16:15, Frederik Gladhorn wrote: > > Hi, > > Just to keep the ball rolling, we prepared the upgrade to move from Gerrit > 2.16.7 to 2.16.9. I don't expect any real changes, but it's a good exercise > for us to st

Re: [Development] Assistant WebKit/WebEngine support

Am 26.06.19 um 14:44 schrieb Kirill Burtsev: > Hi, > > sorry, but that is not a right way to assess thing like memory consumption. > > Windows shows in a task manager just private memory (can not be used > by other processes) usage for process. And that is really takes 15-20 Mb > but just for sepa

Re: [Development] Assistant WebKit/WebEngine support

f ram ? On 6/26/19 1:12 PM, Simon Hausmann wrote: > > Am 25.06.19 um 23:53 schrieb Konrad Rosenbaum: >> Option 4: convert to WebEngine >> Pros: looks great; currently supported browser engine, only little >> porting work >> Cons: horrible memory footprint; acute termin

Re: [Development] Assistant WebKit/WebEngine support

Am 25.06.19 um 23:53 schrieb Konrad Rosenbaum: > Option 4: convert to WebEngine > Pros: looks great; currently supported browser engine, only little > porting work > Cons: horrible memory footprint; acute terminal featuritis; adds lots of > dependencies (disqualifies it for most/many people redist

Re: [Development] Assistant WebKit/WebEngine support

Am 25.06.19 um 10:10 schrieb Morten Sørvig: > I’m not sure if it has been mentioned; we have another option which is to use > the OS web browser component via the Qt WebView module. > > The benefits would be > > * up-to-date web browser (and someone else keeps it up to date for us) > * insignific

Re: [Development] Assistant WebKit/WebEngine support

Hi, I think you're right, the linkage appears to be due to the use of QQuickWidget as child widget of QWebEngineView. Do you think that's a problem? Simon From: Giuseppe D'Angelo Sent: Tuesday, June 25, 2019 10:02 To: Simon Hausmann;

Re: [Development] Assistant WebKit/WebEngine support

nd Chrome are all built using clang these days) Simon From: Development on behalf of Konrad Rosenbaum Sent: Tuesday, June 25, 2019 7:50 To: development@qt-project.org Subject: Re: [Development] Assistant WebKit/WebEngine support Hi, On 6/24/19 2:43 PM, Simo

Re: [Development] Assistant WebKit/WebEngine support

Hi, QtQuick 2 is not required for using WebEngine and there is support for software rendering. The existing Qt Creator integration as well as the proposed patch to Qt Assistant to use Web Engine is using the widgets integration. To put it to a test, I just installed a fresh Windows 10 in Virtua

Re: [Development] Assistant WebKit/WebEngine support

Am 24.06.19 um 12:31 schrieb Eike Ziller: >> * What exactly is so big about WebEngine? What is this size that many are >> hinting at but won't provide the number? > My numbers on macOS: > > WebEngineCore.framework = 145 MB > Current Qt Creator application = 430 MB (and about 60 MB of this we curr

Re: [Development] Assistant WebKit/WebEngine support

Am 21.06.19 um 15:42 schrieb Volker Hilsheimer: >> To me it seems easier to solve this first by making the Qt Assistant use >> WebEngine and when we later have a better doc "frontend" (as web app) >> switch to that and potentially an external browser. > > > Personally I think the “external browser

Re: [Development] Assistant WebKit/WebEngine support

Am 21.06.19 um 14:57 schrieb Volker Hilsheimer: >> On 21 Jun 2019, at 11:08, Bastiaan Veelo > > wrote: >> >> >> On 21/05/2019 12:24, Kai Köhne wrote: -Original Message- From: Development >>> > On Behalf Of

Re: [Development] Coin mailing issue

Yeah something bad happened and it started yesterday late afternoon. I don’t know what’s causing it but since nobody reacted so far I have shut down coin. I hope that will help with the mass emailing. I’m unfortunately not in a position to investigate this issue right now (or this weekend). Sim

Re: [Development] Proposing CMake as build tool for Qt 6

Am 12.06.19 um 12:45 schrieb Christian Gagneraud: > On Fri, 7 Jun 2019 at 03:31, Alexandru Croitor > wrote: >> On 6. Jun 2019, at 16:48, Christian Gagneraud wrote: >> On Fri, 7 Jun 2019 at 02:25, Simon Hausmann wrote: >> Am 06.06.19 um 16:17 schrieb Christian Gagnerau

Re: [Development] Proposing CMake as build tool for Qt 6

, 2019 19:19 To: development@qt-project.org Subject: Re: [Development] Proposing CMake as build tool for Qt 6 Awesome news! Any ideas/plans for WebAssembly? On 06.06.19 13:45, Simon Hausmann wrote: > Hi, > > In the past months we, some developers from the Qt Company and KDAB, > have made good

Re: [Development] Proposing CMake as build tool for Qt 6

. Simon > On 6. Jun 2019, at 17:54, Thiago Macieira wrote: > >> On Thursday, 6 June 2019 04:45:14 PDT Simon Hausmann wrote: >>* Builds on >> * Windows (desktop) >> * macOS >> * Linux (desktop and embedded) >> * Android (running

Re: [Development] Proposing CMake as build tool for Qt 6

Am 06.06.19 um 16:17 schrieb Christian Gagneraud: > On Fri, 7 Jun 2019 at 02:08, Simon Hausmann wrote: >> >> Am 06.06.19 um 15:52 schrieb Christian Gagneraud: >>> On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development >>> wrote: >>>> Hi, >>&

Re: [Development] Proposing CMake as build tool for Qt 6

Am 06.06.19 um 16:01 schrieb Tor Arne Vestbø: > >> 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

Re: [Development] Proposing CMake as build tool for Qt 6

Am 06.06.19 um 15:52 schrieb Christian Gagneraud: > On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development > wrote: >> Hi, >> >> I won't hold my breath for community support for iOS. iOS is out for so many >> years, yet CMake has no support for t. >> >> iOs is not a show stopper if and only yo

Re: [Development] Proposing CMake as build tool for Qt 6

ake looks like? qmake's documentation has always been an afterthought. The documentation equivalent for CMake should be better than that – at the very least, it shouldn’t result in another https://wiki.qt.io/Undocumented_QMake and such. -- Kavindra. From: Development on behalf of S

Re: [Development] Proposing CMake as build tool for Qt 6

is needed. Simon From: Иван Комиссаров Sent: Thursday, June 6, 2019 15:33 To: Simon Hausmann Cc: Bogdan Vatra; development@qt-project.org Subject: Re: [Development] Proposing CMake as build tool for Qt 6 Sorry, but the iOS should be properly supported before making

Re: [Development] Proposing CMake as build tool for Qt 6

use Apple's automated code signing. This might be done at application time using the xcode generator. Simon From: Bogdan Vatra Sent: Thursday, June 6, 2019 15:33 To: Simon Hausmann Cc: development@qt-project.org Subject: Re: [Development] Proposing CMake as

Re: [Development] Proposing CMake as build tool for Qt 6

others in the C++ community are able to build apps for iOS with CMake, then we will also be able to build Qt for it. Simon From: Bogdan Vatra Sent: Thursday, June 6, 2019 15:13 To: development@qt-project.org Cc: Simon Hausmann Subject: Re: [Development] Proposing CMak

[Development] Proposing CMake as build tool for Qt 6

Hi, In the past months we, some developers from the Qt Company and KDAB, have made good progress on the port of Qt to use CMake as build tool. Since the initial prototype, the port has advanced very well and its current state can be summarized roughly like this: * Builds on * Windows (d

Re: [Development] Views

Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development: > On 2019-06-06 09:47, Simon Hausmann wrote: > [...] >> However I don't find your arguments that find_if/lower_bound is not >> harder to read convincing. I continue to agree with Joerg and Tor Arne >>

Re: [Development] Configure command lines of official Qt releases

Hi, On Linux/macOS the current directory is not automatically/always an path where the dynamic linker searches implicitly for dependencies. That's only Windows :) Simon From: Development on behalf of Richard Weickelt Sent: Thursday, June 6, 2019 10:10 To: Ива

Re: [Development] Views

Am 06.06.19 um 09:05 schrieb Mutz, Marc via Development: > On 2019-06-06 08:24, Joerg Bornemann wrote: >> On 6/5/19 5:49 PM, Mutz, Marc via Development wrote: >> >>> As a library implementer, you are simply not _allowed_ the freedom to >>> use a convenient tool over the most efficient one. That is

Re: [Development] Configure command lines of official Qt releases

ths, plus the relative path specified (but as that's a dot it's a noop). Simon From: Richard Weickelt Sent: Wednesday, June 5, 2019 14:46 To: Simon Hausmann; Markus Haberlander Cc: development@qt-project.org Subject: Re: [Development] Configure command

Re: [Development] Configure command lines of official Qt releases

Excellent yes. That was a recent addition to the installer framework, very useful for exactly that purpose. Simon From: Markus Haberlander Sent: Tuesday, June 4, 2019 12:47 To: Simon Hausmann Cc: Richard Weickelt; development@qt-project.org Subject: Re

Re: [Development] Configure command lines of official Qt releases

Hi, It's a little tricky, but you can reverse engineer it :) The releases are spun from qt5.git. So if you take the 5.12.3 release, for example then using git tag -l you can see a v5.12.3 tag in the qt5.git repository. A quick git show on that tag leads you to commit 8337e20fadddf7f9c3407

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

obody has stepped up to attempt to replace the mo https://github.com/woboq/verdigris not quite true On Thu, May 30, 2019 at 9:59 PM Simon Hausmann mailto:simon.hausm...@qt.io>> wrote: So far nobody has stepped up to attempt to replace the moc, so I doubt that it will be replaced in Qt 6.

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

So far nobody has stepped up to attempt to replace the moc, so I doubt that it will be replaced in Qt 6. Simon > On 30. May 2019, at 20:46, Konstantin Tokarev wrote: > > > > 30.05.2019, 21:18, "Thiago Macieira" : >> On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development >>

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

Hi, If the Qt project decides to go with cmake, then I think that while bootstrap will remain for the moc and rcc, I think that we may be able to remove qregexp (Or QRegularExpression) from it. I doubt that either of them need it. The cmake port fwiw is progressing very well and I hope that we

Re: [Development] QList for Qt 6

Hi, I’m very much in favor of having QList be an alias for QVector and try it out, in qt5, with creator and KDE. Simon On 27. May 2019, at 10:12, Lars Knoll wrote: >> On 25 May 2019, at 00:37, Giuseppe D'Angelo via Development >> wrote: >> >> Il 24/05/19 18:16, Uwe Rathmann ha scritto: >>

Re: [Development] What's the status of a moved-from object?

e anything to our users - it's a poor interface because it either isn't reliable (-release build not enabling it) or hard to understand (debugger usage). Simon From: Giuseppe D'Angelo Sent: Friday, May 24, 2019 14:28 To: Simon Hausmann; d

Re: [Development] What's the status of a moved-from object?

Hi, I favor a well-formed (null) state over a partially-formed state. I agree with the suggestion of adding null pointer checks into member functions where applicable. I think a well-formed state is more likely to enable our users to have a productive time. Operating - by accident - on a parti

Re: [Development] Gerrit is back

Hi, After a few days of usage and getting used to the new UI, I'd like to say that I'm very impressed! This upgrade went smoothly and the new functionality is a real productivity booster. I love the fact that there's now a usable mobile interface. And that I can edit commits to make small chan

  1   2   3   4   5   6   >