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 >

Re: [Development] Qt branches & proposal how to continue with those

Tuukka Turunen (1 February 2018 16:22) > I think keeping 5.9 open a bit longer has benefit due to it being an > LTS. The benefit looks small, to me. If I have to cherry-pick back to LTS, it's for an important issue; I've just done that for QTBUG-66076 because it got reported against 5.9.4, after

Re: [Development] Setters: Clarifying the ownership

Jaroslaw Kobus (19 January 2018 17:09) > "give" may be confused with "get", which is usually an accessor. I may > also think "Am I giving (to QCoreApplication)" or "The > QCoreApplication is giving (me)". Maybe it is just a matter of the > other verb? Absorb, hand over, hand on, suck in,

Re: [Development] [FYI] the new way to retarget gerrit changes

Benjamin TERRIER (10 January 2018 10:37) > What happens if the change already exists in the target branch? > > As a real example I have https://codereview.qt-project.org/#/c/197888/ > that should be retargeted to the dev branch. However, as I am quite > new to gerrit I have made the mistake to

Re: [Development] About the presence of /System/Library/Frameworks/Carbon.framework

René J.V. Bertin: >>> Here's a silly one: configuring Qt for building on my Linux rig I was told >>> that I needed Xcode, and how to get it. :) >>> >>> Long story short, it turns out that the configure script determines >>> whether it's building on Mac by checking if the Carbon framework exists

Re: [Development] Suggestion to add labels when changing API

On 07/12/2017 17:22, Liang Qi wrote: >> The changes that are important to be merged up before other changes >> should have a special tag, such as API_CHANGE in the commit >> message. Then the script used to do the merges could stop and/or warn >> about commits with this tag in the message, which

[Development] Why is year 7999 the end of time ?

Investigating bug QTBUG-64401, I discover qdatetimeparser_p.h defining #define QDATETIMEEDIT_DATE_MAX QDate(7999, 12, 31) which dates back to the original import of qtbase by Nokia (albeit John Layt moved it from qdatetime_p.h in 2013). If anyone knows any cause or just impediment against

Re: [Development] MAINTAINERS, your action needed: Qt 5.10 reviews (was: Qt 5.9.3 change files)

Jani Heikkinen (8 November 2017 11:29) poked all about 5.9.3's change files. I note that many 5.10 API reviews [0] also remain unresolved - indeed, six appear to be untouched by anyone but me: * qt3d, qtx11extras, qtandroidextras, qtscxml, qtnetworkauth, qtremoteobjects Four have had a +1

Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)

Sérgio Martins (13 October 2017 16:05) > Some users have been complaining about the review process and have > rotting patches, so I welcome brainstorming around this. Let's see if > we can conclude improvements! Indeed - and the remedy for that is, painfully enough, that we, as developers, need

Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)

Viktor Engelmann (13 October 2017 13:04) > On the [Interest] mailing list there was a discussion about the > review-process taking to long and we also had multiple discussions > about that at the world summit. I have complained about this myself, > so I would like to start a new thread and collect

Re: [Development] CSPRNG vs DPRNG

Thiago Macieira (11 October 2017 18:12) > I've come to the conclusion that adding QRandomGenerator, a (mostly) > cryptogrphically-secure PRNG, without adding a corresponding deterministic > PRNG is a bad idea, especially with the changes that went in to the examples > that changed all uses of

Re: [Development] Meeting minutes from Qt Release Team meeting 05.09.2017

Back on 13 September 2017 at 10:54 I announced: > Change reviews generated: > > https://codereview.qt-project.org/205317 -- qtbase > https://codereview.qt-project.org/205318 -- qtdeclarative > https://codereview.qt-project.org/205319 -- qtmultimedia > https://codereview.qt-project.org/205320 --

Re: [Development] Seeking advise using git and code review

Daniel Savi: >> When checking the branch with "git branch", I found that I was on a >> detached head now. André Hartmann (4 October 2017 09:25) > That sounds like you didn't work on a local branch, but rather on the > remote branch. When commiting there, you go into detached head. But > that's

Re: [Development] codereview website down?

André Hartmann (2 October 2017 12:06) > I just wanted to give a quick "thank you" to the one (Eddy?) that > convinced Sanity Bot! Everything is fine now. I'll make an educated guess that it was Ossi ;-) I only just caught up (after lunch) with your mail about the reviews the inanity bod had

Re: [Development] Meeting minutes from Qt Release Team meeting 05.09.2017

Thiago Macieira (19 September 2017 16:49) > The problem with Q_DECL_NOTHROW is that it once added, it cannot be > removed. There's also the choice: we choose to add it only to > functions that (in addition to neevr throwing) are wide contract. So > we should see it and review that kind of change.

Re: [Development] Coding style for lambdas, particularly their open-brace

On Fri, Aug 18, 2017 at 2:17 PM, Edward Welbourne <edward.welbou...@qt.io<mailto:edward.welbou...@qt.io>> wrote: >> We have a draft policy for lambdas at [0], in a section that begins with >> >> Note: This section is not an accepted convention yet. >&g

Re: [Development] Meeting minutes from Qt Release Team meeting 05.09.2017

On quarta-feira, 13 de setembro de 2017 01:54:12 PDT Edward Welbourne wrote: >> [...] Should Q_DECL_CONST_FUNCTION >> changes be ignored ? Q_NORETURN ? They currently aren't. Thiago Macieira (13 September 2017 15:51) > Those two are optimisations and could safely be ignored, b

Re: [Development] Meeting minutes from Qt Release Team meeting 05.09.2017

Jani Heikkinen (6 September 2017 06:53) > Meeting minutes from Qt Release Team meeting 5th September 2017 > > Qt 5.10 status: [...] > - API review to be started immediately when Alpha content in place No API changes found in: qtsvg, qtactiveqt, qtscript, qttools, qtxmlpatterns, qtsensors,

Re: [Development] QtWebKit is coming back (part 2)

07.09.2017, 10:45, "Martin Koller" : >> It also seems that it requires a too new ICU devel package (at least >> for CentOS 7.3), that is I need to deactivate INTL by using >> -DENABLE_INTL=OFF >> >> Can you tell us what I actually disable with that switch, e.g.: what >> does no

Re: [Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

>>> Interesting way such as LTTNG/ETW :) ? >> Spoiler alert: not on Mac ... Konstantin Tokarev (31 August 2017 15:50) > Mac has DTrace Do we have anyone eager to follow up on the LLTNG/ETW work (see earlier mail in this thread for link), adding DTrace for Mac ? Eddy.

Re: [Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

Thiago Macieira wrote: >> Source compatibility. Which is why it's unlikely we'll do it. René J. V. Bertin 31 August 2017 10:35 > Qt6 isn't going to break anything that builds against a sufficiently > recent Qt5 version? I doubt that; but the fact that we may break SC at Qt6 doesn't necessarily

Re: [Development] Qt and IoT infographic

Thiago Macieira (earlier): >>> Research shows NO ONE deploys Arduino for real products. It's a >>> maker toy, stuff hobbyists use to make one-off things and some >>> professional makers use for initial prototyping. When they get >>> serious, Arduino goes out the window and they get real boards.

Re: [Development] Qt and IoT infographic

Thiago: >> If you're going to communicate with a tiny MCU connected over a mesh >> network like 6LoWPAN/Thread, you won't be using TCP. Much less HTTP. and you'll want that MCU running something light-weight in C++, not a web-bloat thing. So Qt is just the thing for the job. (... and I had to

[Development] Coding style for lambdas, particularly their open-brace

Hi all, We have a draft policy for lambdas at [0], in a section that begins with Note: This section is not an accepted convention yet. This section serves as baseline for further discussions. That section is now a quarter decade old; it's had a few updates since it was added (2015-02-27),

Re: [Development] Calendar Systems proposal

Thiago Macieira (7 August 2017 06:14) > ... there are bigger problems with the implementation, starting with > QAbstractCalendar having a static protected QMap member. That's my fault. We're going to need some way for QML/V4 to get at calendars; and I want to ensure our design leaves scope for

Re: [Development] Erroneous Qt TouchBegin event to QGraphicsView ?

Patrick Stinson (3 August 2017 18:43) > I have filed bug reports before but am not sure where the line between > bug discovery and bug reporting is. For example in this case I am > partly asking if widget focus is supposed to work this way to avoid a > superfluous bug report. But it sounds like I

Re: [Development] ChangeLog entries and reverted commits

Joerg Bornemann (31 July 2017 09:07) > Suppose you create a new feature in commit A for Qt 5.x. The commit > message has a change log entry. After a while A has to be > reverted. You won't have time to fix the issue properly for 5.x. The > git history for 5.x still contains the change log entry -

Re: [Development] When will Qt Remote Objects become an official Qt module?

Thiago Macieira (18 July 2017 20:55) > $ grep qtremoteobjects .gitmodules ... and, to squeeze a little more information out of .gitmodules: $ grep -A 5 'submodule "qtremoteobjects"' .gitmodules [submodule "qtremoteobjects"] depends = qtbase path = qtremoteobjects url =

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

André Pönitz (13 July 2017 19:20) > There's no sensible reason to postpone "compilation" to run-time > on a million feeble devices if there's any sensible way to do it > ahead of time once on a beefy developer machine. On the other hand, doing run-time optimisation (which is one of the benefits a

Re: [Development] Nominating Jesus Fernandez for Approver status

Timur Pocheptsov (11 July 2017 14:06) > I'd like to nominate Jesus Fernandez for Approver status. +1 Full disclosure: Timur, Jesus and I are all in TQtC's Core & Network team. Eddy. ___ Development mailing list Development@qt-project.org

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

On quinta-feira, 6 de julho de 2017 04:53:16 PDT Phil Bouchard wrote: >>> It's all memory usage and bad programming habits vs execution speed. >>> Why would you want to add objects that are never used? A minimum >>> programming skills set is required here. You're saying the actual >>> garbage

Re: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail?

Morten Sørvig (20 June 2017 11:14): > I agree that getting to the root cause is preferable. We can do both: > blacklist immediately to get integrations going again while > investigating. https://codereview.qt-project.org/196699 has done that, in 5.9; we just need an upmerge to dev to get going

Re: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail?

Thiago Macieira (16 June 2017 22:23) > QDEBUG : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) > QHostAddress("fe80::250:56ff:feab:4818%eth1") > FAIL! : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) > '(neutralReadSpy.count() > 0)' returned FALSE. () > Loc: [../tst_qudpsocket.cpp(1600)] I

Re: [Development] Question on using multiple multicast receives on same channel in one program

On segunda-feira, 29 de maio de 2017 15:22:15 PDT wim delvaux wrote: > Therefore I tried to open multiple connections to that multicast > address/port but to no avail. What exactly did you try and in what sense did it fail ? Eddy. ___

Re: [Development] Introducing discussion about QStringFormatter

Jason H (15 May 2017 23:52): > Having worked with Python's format(), I much prefer the alterative {} > syntax, where {} defers to the next paramter. > '{}{}{}'.format('a', 'b', 'c) == 'abc' > Which makes maintence much easier, However, it can be problematic for translation; some languages shall

Re: [Development] QtWebKit is coming back (part 2)

Oswald Buddenhagen (4 May 2017 18:35) > i'll say outright that you can't be part of the qt supermodule and yet > have independent releases. while that was the plan once upon a time, the > whole release infrastructure simply doesn't deliver, and even just > diverging branch names are a pita (proved

Re: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit?

From: Development on behalf of Thiago Macieira Sent: 08 May 2017 08:47 To: development@qt-project.org Subject: Re: [Development] DBus signals for (dlclose'd) style

Re: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit?

Thiago Macieira wrote: >> In 5.8, the build deadlocks, so >> we can't even just disable a test. René J. V. Bertin (3 May 2017 13:28) replied: > How is that even possible? We don't know. And yet:

Re: [Development] Introductions?

Christian Kandeler (28 April 2017 16:19) > I see one +1 and one -2. ah - sorry - I though that one was off-list. Andre: do you feel your concern is addressed by my clarified proposal ? Eddy. ___ Development mailing list

Re: [Development] Introductions?

On 25 April 2017 at 10:09 I wrote (inter alia): > [...] the same is relevant for any approver or maintainer: perhaps we > should tweak our process for introducing candidates for those stations > within the community; ask that each introduce self in the course of it > - possibly *after* we've made

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

>> Something like the following seems nice: >> Tier 1 - the most rigorously tested configurations, tested in CI >> Tier 2 - we actively try to make it work but it's a lower priority; >> will make and accept patches and provide support but isn't tested in >> CI >> Unsupported - we remove code

Re: [Development] Introductions?

Steve Schilz asked me (24 April 2017 19:10) a pertinent question (heavily edited): > I’m not really sure what/where your role is… and I’m curious. > Perhaps an introduction on the mailing list (say, from Lars Knoll?) > for people further out in the Qt orbit is in order, or perhaps I > missed it?

Re: [Development] Exposing QMimeDatabase to QML; QtQml.Utils?

Robin Burchell (24 April 2017 16:01) > I'd generally like to avoid a "Utils" import, since in my opinion they > far too easily end up as a dumping ground +1, also for anything with "misc" in its name. Such names are a red flag about bad modularisation, Eddy.

Re: [Development] Qt 5.9 Header diff (API review)

Lars Knoll (21 April 2017 10:10) > Let us know once the updated diffs are available. No point doing the review > on the old diffs. Done :-) Eddy. ___ Development mailing list Development@qt-project.org

Re: [Development] Qt 5.9 Header diff (API review)

Lars Knoll (20 April 2017 12:19) > Some of the diffs don’t look like they are 100% up to date. Eddy? Indeed, I've just been updating them on request. I do plan on a bulk update today. Eddy. ___ Development mailing list

Re: [Development] Who's responsible for 3rdparty these days (QTBUG-59586)?

On 19 March 2017 at 20:01, Thiago Macieira > wrote: >> The rules are that only Qt Company people can import 3rdparty code, so I know >> I am not responsible. >> >> Who do I assign the bug to? >>

Re: [Development] Etymological digression from QList discussion

On вторник, 28 марта 2017 г. 01:18:18 EEST Rafael Roquetto wrote: >> It clearly has nothing to do anymore with the vector from my geometry >> classes. I don't know why it received the named 'vector' in first >> place, It's "carrier" in Latin; a vector carries several numbers. Geometry was a

Re: [Development] QList

On 27 Mar 2017, at 10:52, Martin Smith wrote: >> It was about whether QPolygon should inherit QVector, which means >> that a polygon is a vector. That is kind of jolting because people >> don't think of a polygon as being a vector. But back in the day, >> calling a sequential

Re: [Development] P0 Mac help needed due to Daylight savings

Thiago Macieira (26 mars 2017 8:12 PM) >> This test began failing today: >> FAIL! : tst_QLocale::macDefaultLocale() >> 'timeString.contains(expectedGMTSpecifier) || >> timeString.contains(expectedGMTSpecifierZeroExtended)' returned FALSE. >> (timeString `1:02:03 AM GMT+02:00',

Re: [Development] QList

Marc Mutz (23 March 2017 20:41) > Do I need to mention QPolygon and what pain it's inheritance from > QVector has caused? (FTR: cf. end of qvector.h and > qvector_msvc.cpp). well, I - for one - can only see a minor problem; so, since you *have* mentioned it, perhaps you could elaborate ? I

Re: [Development] Use of std::function in Qt API

Earlier, Thiago said: >>> The point however is that if libstdc++ does break its ABI, then >>> you'll have to rebuild half the world anyway. The few libraries and >>> applications that did use Qt and were not affected would be the >>> minority. Telling them apart could be a higher cost than just

Re: [Development] QList

On Wednesday 22 March 2017 07:37:27 Thiago Macieira wrote: >> Another thing I'd want is for QStringView to carry the pointer to the >> QArrayData like QString does. Marc Mutz (22 March 2017 09:27) > NAK to inheriting from QStringView, publicly or privately. NAK to > adding another pointer. Is

Re: [Development] syncqt.pl in C++

André Somers (8 March 2017 06:18) > The stopping maintainance of qmake can't happen any time soon I'd > think. Not even from Qt6. There are too many Qt projects out there > depending on it. All the same, the sooner we can make the transition away from using it ourselves, the sooner we can retire

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

> So let me play the devil's advocate: 5.9.1 also will be canceled for > similar arbitrary reasons like vacation plans. or the universe might end for no readily apparent reason. There is no reason to expect either will happen, though. > Guys, by not delivering bugfix releases for arbitrary

Re: [Development] Qt 5.9 API review

Jani Heikkinen (28 February 2017 11:09): > It seems Qt 5.9 API review is still badly ongoing, see [snip] FTR, we have some on-going fixes in progress in qtbase. > Please finalize the reviews & do needed fixes as soon as possible so that we > will be ready for beta early enough. If your module

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

Mat Sutcliffe (18 February 2017 15:36) >>> "We plan, and plan, and then plan again. What we don't do is stress >>> conformance to a plan." - Uncle Bob Martin. One may generalise von Moltke: plans seldom survive more than a little contact with reality. It remains useful to make them, as long as

Re: [Development] [Releasing] Change file process & improvement proposal

Kai Koehne (10 February 2017 16:21) wrote: > To sum the discussion here and also on gerrit up : There's no > consensus on making [ChangeLog] entries mandatory, or making the > [ChangeLog] field enabled by default. Indeed. > Anyhow, Ossi had an interesting third suggestion on >

Re: [Development] Calendar Systems proposal

On Monday 02 January 2017 09:21:25 Lars Knoll wrote: >>> I wonder whether we can't keep handling of different calendars >>> completely outside of QDate. Something similar to what we've done >>> with QString/QLocale. So QDate would continue unchanged and only >>> support the standard Gregorian

Re: [Development] Nominate Mike Krus as approver

On quarta-feira, 8 de fevereiro de 2017 10:52:10 PST Edward Welbourne wrote: >> ... which may well have been the intent, but the thing about Rules, >> Policies, Laws and Constitutions is that they have to actually *say* >> what they mean Thiago Macieira (8 February 20

Re: [Development] Calendar Systems proposal

I had remarked: >> That shall complement Soroush Rabiei's work on the C++ side: Hamed Masafi (30 January 2017 21:07) replied: > Yes, that's right. I'm trying to port Soroush's calendar mechanism to > qml side of Qt. Good. >> If I understand Lars correctly, he prefers an API where the calendar >>

Re: [Development] Calendar Systems proposal

Soroush Rabiei (30 January 2017 11:04) wrote: > Speaking of the API, I wish to share an idea about not to put calendar > implementations in a plugin subsystem. I should clarify: when I spoke of calendar systems in plugins, I wasn't suggesting we should do that as the normal mode for commonly-used

Re: [Development] Calendar Systems proposal

Sorry to have left this thread dangling for so long. A vast flood of code-review came my way ... Now to work my way back through the thread, staring at the end, so all in JavaScript land: On Mon, Jan 30, 2017, at 09:07 PM, Hamed Masafi wrote: >> My prefer option is form (3) >> We can add an

Re: [Development] Nominate Mike Krus as approver

Am 07.02.2017 um 13:03 schrieb Edward Welbourne: [snip] >> Here's my change to the Wiki page: >> https://wiki.qt.io/index.php?title=The_Qt_Governance_Model=29866=29555 >> >> I doubt I'll get round to QUIPping it any time soon - any volunteers ? Robert Löhning (8 Febr

Re: [Development] Nominate Mike Krus as approver

On terça-feira, 7 de fevereiro de 2017 12:03:47 PST Edward Welbourne wrote: >> Indeed, the "Becoming a Maintainer" section did in fact only permit >> us to nominate existing Approvers as Maintainers; which we have >> violated repeatedly. Thiago Macieira (7 F

Re: [Development] Nominate Mike Krus as approver

Lars Knoll (7 February 2017 12:45) wrote: > The way we have been drawing our governance model as a pyramid had > always implied this for me. But I can see that it’s not explicitly > mentioned in the wiki page. Indeed, the "Becoming a Maintainer" section did in fact only permit us to nominate

Re: [Development] Nominate Mike Krus as approver

Sergio Martins (6 February 2017 17:11) quoted > https://wiki.qt.io/The_Qt_Governance_Model kind of implies you can't > be a maintainer if you're not an approver. > "How to become a Maintainer: An Approver who (...), may be nomiated > (...)" However, the next paragraph adds "A Maintainer may also

Re: [Development] Documentation typo fixes

On 7 February 2017 at 08:39, Ch'Gans wrote: >> It's been a while that I notice some typos here and there in Qt5 >> documentation (mainly qtbase), and i decided that i would start >> correcting them in the source code. Thank you :-) [snip] >> documentation looks always nicer

Re: [Development] Feature Freeze Exception: QStringView

>>> [followed by exception handling code irrelevant for us] >> >> I disagree. The exception code is not irrelevant for our users (and >> not for us, either, e.g. in QtCore). Thiago Macieira (3 February 2017 17:45) > It's irrelevant when the function called is one of ours, in a library > of ours

Re: [Development] Meeting minutes from Qt Release Team meeting 31.1.2017

Jani Heikkinen reported an action item of the release team meeting: >>> * API review to be started immediately after final downmerge. I replied with (January 31, 2017 6:52 PM): >> Let me know as soon as that down-merge is done. >> Speaking of API review, review of >>

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

On Thu, Jan 26, 2017 at 05:28:23AM +, Jani Heikkinen wrote: >> We have now soft branched '5.9' from 'dev'. Target is to have final >> downmerge from 'dev' to '5.9' and Qt 5.9 Feature Freeze 1st of >> February. >> >> Please finalize ongoing changes in 'dev' and start using '5.9' for >> new

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

Liang Jian (29 January 2017 05:13): >Start from qt-5.8 I can't build qt anymore under Windows(simplified > chinese locale). Since there is a file > src/plugins/generic/tuiotouch/qtuiohandler.cpp which contain > non-latin-1 character, msvc2015 assume the source code's character set > should be

Re: [Development] Calendar Systems proposal

Hamed Masafi (30 January 2017 08:59): > I'm working on qml support of calendar system, That shall complement Soroush Rabiei's work on the C++ side: https://codereview.qt-project.org/182341 http://bugreports.qt.io/browse/QTBUG-58404 Prior discussion:

Re: [Development] Change file process & improvement proposal

On Wed, Jan 25, 2017 at 10:21:09AM +0100, Edward Welbourne wrote: >> However, you seem to be talking about *release* 5.x.0 rather than the >> *branch* of that name, so I'm not really clear on what you're talking >> about. 25 January 2017 12:13, Oswald Buddenhagen: > i don't

Re: [Development] Change file process & improvement proposal

On Tue, Jan 24, 2017 at 03:38:11PM +0100, Edward Welbourne wrote: >>> Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0 >>> branched_. Is that easy to enable/disable? >> >> It should be easy to detect that 5.x.0 "has branched" - check

Re: [Development] Change file process & improvement proposal

> Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0 > branched_. Is that easy to enable/disable? It should be easy to detect that 5.x.0 "has branched" - check for existence of either origin/5.x.0 branch or v5.x.0 tag. That we're committing to 5.x is fairly easy *in Gerrit*

Re: [Development] qt5.8 : configuring the use of PulseAudio and/or GStreamer

On quinta-feira, 19 de janeiro de 2017 22:20:59 PST René J. V. Bertin wrote: >> I've also been talking since the beginning about configure. Sorry >> about the confusion. Thiago Macieira replied: > There are two configure scripts: one in the top-level and one in > qtbase. Please be clear which one

Re: [Development] Branch request: wip/itemviews in qtdeclarative

I wrote: > Which reminds me, back in August I investigated then-current wip/s: > http://lists.qt-project.org/pipermail/development/2016-August/026859.html and Ossi brought git fetch's -p option to my attention. Most of those mentioned before are still here, but: > Two branches (only in qtbase)

Re: [Development] Branch request: wip/itemviews in qtdeclarative

Oswald Buddenhagen: > speaking of how hard is to get branches: the policy is quite clear that > done (and abandoned) branches should be deleted (or moved to a hidden > namespace, if you insist on archiving your throw-away branch). they > aren't, they are piling up. what exactly do you expect in

Re: [Development] invokeMethod() with function pointers

Grégoire Barbier: > Kind of Qt::DirectOrBlockingQueuedConnection. Blocking_DirectOrQueued_Connection, surely. Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Calendar Systems proposal

Allan Sandfeld Jensen asked: > Are you aware of KCalenderSystem? Yes - Sergio Martins helpfully brought it up a couple of weeks ago: http://lists.qt-project.org/pipermail/development/2017-January/028241.html Current plan is roughly to upstream it. Debate remains as to whether it should sit

Re: [Development] Calendar Systems proposal

Jake Petroules > Eddy, "draft" does not do what you think it does. This is why no one can see > the change. I think you are addressing the wrong person. Soroush created the review (as a draft) and added me as a reviewer. That enabled me to add Frederic. > Please remove "draft" status and add

Re: [Development] Calendar Systems proposal

On Sunday 15 January 2017 14:39:49 Soroush Rabiei wrote: >> Just submitted first change set: >> >> https://codereview.qt-project.org/#/c/182341/ Frédéric Marchal replied: > I'm seeing an error: "The page you requested was not found, or you do > not have permission to view this page." I've just

Re: [Development] Branch request: wip/itemviews in qtdeclarative

Robin Burchell > I have a longer mental list of things that concern/bother me with > current model/views (some of which we've already discussed), maybe I > should try write that up in some form, if you think it might find it > helpful, but as I don't know how much time I'll be able to dedicate to

Re: [Development] Calendar Systems proposal

Soroush Rabiei > Sorry for being noisy on this list, but I think we have several issues > needed discussion before going further. I should note that Lars still holds to the view that we should keep this out of QDate: which seems to imply roughly just upstreaming KCalendarSystem, albeit with the

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

On 12 January 2017 at 08:39, Lars Knoll wrote: > Here are the criteria I think we should have (and that we IMO implicitly used > in the past): This smells like something we should be turning into a QUIP. Eddy. ___ Development mailing list

Re: [Development] Qt pi

Lars Knoll: > plan sounds good, just go ahead :) I've opened QTBUG-58083 for the sake of tracking it. Anyone with further comments is welcome to look there. On IRC, peppe has pointed out using L may get narrowing warnings from some compilers. So I'll start with using M_PI and Math.PI more

[Development] Qt pi

Hi all, In the course of testing 5.8.0, I was puzzled by an example hard-coding a value for pi, rather than re-using one from some public header as I expected. To my surprise, the standard library only provides M_PI as a POSIX extension. It turns out we do have a qmath.h that, sensibly enough,

Re: [Development] Cloning version 5.6.2

Daniel Pfeifer wrote: > Up until one month ago, the following worked to clone version 5.6.2: > > git clone --branch v5.6.2 git://code.qt.io/qt/qt5.git . > ./init-repository > --module-subset=essential,qtconnectivity,qtlocation,qtserialbus,qtserialport [...] > It now fails with the following

Re: [Development] Calendar Systems proposal

I observed: >> Issue: Q(Date|Time)+ think day-changes happen at midnight. [...] Has >> secular society shifted the day boundary to midnight in practice ? Soroush replied: > Indeed they do the simplification needed to adopt modern lifestyle. OK, good - then we have an excuse to keep the simple

Re: [Development] Calendar Systems proposal

Well, I've missed a long and lively discussion while I was away. I've now caught up with e-mail, digested the thread and done some (but by no means enough) background reading; that's left me with some jumbled notes. This shall be long - let's start with the thread (and fit some of those notes

Re: [Development] Proposal to adjust release candidate process

Since general churn while "stabilising" is a central part of the discussion, let's take a look at the change, since my early November API review push, in just the not-obviously-boring[*] changes to API-related headers. ([*] If you can see any changes in the reviews that a dumb script could be

Re: [Development] [Releasing] Qt 5.8.0 API review

Back on the 7th of November 2016 I announced: > With the 5.8.0 release now close at hand, I've updated the API reviews: I've now updated these for the actual 5.8.0 branch (fetched this morning): https://codereview.qt-project.org/170634 - qtbase https://codereview.qt-project.org/170635 -

Re: [Development] Calendar Systems proposal

Soroush Rabiei wrote: > Nowadays, almost all major programming frameworks support calendar > globalization. We are a small group of developers working with > non-Gregorian calendars and we believe Qt must support this too. This > proposal discusses details of our plan (and early implementation) to

Re: [Development] A new approach for Qt main()

Morten Sorvig supplied: > For some background, here’s what typical application startup looks > like on macOS, NaCl, and Emscripten: I've updated [0] to illustrate these. [0] https://wiki.qt.io/Application_Start-up_Patterns > macOS: Define the application delegate, create instance of it in

Re: [Development] A new approach for Qt main()

Em sexta-feira, 9 de dezembro de 2016, às 10:44:24 PST, Lars Knoll escreveu: > Well, the problem is that the main() entry point is causing huge > amounts of issues on at least Android and iOS. We’d help those > platforms a lot if we didn’t support this kind of entry point (on >

Re: [Development] Very slow incremental builds with 5.8

Sean Harmer: >>> what is the reason that when doing incremental builds with the 5.8 >>> branch that qmake gets run in each and every subdir please? It >>> *really* slows down doing incremental builds. Is there any way to >>> avoid this or can we go back to the 5.7 behaviour please? I can confirm

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

Giuseppe D'Angelo: >> I would also like to point out that, despite we have a repository, we >> still don't have a tool for properly discussing the actual content of >> QUIPs. >> >> * Gerrit does not work because comments cannot be threaded, they >> don't stick to multiple reviews, and they can

Re: [Development] Naming of path/directory-related environment variables in Qt

From: Development on behalf of Jake Petroules Sent: 16 November 2016 20:06 To: J-P Nurmi Cc: development Subject: Re: [Development] Naming of path/directory-related

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

On quarta-feira, 16 de novembro de 2016 17:11:02 PST Marco Bubke wrote: >> Like you maybe have learned there are C++ Core Guidelines. They are >> already very comprehensive. What about basing the Qt Creator Code >> Style on it? >> >> I see advantages like new developer can easier grasp out rules

<    1   2   3   4   5   6   >