Re: [Development] Should QObject::event() be protected or public?

On 18/03/2024 14:00, Giuseppe D'Angelo via Development wrote: On 18/03/2024 13:34, André Somers wrote: While I know it's easy to work around, I sometimes find myself doing it anyway. To me, it signals what API is intended to be used in what way. That a class overrides `event`  (or any other

Re: [Development] Should QObject::event() be protected or public?

Hey, On 18/03/2024 12:12, Giuseppe D'Angelo via Development wrote: Il 15/03/24 21:21, Jaroslaw Kobus via Development ha scritto: To the point: we are talking here about decreasing the visibility of a member function in a subclass. The virtuality of the method isn't relevant I guess, is it?

Re: [Development] QtQuick Layout behavior changes?

Hi, On 27/02/2024 02:46, Jan-Arve Sæther via Development wrote: Hi Nicolas. Thank you for your concern. I've explained the reasoning in the issue here: https://bugreports.qt.io/browse/QTBUG-117597 Well, it appears as if the reasoning in that issue is still concerned with the effects on

Re: [Development] QML Rectangle corner radius API for Qt 6.7

On 22-12-2023 14:12, Tor Arne Vestbø wrote: On 22 Dec 2023, at 13:59, André Somers wrote: And what type would the radius property return then? I guess it would have to be the grouped type. But that would break all code that currently creates a binding on radius expecting it to be a real

Re: [Development] QML Rectangle corner radius API for Qt 6.7

On 22-12-2023 13:54, Tor Arne Vestbø via Development wrote: On 22 Dec 2023, at 13:20, Giuseppe D'Angelo via Development wrote: Il 22/12/23 11:15, André Somers ha scritto: I can see two options. The simplest option is to have a `radii` property, which is a grouped property containing

Re: [Development] QML Rectangle corner radius API for Qt 6.7

On 22-12-2023 13:20, Giuseppe D'Angelo via Development wrote: Il 22/12/23 11:15, André Somers ha scritto: I can see two options. The simplest option is to have a `radii` property, which is a grouped property containing the `topLeft`, `topRight`, `bottomLeft` and `bottomRight` properties

[Development] QML Rectangle corner radius API for Qt 6.7

Hi, Starting from 6.7 we'll have separate corner radii for the corners of a Rectangle. Nice, very welcome! https://doc-snapshots.qt.io/qt6-6.7/qml-qtquick-rectangle.html Unfortunately, the API looks a bit clunky and not ready for further extension. Would it not be better to use a grouped

Re: [Development] QtWidgets Item / Model / View: tree model examples

Hi, On 21-11-2023 16:31, Laszlo Papp wrote: Hi, The tree model examples seem to invent a custom tree item. Simple: https://doc.qt.io/qt-6/qtwidgets-itemviews-simpletreemodel-example.html Edit: https://doc.qt.io/qt-6/qtwidgets-itemviews-editabletreemodel-example.html at

Re: [Development] API style guide: scoped enum or not?

On 03/05/2023 21:42, Marc Mutz via Development wrote: On 03.05.23 20:06, A. Pönitz wrote: My main problem with enum classes _in Qt_ is that it is inconsistent with what has been there traditionally. It is simply no fun to guess what "style" some enum is (and sure, Peppe has a point when

Re: [Development] API style guide: scoped enum or not?

On 04/05/2023 15:51, Sune Vuorela wrote: On 2023-05-04, Marc Mutz via Development wrote: that keeps unported code running. The main issue isn't the scoping, the main issue will be the missing implicit conversion to underlying_type. In few cases the implicit conversion to underlying_type is

Re: [Development] New Chief Maintainer

Hi Volker, On 19-05-2022 22:42, Volker Hilsheimer wrote: On 18 May 2022, at 11:23, André Somers wrote: On 18-05-2022 11:19, André Somers wrote: As I understand it [1], this needs a formal vote. However, the QUIP does not specify a full procedure. I would suggest: And then I forget

Re: [Development] New Chief Maintainer

On 18-05-2022 11:19, André Somers wrote: On 18-05-2022 10:53, Samuel Gaist via Development wrote: Hi, +1 Best regards Samuel As I understand it [1], this needs a formal vote. However, the QUIP does not specify a full procedure. I would suggest: And then I forget the actual link

Re: [Development] New Chief Maintainer

On 18-05-2022 10:53, Samuel Gaist via Development wrote: Hi, +1 Best regards Samuel As I understand it [1], this needs a formal vote. However, the QUIP does not specify a full procedure. I would suggest: 1) a time for people to nominate themselves or get nominated by others (ofc.

Re: [Development] QTreeView: vertical bar between columns

On 17-05-2022 12:12, Laszlo Papp wrote: On Tue, May 17, 2022 at 11:01 AM André Somers wrote: Hi, On 16-05-2022 23:26, Laszlo Papp wrote: > Hi, > > Was just wondering if it was okay to add a property for drawing > vertical bar between columns

Re: [Development] QTreeView: vertical bar between columns

Hi, On 16-05-2022 23:26, Laszlo Papp wrote: Hi, Was just wondering if it was okay to add a property for drawing vertical bar between columns in the body of the QTreeView. Our customer has requested this as otherwise it was challenging to visually separate the columns. It looks like jpn

Re: [Development] Feature freeze exception for QTBUG-95587

Hi, On 14-09-2021 09:12, Shawn Rutledge wrote: On 2021 Sep 13, at 20:58, Elvis Stansvik > wrote: Yes, URLs are vital to QML I guess, but are they *that* vital? The bar should be quite high IMO. In the apps I've worked on, URLs and URL handling is really not central

Re: [Development] Feature freeze exception for QTBUG-95587

On 09-09-2021 17:32, Ulf Hermann wrote: Hello, due to the magnitude of the above mentioned bug, I'm considerng to introduce a new feature in Qt 6.2.1. The new "@" operator in QML relieves you from typing "Qt.resolvedUrl" over and over. See

Re: [Development] Commercial LTS Qt 5.15.4 released

On 12-05-2021 17:51, Thiago Macieira wrote: On Wednesday, 12 May 2021 08:30:52 PDT Frank Hemer wrote: On Mittwoch, 12. Mai 2021 17:26:50 CEST Thiago Macieira wrote: Even maintainers who like me don't get access to the source, it's important to know the release was made. Not having access to

Re: [Development] Making Binary Incompatible Changes after Qt 6.0

Hi, On 07-12-2020 10:24, Volker Hilsheimer wrote: Hi, Given the scale of Qt 6.0 it’s perhaps no surprise that in spite of careful reviews, we are seeing the first API issues popping up, fixing of which would require a breakage of binary compatibility. For example:

Re: [Development] QVariant comparison in Qt6

On 18-09-2020 09:12, Albert Astals Cid via Development wrote: El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago Macieira va escriure: On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote: Hi! There was a discussion about the decision to deprecate (remove?)

Re: [Development] QProperty and library coding guide

On 16-07-2020 17:40, Volker Hilsheimer wrote: We need “text” to be a public member of QAction, otherwise we can’t do action->text(); That ‘text” member is a struct with a bunch of operators overloaded, so that we can do either qDebug() << action->text(); qDebug() << action->text; and

Re: [Development] QProperty and library coding guide

On 16-07-2020 13:08, Edward Welbourne wrote: Il 16/07/20 12:43, Volker Hilsheimer ha scritto: For pre-C++20 (where it’s possible to have zero-size structs), and for compilers that don’t respect the [[no_unqiue_address]] attribute, all these struct-instances are put into a union. In that case,

Re: [Development] QAnyStringView

On 29-06-20 09:20, Edward Welbourne wrote: BTW, any chance we can bait-and-switch, renaming QStringView to QUtf16StringView and rename QAnyStringView into the newly liberated name? Philippe (25 June 2020 08:40) asked: When we deal with strings, the "Uff" affix is unecessarily verbose. Nice

Re: [Development] QString and related changes for Qt 6

On 12-05-20 22:42, Thiago Macieira wrote: QStringView::mid(), for example, returns QStringView, but QString::mid() returns QString. _Should_ QString::mid be returning a QString though? Perhaps it should return a QStringView? André ___ Development

Re: [Development] [SPAM] How bad QList really is

Hi, On 25-04-20 16:49, André Pönitz wrote: We all know the story that began with "We knew for a long time that QList is not a good default container, despite what the documentation claims. The problem boils down to the fact that for a lot of types T, QList is needlessly

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

On 23-04-20 12:49, Mitch Curtis wrote: -Original Message- From: Development On Behalf Of André Somers Sent: Thursday, 23 April 2020 12:04 PM To: Jaroslaw Kobus ; development@qt-project.org Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 Hi, On 23-04-20 11:58, Jaroslaw

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

be deprecated in favor of a QSet::toVector(). André Changing QList to QVector may in consequence require even more API changes. Jarek From: Development on behalf of André Somers Sent: Thursday, April 23, 2020 11:21 AM To: development@qt-

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

Hi Simon, On 23-04-20 10:55, Simon Hausmann wrote: Hi, So take for example this function in QIconEngine: virtual QList availableSizes(QIcon::Mode mode = Icon::Normal, QIcon::State state = QIcon::Off) const; If we change that to QVector, we require our users to clutter their code base

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

On 02/03/2020 16:42, Matthew Woehlke wrote: On 28/02/2020 15.33, Lars Knoll wrote: This is all nice and fun to bike shed about, but I don’t think those proposed solutions match the scope of the original problem (which was relatively small). I don’t think a massive source compatibility breakage

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

Hi Lars, Sent from my phone, please excuse my brevity > On 24 Feb 2020, at 12:27, Lars Knoll wrote: > >  >> >> On 21 Feb 2020, at 17:39, Thiago Macieira wrote: >> >>> On Friday, 21 February 2020 04:59:02 PST Ville Voutilainen wrote: >>> Having a keyword-extension to normal C++ is ugly as

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

Hi, Pure from a transitioning perspective: isn't it rather late for such a massive change? Wasn't it the idea that 5.15 would be the "transitioning" version that people could use to make their code Qt6-ready? In that case, should this not have already been implemented in Qt 5.15, as I think

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

On 31-01-20 15:14, Vitaly Fanaskov wrote: Hi Daniel, I'm confused that there's zero discussion of the work I have done in showing how adding unique_ptr apis would look like. Surely, you have internally discussed that approach. Yes, I saw this patch

Re: [Development] Changes to Qt offering

On 29/01/2020 04:27, Thiago Macieira wrote: On Tuesday, 28 January 2020 08:09:00 PST Matthew Woehlke wrote: I agree... somewhat. Where I disagree is that I would go even further and suggest rethinking their entire business model. Maybe look at companies with a strong and successful open source

Re: [Development] Changes to Qt offering

Hi, On 29/01/2020 04:23, Thiago Macieira wrote: On Tuesday, 28 January 2020 10:01:43 PST Tim Murison wrote: 2. Don’t scare people off before they even start. Much lower initial pricing, no historical licensing, more distant ramps for price increases. Historical licensing cannot go away so

Re: [Development] Changes to Qt offering

On 28/01/2020 10:52, Christian Kandeler wrote: On Mon, 27 Jan 2020 19:09:43 +0100 Giuseppe D'Angelo via Development wrote: Il 27/01/20 16:57, Benjamin TERRIER ha scritto: *We do hope that this eases your concerns, and that we can continue with your trust*.

[Development] Qt installer capabilities (was: Re: Changes to Qt offering)

Hi, On 28/01/2020 12:52, Tino Pyssysalo wrote: On 27.1.2020, 23.53, "Development on behalf of Thiago Macieira" wrote: > On segunda-feira, 27 de janeiro de 2020 10:39:44 PST Elvis Stansvik wrote: > > So? I have an account because I want to contribute. Does not mean I > >

Re: [Development] Changes to Qt offering

On 27/01/2020 22:07, Ville Voutilainen wrote: On Mon, 27 Jan 2020 at 21:56, Dmitriy Purgin wrote: By the way, gathering emails by requiring an account to download the software without any technical reason might be indeed an example of a GDPR violation. I am not a lawyer, but I am unaware of

Re: [Development] QHash for Qt 6

On 24-12-19 11:28, Martin Smith wrote: However, instead of adding template bool qIsEmpty(const T ) { return t.empty(); } we keep discussing how ugly std is=) But that's kind of ugly too. I read it as qlsEmpty(), not qIsEmpty(). See what I mean? On of those is a lower case L. How about a new

Re: [Development] Removing overloaded signals in Qt6

Hi, On 29-11-19 09:15, Ville Voutilainen wrote: On Wed, 27 Nov 2019 at 17:52, Sérgio Martins via Development wrote: Hi, The Qt5 PMF connect syntax is wonderful and very elegant compared to Qt 4. Unless, ofc, you have overloaded signals, which makes it painful to write and read. Not even

Re: [Development] Qt 5.15 schedule proposal

On 27-11-19 07:03, Jani Heikkinen wrote: Hi! Qt 5.14.0 is in its final steps and it is time to start thinking Qt 5.15 release schedule. I don't see any reason/evidence how we could cut the time so my proposal is based on previous releases: Qt 5.15 initial schedule proposal: - All new

Re: [Development] QtCS2019 Notes from "Fuzzing Qt" BoF session

On 22/11/2019 18:17, Giuseppe D'Angelo via Development wrote: Il 21/11/19 13:13, Robert Loehning ha scritto: ** [https://doc.qt.io/qt-5/qregularexpression.html QRegularExpression] This should mostly be fuzzing libpcre itself... Note that users should NEVER use / accept untrusted regular

Re: [Development] QTCS2019 Notes from QtQml session

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). Will something similar still be possible? You should

Re: [Development] QTCS2019 Notes from QtQml session

On 26/11/2019 09:34, Chris Adams wrote: On Mon, Nov 25, 2019 at 9:34 PM Ulf Hermann wrote: I think one of the biggest problems is that ID resolution crosses file boundaries. This essentially means that the ids chosen can very easily become part of the "API" of a component unless you are very

Re: [Development] QTCS2019 Notes from QtQml session

On 25-11-19 15:53, Ulf Hermann wrote: Yeah, that's going to make using QML in actual applications a whole lot harder. For instance, sometimes access to some root node is needed even from deep leaf files. Removing that capability is quite a drastic measure. Yes, but the problems with this

Re: [Development] QTCS2019 Notes from QtQml session

On 25-11-19 12:31, Ulf Hermann wrote: I think one of the biggest problems is that ID resolution crosses file boundaries. This essentially means that the ids chosen can very easily become part of the "API" of a component unless you are very vigilant to not allow that to happen. Well, yes, and

Re: [Development] Two-digit dates: what century should we use ?

On 08-11-19 11:15, Edward Welbourne wrote: André Somers (6 November 2019 17:20) wrote I came to the conclusion that the sane behavior for interpreting dates depends on the semantics of what the date means. For instance, a birth date will always be a date in the past, On 07-11-19 11:47, Edward

Re: [Development] Two-digit dates: what century should we use ?

On 07-11-19 11:47, Edward Welbourne wrote: André Somers (6 November 2019 17:20) wrote I came to the conclusion that the sane behavior for interpreting dates depends on the semantics of what the date means. For instance, a birth date will always be a date in the past, ... except when it's

Re: [Development] Two-digit dates: what century should we use ?

Hi, On 05-11-19 14:44, Edward Welbourne wrote: Hi all, Prompted by [0], I'm looking at what century to use for years, when the text being read is expected to be in a "short format" that only includes two digits. * [0] https://bugreports.qt.io/browse/QTBUG-74323 tl;dr - how do folk feel about

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

On 18/10/2019 02:37, Kevin Kofler wrote: Ville Voutilainen wrote: Since we are about to do a major version upgrade, should be stop being a special snowflake in the C++ world and start attaching pointer-stars and reference-ampersands to the type instead of to the variable? No, because it is

Re: [Development] Qt6 qml

Hi, On 02-10-19 09:39, Nicola De Filippo wrote: Hi, is possible think will Qt6/qml c++ binding similar to swiftui? Perhaps it would be helpful to explain a bit more about how such things work in swiftui, for those not familiar with it? André

[Development] [SPAM] Re: QDialog vs QPushButton and it's autoDefault default

Spam detection software, running on the system "mx.qt-project.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details.

Re: [Development] Opinions on QTBUG-71545

Hi, On 05/11/2018 20:56, Elvis Stansvik wrote: Den mån 5 nov. 2018 kl 20:32 skrev Konstantin Shegunov : Hello, Since we couldn't agree, I'd love to see some more opinions about this one.[1] I may be missing some detail, but I think what Thiago says makes sense. When children are destroyed,

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

Hi, > On 2 Nov 2018, at 16:02, Thiago Macieira wrote: > >> On Friday, 2 November 2018 06:50:50 PDT Jedrzej Nowacki wrote: >>> On Friday, November 2, 2018 4:42:52 AM CET Thiago Macieira wrote: >>> >>> We have a lot of API that, for Qt 6, we've already decided to extend to >>> 64-bit on 64-bit

Re: [Development] Making QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable

On 06/03/2018 11:04, Mitch Curtis wrote: https://codereview.qt-project.org/#/c/221758/ makes QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable so that they can be used from QML. I think that this could be useful to debug issues, but being such a widely used and important

Re: [Development] QVector rvalue overloads for convenience functions?

On 03/03/2018 21:25, Allan Sandfeld Jensen wrote: On Samstag, 3. März 2018 21:11:18 CET Mandeep Sandhu wrote: On Sat, Mar 3, 2018 at 11:46 AM, Christian Ehrlicher wrote: Hi, recently rvalue overloads for QVector::append(T), push_back(T) and others were added to

Re: [Development] QHash

Hi, As already pointed out by the other responders, this cannot be an error. However, perhaps it could be a Clazy check? Because I doubt QHash does what the writer intented in the general case. André Op 18/01/2018 om 15:12 schreef René J.V. Bertin: > Hi, > > It took me a while to figure out

Re: [Development] QtCS 2017 QtCore sessions

Op 01/11/2017 om 22:27 schreef Thiago Macieira: > On quarta-feira, 1 de novembro de 2017 13:15:11 PDT André Somers wrote: >> That doesn't make sense. Of course it allows for that. >> >> You'd give indexOf a flag like Qt::searchTowardsBeginning (default being >> Qt::sea

Re: [Development] QtCS 2017 QtCore sessions

Op 01/11/2017 om 16:46 schreef Thiago Macieira: > On quarta-feira, 1 de novembro de 2017 08:25:01 PDT Konstantin Tokarev wrote: >>> No, not really, since it's already limited to half the full VM space. No >>> object can be larger than that. Using unsigned is unnecessary. >> Using unsigned for

Re: [Development] Future of QBS

Op 17/10/2017 om 17:31 schreef Oswald Buddenhagen: > On Tue, Oct 17, 2017 at 05:23:17PM +0200, Ulf Hermann wrote: Exactly. The halting problem can be worked around pragmatically. >>> ... at the price of getting different build results based on CPU speed ... >>> >>> Your fast desktop CPU

Re: [Development] Future of QBS

Op 17/10/2017 om 03:01 schreef Kevin Kofler: > Konstantin Tokarev wrote: >> This problem is solved by having access to full "project" model from the >> same language. E.g. this is how I implemented Premake plugin for Qt >> Creator a while ago: added Lua code to traverse Premake's project >>

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

Op 13/10/2017 om 13:04 schreef Viktor Engelmann: > 4. I don't think we need to be as paranoid towards contributions from > our own employees as we need to be towards external contributions. > > So much for open government... André ___ Development

Re: [Development] Pointer Handlers will be Tech Preview in 5.10

Op 28/09/2017 om 13:42 schreef Tor Arne Vestbø: > On 28/09/2017 13:36, J-P Nurmi wrote: >> I would prefer attached properties and signals. Similarly to >> Keys.onPressed. Attaching onTapped from the outside of a component >> would be similar to overriding an event handler in C++. There would >>

Re: [Development] Qt Coding style and C++11

Op 18/09/2017 om 09:02 schreef Lorn Potter: >> On 15 Sep 2017, at 6:47 pm, Kevin Funk wrote: >> >> (2) And maybe your request: >> - Use C++11 member initialization where possible >> (IOW: Run clang-tidy cppcoreguidelines-pro-type-member-init checker >> on code base and

Re: [Development] QList

Hi, Op 29/05/2017 om 14:53 schreef Jason H: >> Sent: Thursday, May 25, 2017 at 7:03 PM >> From: "André Somers" <an...@familiesomers.nl> >> To: "Christoph Feck" <cf...@kde.org> >> Cc: development@qt-project.org >> Subject: Re

Re: [Development] QList

Hi, Sent from my phone, please excuse my brevity > On 25 May 2017, at 18:40, Christoph Feck <cf...@kde.org> wrote: > >> On 25.05.2017 13:53, André Somers wrote: >> Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: >>> Other problem, that IMO is more serious,

Re: [Development] QList

Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: > > 25.05.2017, 02:19, "Ville Voutilainen" : >> On 24 May 2017 at 22:25, Marc Mutz wrote: >>> On 2017-05-24 15:12, Konstantin Tokarev wrote: 24.05.2017, 15:49, "NIkolai Marchenko"

Re: [Development] [docs] changing the way overloads are documented and presented

Op 28/04/2017 om 15:48 schreef Martin Smith: >> I am a bit worried about having a good way to describe the specifics of a >> >specific overload or group thereof. > Remember you will still have the option of giving an overload its own qdoc > comment instead of including it in the common \fn

Re: [Development] [docs] changing the way overloads are documented and presented

Op 28/04/2017 om 09:35 schreef Marc Mutz: > Hi. > > TL;DR: I propose to document overloaded functions with a single comment block, > containing multiple \fn's and a common documentation text, to be rendered as > one documentation block preceded by a listing of all the \fn's, instead of as >

Re: [Development] QList

Op 24/04/2017 om 20:39 schreef Marc Mutz: > On 2017-04-24 20:19, Ville Voutilainen wrote: > [...] >> What is wrong with QArrayList? > > Nothing, IMO, in the version proposed by me: > https://codereview.qt-project.org/188938 > > But since there's been no +2 forthcoming on above change, and I will

Re: [Development] Lack of base classes/interfaces? Q*, Q*F

Op 17/04/2017 om 08:02 schreef Jason H: > Maybe templates are the way to go. But I just had to change some lines > because I was using vectors and Qt was using QList. I'd like to eliminate the > need/cost for QList::toVector() and QVector::toList(). If there was a base > that provided the

Re: [Development] QList

Op 27/03/2017 om 09:22 schreef Martin Smith: > > > A vector is a collection of points and so is a polygon. Both > are even ordered. > > > vector is an ordered collection of points, but a QVector can > contain anything; QVector can even contain unlike things, which > is truly a tuple. So

Re: [Development] QList

Op 21/03/2017 om 16:55 schreef Thiago Macieira: > Em terça-feira, 21 de março de 2017, às 05:22:31 PDT, André Somers escreveu: >> Op 20/03/2017 om 23:43 schreef Kevin Kofler: >>> Marc Mutz wrote: >>>> https://github.com/KDE/libkleo/blob/2fe48b77ba61fada80eaace8c

Re: [Development] QList

Op 20/03/2017 om 23:43 schreef Kevin Kofler: > Marc Mutz wrote: >> https://github.com/KDE/libkleo/blob/2fe48b77ba61fada80eaace8cb71dd0fd13265ae/src/kleo/stl_util.h > Thanks for proving my point that the STL APIs require tons of copy > boilerplate in every project. > > That's not just your

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

Op 07/03/2017 om 22:43 schreef Richard Moore: > > > You're right. My wording above was misleading, I wasn't present > myself. This is what I remembered people telling me afterwards. > > Here are the session > notes: https://wiki.qt.io/Qt_build_systems_at_QtCon_2016 >

Re: [Development] Feature Freeze Exception: QStringView

Op 03/02/2017 om 14:27 schreef Giuseppe D'Angelo: Il 03/02/2017 13:48, Kevin Kofler ha scritto: We really need a plan to deprecate implicit casts between QString and ASCII. They are not only the source of such inefficiencies from inexperienced or lazy programmers, but also of encoding-related

Re: [Development] Request moving project to playground area

Op 03/02/2017 om 10:18 schreef Jesus Fernandez: On Thursday, February 02, 2017 07:38:00 PM Hamed Masafi wrote: Declaring persistant objects in ORM is straightforward: class Comment : public Table { Q_OBJECT NUT_PRIMARY_AUTO_INCREMENT(id)

Re: [Development] Proposal to adjust release candidate process

Hi, Op 22/12/2016 om 13:54 schreef Tuukka Turunen: -Original Message- From: Development [mailto:development- bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Shawn Rutledge Sent: torstaina 22. joulukuuta 2016 9.25 To: development@qt-project.org; releas...@qt-project.org

Re: [Development] Calendar Systems proposal

Op 15/12/2016 om 22:10 schreef Sune Vuorela: On 2016-12-15, Soroush Rabiei wrote: 2.History Hi I would welcome more calendar systems. Personally I hope for french revolutionary calendar. Because it is funny. I think you need to touch quite some of the 'inner

Re: [Development] [closed] Using semicolons in JS (QML)

So, now we need one of these QUIPs to document the descision if I understand it correctly ? André Op 06/10/2016 om 10:58 schreef Mitch Curtis: To make it a bit more formal and hopefully prevent it from being lost in the mail archives, let's update our QML coding conventions:

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

Hi, Thanks for posting this, it finally cleared up a few postings by Thiago from just after the event. I wrestled my way through this whole thing, trying to get through the self-referential nature of all the acronyms. Somewhere in the middle I finally found what a QUIP is supposed to be.

Re: [Development] On deprecated APIs

Op 31/08/2016 om 09:38 schreef Marc Mutz: Hi, My porting guide for Q_FOREACH -> C++11 ranged for has created the expected outcry from users. I think some of the FUD comes from the fact that deprecation in 5.x usually means that the API is gone in Qt 6.0. I'd therefore like to propose a new

Re: [Development] QML: Why C++11 scoped enums are not scoped in QML?

Op 27/07/2016 om 09:53 schreef BogDan Vatra: That said, it would be a behavior change not to allow anymore the previous (unscoped) syntax to work with QML The unscoped enums should work as they are woring now, just the scoped ones should be scoped in QML as well. Based on your patch, I'll

Re: [Development] Stack Overflow Documentation

Op 21/07/2016 om 16:35 schreef Sze Howe Koh: On 21 July 2016 at 19:04, Mitch Curtis wrote: Hello. Stack Overflow Documentation is now in Beta. You can read more about it here: http://stackoverflow.com/tour/documentation It is much more accessible than our contribution

Re: [Development] leak in QMetaObject?

Op 20/07/2016 om 11:39 schreef Edward Welbourne: Op 20/07/2016 om 10:41 schreef Olivier Goffart: The distribution does not matter. If it can be big, quadradic complexity can be a blocker. André Somers replied Nonsense. There is no need to pessimize the frequent cases to cater for avoiding

Re: [Development] leak in QMetaObject?

Op 20/07/2016 om 10:41 schreef Olivier Goffart: On Mittwoch, 20. Juli 2016 10:01:26 CEST André Somers wrote: Op 19/07/2016 om 18:06 schreef Olivier Goffart: It is true that we could consider trying to clean the connection list after each signal emission if it is dirty. We don't want to do

Re: [Development] leak in QMetaObject?

Op 19/07/2016 om 18:06 schreef Olivier Goffart: On Donnerstag, 14. Juli 2016 17:45:58 CEST Thomas Senyk wrote: On 14.07.2016 17:18, André Somers wrote: Op 14/07/2016 om 17:10 schreef Olivier Goffart: On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote: Hi, I lately wanted

Re: [Development] leak in QMetaObject?

Op 14/07/2016 om 17:10 schreef Olivier Goffart: On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote: Hi, I lately wanted to validate that a connecting to a lambda will not leak the lambda object .. and found that more then that is leaked. Here is my example:

Re: [Development] QTableView gets freezed in showing data read from SQLite database , which is updated dynamically with 2000 rows in 2s

Op 09/07/2016 om 20:01 schreef swarit wipra: Hi folks, i have issues in showing huge data in QTableView ,data read from sqlite database which is being updated dynamically .. 2k rows in 2s. i am using QSQLRelationModel let me describe the scenario in detail. My Qt application has a view i.e

Re: [Development] Use of Standard Library containers in Qt source code

Op 07/07/2016 om 09:10 schreef Marc Mutz: On Thursday 07 July 2016 03:00:08 Thiago Macieira wrote: In case we're not getting the deserved attention due to Summer vacations, I'll post again in a month or so to see if there's any change. We have The Chief on record saying that we should use

Re: [Development] Use of Standard Library containers in Qt source code

Op 04/07/2016 om 10:03 schreef Philippe: Actually, I disagree with that. As someone who has come to appreciate STL after growing up in the Qt world, Exact opposite here: I learned STL from its early days, and could never become at ease with its namings... and I started to breath with Qt

Re: [Development] Use of Standard Library containers in Qt source code

Op 04/07/2016 om 08:41 schreef Thiago Macieira: On segunda-feira, 4 de julho de 2016 08:14:21 PDT Julien Blanc wrote: Following Stephen Kelly’s mails, I’m convinced that instead of wrapping stl containers, implementing a free function qIsEmpty is less work and addresses all your readability

Re: [Development] [Interest] Native event filter in QtService

Op 24/06/2016 om 11:18 schreef Bo Thorsen: Hi all, I'm copying this to devel, because it fits in a discussion a week or two ago. Den 24-06-2016 kl. 10:56 skrev Tony Rietwyk: qtservice_win.cpp around line 830 at your reference [1] installs its own nativeEventFilter - probably displacing

Re: [Development] commas in ctor-init-lists

Op 03/06/2016 om 14:52 schreef Marc Mutz: On Friday 03 June 2016 14:26:03 André Somers wrote: Op 03/06/2016 om 13:53 schreef Marc Mutz: On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: if (somee.really(long.and.complicated, expression) || another.such(that, makes

Re: [Development] commas in ctor-init-lists

Op 03/06/2016 om 13:53 schreef Marc Mutz: On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: if (somee.really(long.and.complicated, expression) || another.such(that, makes, the.line.too.long) || and.then.some.more()) To be perfectly blunt: such expressions shouldn't be allowed.

Re: [Development] commas in ctor-init-lists

Op 03/06/2016 om 08:52 schreef Martin Smith: You can do this, given: Nobody does that. We always write: * You bla, or you boo, or you foo, and in this case we would normally write: You bla, you boo, or you foo. Even better: You bla, boo, or foo. You are inventing problems that don't exist.

Re: [Development] commas in ctor-init-lists

Op 02/06/2016 om 21:47 schreef André Pönitz: On Wed, Jun 01, 2016 at 03:36:43PM +0200, Olivier Goffart wrote: On Mittwoch, 1. Juni 2016 12:56:12 CEST Simon Hausmann wrote: Hi, I'm in favorof changing our coding style to adopt the model you call "butt ugly" because I find it more appealing

Re: [Development] commas in ctor-init-lists

Hi, Op 03/06/2016 om 08:28 schreef Martin Smith: but it is very structurally clean and in some circumstances I prefer it due to that. The structure is a comma separated list. Historically, the comma has always been placed directly after the first of two list items. The comma tells the

Re: [Development] Documentation for QPagedPrintDevice::setPageSize should specify a unit`

agreement * Clone Qt - Which branch? 5.8? * prepare a patch altering the docs in the source code comments, submit to code review… QUESTION * Who do I put as reviewer for this change? Steve Schilz PASCO scientific - think science On 5/4/16, 11:06 PM, "André S

Re: [Development] Heads up! Fixing the build system on Windows

Op 01/04/2016 om 07:49 schreef Thiago Macieira: I want to point this out: On quinta-feira, 31 de março de 2016 22:48:35 PDT Thiago Macieira wrote: On sexta-feira, 1 de abril de 2016 05:16:33 PDT Tvete Paul wrote: It's still March 31st. April Fools rules, #27: all jokes refer to the jokers'

Re: [Development] Changing definition of Qt meta macro to allow tools integration

Op 31/03/2016 om 06:04 schreef Thiago Macieira: On quinta-feira, 31 de março de 2016 00:10:48 PDT Olivier Goffart wrote: The question is rather, the Qt creator that will be release in 2 years will maybe want to use these macros to auto complete signals/slots and properties. I would assume

  1   2   3   4   >