Re: [Development] Proposal: New branch model

23.01.2019, 21:38, "Alex Blasche" : >>> At the end of the day each cherry-pick is a merge too Merges and cherry-picks have a certain amount in common, but they are not the same thing at all. >>> and they can conflict too. The conflict resolution process is still >>> the same. if everything is

Re: [Development] Proposal: New branch model

On Wednesday, 23 January 2019 11:01:53 PST Volker Hilsheimer wrote: >> I think that’s fine. What’s much worse is having a fix in 5.12 and not >> knowing how to deal with the merge conflicts into dev. That means dev might >> regress, unless whoever authored the change is willing to spend time on >>

Re: [Development] Proposal: New branch model

Jedrzej Nowacki wrote: >> Advantages: >> - no waiting for merges, a fix can be used right away after >>integration >> - faster propagation of fixes targeting all branches, as there are >>no merges of merges Alex Blasche (23 January 2019 18:09) > This is pure speculation because you

Re: [Development] Qt6: Adding UTF-8 storage support to QString

Marco Bubke (23 January 2019 15:07) wrote > Would it be not better to use a simple container and then functions on > top which use a view, so we could use them with any container. That sounds just fine to me. Indeed, in separating the "Unicode text" nature from its encoding, I'm fine with the

Re: [Development] Qt6: Adding UTF-8 storage support to QString

All of this discussion ignores a major elephant: QString's indexing is by 16-bit UTF-16 tokens, not by Unicode characters. We've had Unicode for a couple of decades now. We *should* have a string type (I don't care what you call it) that acts on strings indexed by Unicode characters, not in

Re: [Development] Qt 5.13 feature freeze is getting closer

Paul Tvete (17 January 2019 15:33) > I'm taking the opportunity to yet again point out that the term "API review" > has a long history inside and outside of the Qt Project, and we need another > name for the just-before-release check. This misunderstanding shows that the > risk of miscommunication

Re: [Development] Qt 5.13 feature freeze is getting closer

Tuukka Turunen (17 January 2019 15:00) > I think best would be to do the API review in codereview tool as > mailing lists are of limited efficiency in this purpose. Based on the > API review we can then decide if the module is ready to be part of Qt > 5.13 as TP or not. For the existing modules we

Re: [Development] Qt 5.13 feature freeze is getting closer

Maurice Kalinowski (17 January 2019 09:18) > Well even for TP there should be some consensus on whether it should > be part of Qt or not, no? Sounds sensible. > We are lacking documentation on the process here, Indeed. > all I could find was >

Re: [Development] Qt6: Adding UTF-8 storage support to QString

Marco Bubke (16 January 2019 10:59) reported: >> https://utf8everywhere.org/ states "UTF-16 is the worst of both >> worlds, being both variable length and too wide" Konstantin Ritt (16 January 2019 17:50) replied > https://utf8everywhere.org/ states bullshit. try reading an alternative >

Re: [Development] Qt6: Adding UTF-8 storage support to QString

Marco Bubke (16 January 2019 10:59) > You can use std::string which as small string optimization instead of > QByteArray too. In many cases where you would use const String > you can use std::string_view, so you are more flexible. Note that we now have a QStringView, which can likewise replace

Re: [Development] [Releasing] HEADS-UP: Branching from '5.12' to '5.12.1' started

Am 14.01.19 um 15:03 schrieb Fabrice Mousset | GEOCEPT GmbH: > I can't see issues with given link > (https://bugreports.qt.io/issues/?filter=20430) I always got this > error: " A value with ID '11040' does not exist for the field > 'project'." hmm ... probably because the search query has a term

Re: [Development] Qt 5.12 and debug/warnings messages

Kai Koehne (11 January 2019 10:33) wrote > There's been no such change. Your problem is most likely one of two: > > - You actually disable the qDebug, qWarning via custom logging > rules. See http://doc.qt.io/qt-5/qloggingcategory.html , section > "Logging Rules" for the details. Note that

Re: [Development] Corrupted ML archive

André Hartmann (8 January 2019 14:09) wrote: > The Qt Creator archive seems broken too. > > https://lists.qt-project.org/pipermail/qt-creator/2019-January/thread.html > only contains two mails, but I'm pretty sure there has been more. Same as developer. I've poked the sysadmins again ...

Re: [Development] Corrupted ML archive

On 21/11/2018 13.10, Danila Malyutin wrote: >> It looks like [the archive] has lost all mails from 4th of November >> up until now. [...] >> I don't know if there any mirror/way for someone >> not subscribed to this ML to see these mails Our sysadmins tell me the archive is now repaired. A

Re: [Development] Build system for Qt 6

On Mon, 17 Dec 2018 at 21:43, Jean-Michaël Celerier wrote: >> But in this day and age where docker works everywhere I don't really >> see the point in fighting to make windows behave like a proper unix >> system, just write a dockerscript that does your cross-compile job. Christian Gagneraud (17

Re: [Development] Qml draw pattern as password

Akin Gümüskavak (Friday, 14 December 2018 9:47 AM) wrote >> I'm trying to develop a drawing pattern area as password field in >> Qml. I've made some research but could not find anything useful. Mitch Curtis (14 December 2018 09:59) replied: > What do you mean by "drawing pattern area as password

Re: [Development] QDateTime addDays logic

>>> Not saying it's correct, just stating the fact that function name is >>> confusing and potentially problematic because it doesn't do what it >>> states it does. Il 13/12/18 15:55, Edward Welbourne ha scritto: >> Aye, there's plenty that isn't perfect, especial

Re: [Development] QDateTime addDays logic

NIkolai Marchenko (13 December 2018 15:24) > It's not like I don't understand all that. But I am not that person who > introduced the regression and > > a) He doesn't use a compiler that supports this warning > b) ... and he wouldn't have read it in the first place. (unfortunately) > c) He

Re: [Development] QDateTime addDays logic

Fausto Papandrea (13 December 2018 12:48) > Hi, I would like to understand the logic of the addDays function of > QDateTime. > > I mean, why doesn't it modify the calling object, but returns a copy of > a new object instead? At this point, it does what it does because it's done so for years

Re: [Development] Nominating Paul Wicking for Approvership

Simon Hausmann (12 December 2018 11:58) proposed: > I would like to nominate Paul for approvership. +1 - sensible fellow, clearly knows what he's doing. Full disclosure: there's only a thin wall between his office and mine. Eddy. ___

Re: [Development] Resolving coding style contentions

On Sunday, 18 November 2018 05:30:26 PST Sze Howe Koh wrote: >> I'd just like to know: Did the Qt Project ever reach a decision? If not, >> how can we reach one? (Linked to the discussion of constructor initializers like MyClass(type param) : MyBase(param) , myMember(param) using

Re: [Development] Hardcoded strings and qstricmp comparison

Andy Shaw (14 November 2018 09:34) wrote: > ... there may be some problems that are connected to using qstricmp > and other functions that are expecting latin1 strings for one reason > or another. The reason that this might be a problem is because we are > encoding our source code as UTF-8 and

Re: [Development] [HEADS UP] 5.12 locked down (Re: Merge and Integration status report - 2018.11.08)

ebugger tests. On 11/13/18 11:30 AM, Edward Welbourne wrote: >> I encourage you to rewrite those tests. >> Anything that makes Coin slower is Bad. Ulf Hermann (13 November 2018 12:02) > How? The problem was that the OS took minutes to start a process. I see. Painful. > However,

Re: [Development] [HEADS UP] 5.12 locked down (Re: Merge and Integration status report - 2018.11.08)

On Dienstag, 13. November 2018 09:30:11 CET Ulf Hermann wrote: >> Just wait forever on the check in a loop. After 15 minutes the >> watchdog kicks in and kills the test. If that happens, you know that >> it's a real failure. This works fine for the QML debugger tests. I encourage you to rewrite

Re: [Development] [HEADS UP] 5.12 locked down (Re: Merge and Integration status report - 2018.11.08)

Oliver Wolff (13 November 2018 09:05) > I had a look at the problem when I blacklisted it for WinRT and one > problem was, that QTRY_IMPL used a hard coded step interval of 50 ms, > which of course does not make sense if you try to have a timeout of 25 > ms. Thank you for bringing that to my

Re: [Development] Build system for Qt 6

On 10/30/18 12:16 PM, Bogdan Vatra via Development wrote: >>> d) While c.1 and c.2 can be fixed with some effort, here we have bigger >>> problems: >>> >>>- Instread to port QBS to QML JS in the first second when QtScript was >>> deprecated, they fork it! I know that back then QML JS

Re: [Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

On Thu, Nov 01, 2018 at 08:42:52PM -0700, Thiago Macieira wrote: What do we do? Option 1: do nothing, wait for Qt 6 and do the change then Option 2: insert #if in our API, starting now Option 3: use #if per class, starting now Option 4: create a central #if and use

Re: [Development] Build system for Qt 6

On Tue, Oct 30, 2018 at 8:32 PM Pier Luigi Fiorini wrote: >> From my point of view qbs is doomed as long as qmake's alive. NIkolai Marchenko (30 October 2018 18:38) replied: > I would much rather this abomination died instead. You are not alone. Unfortunately, the project has depended on it for

Re: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString

Edward Welbourne (Monday, 29 October 2018 7:31 PM) wrote >> I'm not sure where JSON got involved in that Mitch Curtis (30 October 2018 08:37) replied > What do you mean? It's in the title of the email; it's a popular > choice for storing data like this, so I want SplitView's s

Re: [Development] QUIP 12: Code of Conduct

On Mon, Oct 29, 2018 at 02:25:20PM +, Ulf Hermann wrote: >> All the proposals for codes of conduct that I have seen so far mention >> banning only as a last resort and have several less drastic measures >> that should be applied before. André Pönitz (29 October 2018 21:18) came back with >

Re: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString

Mitch Curtis (29 October 2018 17:42) > To solve #2, I first tried simply saving a QVariant containing a > QByteArray (the contents of which were QDataStream's output). This > didn't work because Qt's JSON implementation doesn't support > QByteArray; it only supports QString. That is, calling >

Re: [Development] QUIP 12: Code of Conduct

In a context of witch-hunts against even allegations of minimal harm, NIkolai Marchenko (26 October 2018 20:17) wrote >> And we already see the budding sentiments to that exact tune: >> (quote from Edward Welbourne) >>> That sometimes folk have felt so intimidated that they

Re: [Development] QUIP 12: Code of Conduct

Jason H (25 October 2018 16:43) contributed: Mitch, you wrote: >> To me it seems like you guys are saying: >>> "I don't care if this person treats me like crap because they sure >>> can code." >> I'm happy for you if you've gotten this far in life and decided that >> you like being insulted in

Re: [Development] QUIP 12: Code of Conduct

Rafael Roquetto (25 October 2018 11:50) > I understand this has already been set in stone, I do not think you should take that for granted. We do have a process by which all contributors can contribute to the decision and should be listened to, so that the resulting decision can be shaped by any

Re: [Development] QUIP 12: Code of Conduct

Jason H (24 October 2018 17:09) > - Is "Sceintific racism" actual racism or just statistics? If it's racism, it's racism, however qualified. Extrapolation from populations to individuals misuses statistics. It isn't scientific, it just abuses tools lifted out of science. > I really want to know

Re: [Development] Un-inlining members allowed?

On Sonntag, 21. Oktober 2018 20:07:38 CEST Christian Ehrlicher wrote: >>> one more question - is it ok to un-inline a function? For example I >>> want to move QListWidgetItem::isSelected() to the cpp file so I can >>> properly mark QListWidget::isItemSelected() as deprecated but I'm >>> unsure if

Re: [Development] Gerrit "no matching cipher found"

El mié., 10 de oct. de 2018 16:43, Thiago Macieira mailto:thiago.macie...@intel.com>> escribió: > Our Gerrit server uses an old version of JGit, which uses old > ciphers. You need to turn something back on. See Konstantin's reply > for a suggestion on which one. Lisandro Damián Nicanor Pérez

Re: [Development] Using #pragma once

On Sunday, 7 October 2018 01:56:47 PDT Lars Knoll wrote: >> Just a quick question: Does anybody have any good arguments against >> us starting to use #pragma once instead of header guards throughout >> our code base? Thiago Macieira (7 October 2018 20:39) wrote: > For example, I have ~/src as a

Re: [Development] unified data model API in QtCore => thin wrapper proposal

> On Friday, 5 October 2018 08:35:10 PDT Thiago Macieira wrote: >>> Cons: >>> Suppresses move construction as in >>>QCborValue v = array[n]; >>> this still compiles, but passes through the copy constructor, not >>> the move one. We cana add an extra move constructor for const >>> QCborValue &&

Re: [Development] Dropping remaining support of qtquick1

NIkolai Marchenko (5 October 2018 18:30) wrote: > I would like to remind people that there has already been a deprecation > thread " > [Development] Deprecation of Qt Quick Controls 1" by > Frederik Gladhorn this Februrary. > A couple issues were raised there that were rather relevant and I would

Re: [Development] unified data model API in QtCore => thin wrapper proposal

Thiago Macieira (5 October 2018 17:35) asked me: > Eddy: what happens in the new API if you write: > const QCborArray array = { QCborArray{ 1 } }; > QCborValue v = array[0]; > v[0] = 2; > > Does that modify array? No. It should only modify what v[0] reports, or a v.toArray()[0] reports,

Re: [Development] unified data model API in QtCore => thin wrapper proposal

On Sunday, 9 September 2018 04:16:24 PDT Tor Arne Vestbø wrote: >> This is exactly the kind of stuff I brought up at the contributors >> summit. We should strive to at least be on par with QJson, but I’m >> hoping we can also have a nice API for writing (something QJson >> doesn’t easily

Re: [Development] Orphan modules

Tor Arne Vestbø (12 September 2018 10:25) >> I think the qtmacextras module should be maintained by the same >> [maintainer] as macOS, Morten. On 12 Sep 2018, at 11:02, Edward Welbourne wrote: > That would depend on - Morten: are you willing to take it on ? > Morten Sørvig (12

Re: [Development] Orphan modules

Tor Arne Vestbø (12 September 2018 10:25) > I think the qtmacextras module should be maintained by the same > [maintainer] as macOS, Morten. That would depend on - Morten: are you willing to take it on ? As long as Tor Arne and Morten are watching the module, Samuel could gain some experience as

Re: [Development] Submitting Qt to oss-fuzz

Peter Hartmann (4 September 2018 11:17) > sounds like a good initiative, I was asking about the same thing 2 > years ago ([1]) but then somehow didn't follow up on this. > > Back then I also wrote some simple fuzzing test cases ([2]) that found > some crashes and memory corruptions ([3]), I would

Re: [Development] Naming convention for (scoped) enums

Simon Hausmann (31 August 2018 11:01) > If we decide to allow deciding on a case-by-case basis, then I encourage > everyone to carefully look at newly introduced enums, their values and > their context in the upcoming "API review season". or, indeed, s/upcoming/ongoing/ ;-) Eddy.

Re: [Development] Submitting Qt to oss-fuzz

El divendres, 31 d’agost de 2018, a les 10:27:08 CEST, Edward Welbourne va escriure: >> By "fixed" do they mean "we have told them we've fixed it" or "we've >> released all currently releasing branches of Qt with fixes" ? Albert Astals Cid (31 August 20

Re: [Development] Submitting Qt to oss-fuzz

Albert Astals Cid (30 August 2018 20:42) wrote: > oss-fuzz is an online fuzzing service run by Google. Sounds useful. > They test daily the code base and run fuzzying over it, maintaining a > list of open and closed bugs. > > Found bugs are sent to a list of trusted address and kept private for

[Development] Orphan modules

I notice, as part of seeking folk to look at API reviews, that we have several modules with no Maintainer: qtandroidextras, qtgraphicaleffects, qtmacextras, qtquick1, qtquickcontrols, qtsvg, qtwinextras and (the one that brought this to my attention) qtxmlpatterns, according to [0]. * [0]

Re: [Development] HEADS-UP: Branching from 'dev' to '5.12' completed

Jani Heikkinen (21/08/2018, 11.04) wrote: > Branching from 'dev' to '5.12' is now complete and Qt 5.12 Feature Freeze is > in effect. So now it is time for the API review. Find your favourite module on: https://codereview.qt-project.org/#/q/status:open+branch:5.12+topic:api-review,n,z Track the

Re: [Development] About 3D desktop.

Stef Bon (21 August 2018 05:36) > Also important here is what is called in Dutch a "verdwijnpunt". I do > not know the translation, but the horizon is something like that, > where all parallel lines meet..) Searching for it on nl.wikipedia.org I get a page [0] whose pictures tell me it's what we

Re: [Development] Calendar classes: API review request

On Dienstag, 31. Juli 2018 14:25:21 CEST Edward Welbourne wrote: >>> My primary concern with this API is that it promotes an unclear >>> ownership model. >> hmm ... this is partly a symptom of most QAbstractCalendar instances >> being dataless. Each calendar h

Re: [Development] Naming convention for (scoped) enums

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 read this >>> instead is worse in my opinion: On 13 Aug 2018, at 18:12, Giuseppe D'Angelo via Development

Re: [Development] Apparently dead code: GPU_BLACKLIST and friends

I wrote: > I notice that QTest includes support, in [0], alongside its BLACKLIST > files for problematic tests, for a GPU_BLACKLIST file; [...] > > Inevitably, I'm contemplating a featurectomy. The reviews can be found here:

Re: [Development] Apparently dead code: GPU_BLACKLIST and friends

>>> I'm not the only one : >>> https://github.com/search?p=1=QTEST_ADD_GPU_BLACKLIST_SUPPORT_DEFS=Code On 08/08/2018 01:41 PM, Edward Welbourne wrote: >> This URL got me: >> >> We could not perform this search >>Must include at l

Re: [Development] Apparently dead code: GPU_BLACKLIST and friends

I wrote: >> Inevitably, I'm contemplating a featurectomy. Jean-Michaël Celerier (8 August 2018 13:33) replied > I remember using it to be able to run integration tests on a virtual X11 > server in Travis CI. How long ago ? Are you *still* using it for this ? Do you anticipate using it with

[Development] Apparently dead code: GPU_BLACKLIST and friends

Hi all, I notice that QTest includes support, in [0], alongside its BLACKLIST files for problematic tests, for a GPU_BLACKLIST file; there are, however, no GPU_BLACKLIST files anywhere in our source tree (in any currently live branch, from 5.6 to dev). There's a whole complex

Re: [Development] Repository request: HTTP server

On 10/06/2017 07:10 AM, Fredrik de Vibe wrote: >> We have recently been working on a research project looking into the >> possibilities for creating a lightweight server component that can easily >> enable Qt applications to serve over HTTP. We would like to make this work >> public and

Re: [Development] Qt 6 buildsystem support requirements

Singling out just one tiny corner of all that for a passing remark: Jason Newton (1 August 2018 10:24) > One of the things I like about the way bazel keeps this is I can jump > back and forth between an optimized build and a full debug build (for > example) - they don't erase eachother This is

Re: [Development] Merge and Integration status report - 2018.07.04

While Liang has been away (he'll be back later this week): Merges (various module owners; and I helped out a bit): * qt5's last upmerge was 5.11->dev on July 12 * qtbase 5.11->dev, https://codereview.qt-project.org/233803 took 20 tries, but we got there in the end (July 17); we've not had

Re: [Development] Symbol clashes with static Qt libraries

Kai Koehne (Tuesday, 31 July 2018 1:44 PM) >>> b) Advise people to always configure static Qt in a namespace (- >>> qtnamespace). >>> >>> This should fix it for symbols at least in our own code. Maybe we should >>> make it even the default for static builds in Qt 6? On 31/07/18 14:06, Mitch

Re: [Development] Calendar classes: API review request

Simon Hausmann (31 July 2018 12:38) > I've said this also in the reviews, but perhaps it got lost: 'fraid so. It's been a long review ... and gerrit's not good at helping us find which comments haven't been addressed. > My primary concern with this API is that it promotes an unclear > ownership

[Development] Calendar classes: API review request

Feature freeze is drawing near, as Jani just reminded us, and Soroush's work on calendar support is in a state that looks (to me) ready to use. Please would those with strong views on API design take a look at [0] and speak up now, so that we don't end up reworking it all during the API review

Re: [Development] Proposing Samuel Gaist for approver status

On Saturday, 28 July 2018 01:56:37 PDT André wrote: >> I'd like to propose Samuel as approver. He has been active in the Qt project >> for ages. >> >> He not only provides code changes [0], he is also active reviewing others >> changes [1]. >> >> But that's not all: Samuel is *extremly* active in

Re: [Development] Why are my merged patches not in dev after checkout?

Am Donnerstag, 19. Juli 2018 schrieb Daniel Savi: >> Now, I did a "git checkout dev" and "git rebase origin/dev" on my >> local machine that didn't have the dev branch on it before. The >> rebase command told me, that my local branch was up to date. "git >> branch" shows that I'm on "dev" Andre

[Development] Heads-up: glibc 2.28 will break matching of [a-z], [0-9] and other ranges

Hi all, A discussion on the GNU make mailing list brought this to my attention. Apparently glibc 2.28 is going to implement the POSIX spec on ranges, which says A range expression represents the set of collating elements that fall between two elements in the current collation sequence,

Re: [Development] Coding style: space after comma

On Tuesday, 3 July 2018 07:37:25 PDT Edward Welbourne wrote: >> Derived:Derived(Type arg, Mode um, Form ent) >> >> : Base(arg) >> >> , mem(um) >> , ber(ent) >> {} Thiago Macieira (16 July 2018 17:48) > There are spaces before these commas

Re: [Development] Coding style: space after comma

I (3 July 2018 16:37) wrote: > [0] https://wiki.qt.io/Qt_Coding_Style > > I propose to follow (under "Whitespace") the list item > > * Surround binary operators with spaces > > with > > * Leave a space after each comma > > Any objections, or improved wordings ? Hearing no objections or

Re: [Development] which branch to use for a fix in 5.9 ?

Martin Koller (11 July 2018 10:50) wrote (inter alia): > So I assume I should use 5.9 and not 5.9.6, right ? Yes, except that that's an LTS branch, so it only gets cherry-picks back from other branches (unless you have a strong reason otherwise). Which means you actually need to send it to 5.11

Re: [Development] Dark mode, palettes, styles etc.

Shawn Rutledge (6 July 2018 10:50) wrote > [...] I had the idea a few years ago anyway that there should be an > easy global switch (always within reach, not having to paw through > system settings) to toggle quickly between light and dark themes. [...] > But now that Apple is finally doing

[Development] Coding style: space after comma

I notice that our coding style [0] doesn't actually say out loud that we expect a space after each comma (and none before). Its sole mention of comma is that it goes at a line-end, unlike operators at line-start, on a continued line. Yet the Qt code-base is mostly consistent about this and I've

Re: [Development] Urgent: increase timeout for tst_qcomplextext

On 30 Jun 2018, at 18:14, Thiago Macieira wrote: >> I tried to add a change to increase the timeout >> https://codereview.qt-project.org/233691 >> but Liang pointed out that my inspiration is a change by Rohan McGovern back >> in 2012: >> >> dd3e4f1dbe8

Re: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite

Marco Bubke (7 June 2018 19:37) wrote: > AFAIK the refactoring plugin is disabled for release. Just do the same for > the Sqlite library. Probably better to do as Thiago said: On June 7, 2018 23:54:43 Thiago Macieira wrote: >> So we just need a conditional to disable the building if the

Re: [Development] State of LGPL exception after migration to LGPLv3

Em segunda-feira, 17 de abril de 2017, às 04:24:25 PDT, Konstantin Tokarev escreveu: >>> 1. Is it still legal to incorporate "inline functions and templates" >>> into code not covered by LGPLv3? In particular, I'm interested in >>> qAsConst On 17 Apr 2017, at 18:07, Thiago Macieira wrote: >>

[Development] Recent QUIP activity

Hi all, As ever, you can see current QUIP-related reviews at https://codereview.qt-project.org/#/q/status:open+project:meta/quips,n,z and find the (just now updated) current state of all QUIPs (with most of those changes) at: https://quips-qt-io.herokuapp.com Most recently active first: * QUIP

Re: [Development] Fornux C++ Superset

Phil Bouchard (27 April 2018 15:36) > - It’s always better to patent important algorithms Those of us who believe in the freedom of ideas disagree. It is better to publish important algorithms, so that no-one else can patent them. > - But outside North-America and Europe, companies do not care

Re: [Development] Fornux C++ Superset

Phil Bouchard <philipp...@gmail.com> wrote: >>> - Fornux C++ Superset On 04/27/2018 04:18 AM, Edward Welbourne wrote: >> Nothing as yet persuades me that we need this one. Of course, once your >> compiler can handle Qt's C++ code, you'll be at liberty to combi

Re: [Development] Fornux C++ Superset

Phil Bouchard wrote: >> And I put Qt on top of the list because you already have all the >> necessary layers to jump start to the next level. Phil Bouchard (27 April 2018 00:06) > What I meant by that is Qt could create the ultimate “holodeck” with a > mixture of: > -

Re: [Development] Fornux C++ Superset

Phil Bouchard (24 April 2018 19:05) >>> I’m not sure if you read the link I posted about static analysis but a >>> software bug can cause billion dollar projects like space shuttles to fail. >>> Maybe MS Word was a bad example but they can be very costly. On 04/25/2018

[Development] Nominating Mårten Nordheim as an approver

Hi all, I'd like to nominate Mårten Nordheim for Approver. We've had him here at TQtC, in the Core & Network team, for a bit over a year; he's been reviewing steadily and finding mistakes I miss. As well as diverse work in qtbase, he's also dabbled in the qtnetworkauth and qtwebsockets modules.

Re: [Development] Fornux C++ Superset

Phil Bouchard (24 April 2018 19:05) > I’m not sure if you read the link I posted about static analysis but a > software bug can cause billion dollar projects like space shuttles to fail. > Maybe MS Word was a bad example but they can be very costly. The Columbia crash wasn't a (computer) software

Re: [Development] Fornux C++ Superset

On Monday, 23 April 2018 18:46:05 PDT Phil Bouchard wrote: >>> Remember when Wordperfect kept crashing in Windows 3.1 for some strange >>> reason back in the days? People ended up using MS Word. The same with >>> Netscape... On 04/23/2018 10:34 PM, Thiago Macieira wrote: >> There are a lot of

Re: [Development] Qt 5.11 Alpha released

Jani Heikkinen (20 February 2018 11:14) >> We have release Qt 5.11 Alpha today, see >> http://blog.qt.io/blog/2018/02/20/qt-5-11-alpha-released/ I wrote (21 February 2018 17:43) > and so, of course, we also have 5.11 API reviews, vs v5.10.1: and while eight of these are resolved,

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

ne' properly to get >> it clear for everyone. I already tried to start discussion about it in >> http://lists.qt-project.org/pipermail/development/2018-March/032338.html Edward Welbourne (17 April 2018 11:08) > As noted in [0], this looks like QUIP material. Kai proposed, in a &

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

Alex Blasche (maanantai 16. huhtikuuta 2018 16.47) >>... I do like to emphasize though that the dates for first beta and >>first RC are important (and FF is alpha) because they define times >>when certain level of changes are no longer permitted (e.g. after >>first beta no API changes). Therefore,

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

Tuukka Turunen (16 April 2018 08:59) > I very much like continuous flow of snapshots. I don't think anyone is challenging that part of the plan. The only objection to the plan has been to the change in naming. > Sometimes we have a tendency to fall into a "let's wait and get still > this one fix

Re: [Development] How to run QtBase autotests on a remote machine?

Alexander Richardson (11 April 2018 10:13) > I am currently trying to get Qt to work on the CHERI CPU > (http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-faq.html) Sounds interesting. > I have now managed to get the first few unit tests to build and run as > CHERI pure capability

Re: [Development] To improve UX of the online installer

Jason H (3 April 2018 02:43) wrote: > I'm not involved with the installer, but 2 points. > 1. Number of gets doesn't really matter as long as it's HTTP 1.1. yeah it's > not as optimal as a single compressed download, but it's not terrible. If > it's only 1.0, then that's a problem. Why do you

Re: [Development] Proposing Albert Astals Cid for Approver

Lars Knoll (21 March 2018 12:49) > He isn’t an approver yet? I agree, that we should change that :) My thought entirely ! +1, Eddy. ___ Development mailing list Development@qt-project.org

Re: [Development] Qt API review process (was: Re: Qt 5.11 Alpha released)

Kai Koehne (20 March 2018 09:34) > I would rather create a task in JIRA for the review itself, with priority 1 > and appropriate fixVersion. Any subsequent findings could be made subtasks of > this task. > > This automatically makes the API review part of the blockers list, and makes > sure >

Re: [Development] Qt API review process (was: Re: Qt 5.11 Alpha released)

Jani Heikkinen (14 March 2018 08:03) wrote: > We have API review ongoing for Qt 5.11. > For me our process for that is a bit unclear; That sounds like something we should aim to turn into a QUIP, once discussion here has produced something close enough to a consensus to be worth documenting.

Re: [Development] Qt for WebAssembly

Morten Sørvig (14 March 2018 10:54) > (The alternative would be to wait it out - perhaps threading support will be > enabled and stable in all browsers before we get to merge wip/webassembly). >From recent discussion with a Firefox developer, I gather that browser vendors are generally trying to

Re: [Development] PSA: qtdeclarative and qt5 broken

Simon Hausmann (12 March 2018 09:29) > I filed QTBUG-67010 to track the issue. Preliminary investigation suggests > that this only affects 5.11 and dev as a consequence of the TZ changes > introduced with QTBUG-56787. The test was flawed. https://github.com/tc39/test262/issues/1486 Closed (for

Re: [Development] introduction

gaurav jumrani (2 March 2018 11:08) > my name is gaurav jumrani. I am B.tech student from Rajasthan > Technical university, kota(raj.).I know c++ and qt very well and want > to contribute in bazel support task pls guide me how can i start and > want to be a part of gsoc2018 as a student from your

Re: [Development] Fwd: qrandom.cpp build problem: please advise

Thiago Macieira (27 February 2018 16:12) > Originally qrandom.cpp used getrandom(), which is in sys/random.h. Apparently > I forgot to remove the dependency when I switched to getentropy(). Alexei: please give https://codereview.qt-project.org/221913 a try, let me know if that (in place of the

Re: [Development] Nominating Ville Voutilainen as approver

Simon Hausmann (27 February 2018 10:36) > I would like to nominate Ville as approver. +1 (full disclosure: the three of us all work for TQtC) Eddy. ___ Development mailing list Development@qt-project.org

Re: [Development] Fwd: qrandom.cpp build problem: please advise

Alexei Fedotov (27 February 2018 09:45) > ./configure sets getentropy in qtbase/src/corelib/qtcore-config_p.h to 1, So the config.tests/unix/getentropy/ test passed. > but I have no sys/random.h which that test neglects to #include, so this lack doesn't keep it from failing. See if

Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator

André Pönitz (22 February 2018 20:05) > Any number for a "measured" value for rate of crashes or memory leaks > is uninteresting for me when I run into the problem myself reqularly. > And trust me, I do. I trust you. It is, however, possible your usage patterns of the UI are not typical;

Re: [Development] Qt 5.11 Alpha released

Jani Heikkinen (20 February 2018 11:14) > We have release Qt 5.11 Alpha today, see > http://blog.qt.io/blog/2018/02/20/qt-5-11-alpha-released/ and so, of course, we also have 5.11 API reviews, vs v5.10.1: https://codereview.qt-project.org/221039 qtbase https://codereview.qt-project.org/221040

Re: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11

On Friday, 9 February 2018 10:04:30 PST Giuseppe D'Angelo wrote: > The point isn't which version of Qt comes with the distribution, but the > binary builds. Given people do use binary builds (to have an up-to-date > Qt) but not mess with OpenSSL, the outcome will be that SSL will not be >

<    1   2   3   4   5   6   >