Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?

On 21.02.24 19:56, Edward Welbourne via Development wrote: Andre' Poenitz (21 February 2024 19:21) wrote: 1. 'static' is attached to individual functions, not a scope of uncertain extend. When working on unfamiliar code it helps to understand the context. With 'static' the locality is obvious

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

Hi Thiago This is introducing dependencies on code which makes dependency breaking much harder. I very often need an enumeration in an interface but not the class itself. There are ways to get around that but it makes TDD harder if Qt is involved. From:

Re: [Development] Nominating Knud Dollereder as approver

+1 From: Development On Behalf Of Thomas Hartmann Sent: Monday, June 14, 2021 12:21 PM To: development@qt-project.org Subject: [Development] Nominating Knud Dollereder as approver Hi all, I'd like to nominate Knud Dollereder as an approver for the Qt Project. Mahmoud has been working on Qt

Re: [Development] Nominating Henning Gründl as approver

+1 From: Development On Behalf Of Thomas Hartmann Sent: Monday, June 14, 2021 12:30 PM To: development@qt-project.org Subject: [Development] Nominating Henning Gründl as approver Hi all, I'd like to nominate Henning Gründl as an approver for the Qt Project. Henning has been working on Qt

Re: [Development] Nominating Aleksei German as aproover

+1 From: Development On Behalf Of Thomas Hartmann Sent: Monday, June 14, 2021 12:27 PM To: development@qt-project.org Subject: [Development] Nominating Aleksei German as aproover Hi all, I'd like to nominate Aleksei German as an approver for the Qt Project. Aleksei has been working on Qt

Re: [Development] qsizetype and classes working with QStrings or QList

A new Document API where you could memory map the file and save the changes as a log on top would be nice. For lines you have to read the file but you don't have to hold it completely in memory. An other advantage would be that your document would be a binary reflection of the file. But I think

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

auto view3 = myObject.getCopy()[42].getView(); // not safe, copy is destroyed AFAIK you can say that a rvalue should not return a reference by using ref-qualified member functions. View getView() const & { return v;} ___ Development mailing list

Re: [Development] unique_ptr and Qt, Take 2

On June 13, 2019 17:25:15 Matthew Woehlke wrote: > On 13/06/2019 03.03, Marco Bubke wrote: >> On June 12, 2019 23:13:14 Matthew Woehlke wrote: >>>> me here. I think Daniel is on to something and we really should explore >>>> having smart pointers in Qt 6, bu

Re: [Development] unique_ptr and Qt, Take 2

On June 12, 2019 23:13:14 Matthew Woehlke wrote: >> me here. I think Daniel is on to something and we really should explore >> having smart pointers in Qt 6, but at this point I'm not convinced >> std::unique_ptr alone is it. I'd like to see what we could achieve with a >> QObject-specific smart

Re: [Development] QList for Qt 6

Maybe flatpak is the way to go? There could be two runtimes. Personally I use more and more flatpaks because I get up-to-date packages provided by the developers. On May 24, 2019 19:59:52 Lisandro Damián Nicanor Pérez Meyer wrote: > Hi! > > On Mon, 20 May 2019 at 10:53, Lars Knoll wrote: >

Re: [Development] Views

On 20/05/2019 23:11, André Pönitz wrote: > On Mon, May 20, 2019 at 08:44:47PM +0000, Marco Bubke wrote: >> On May 20, 2019 22:16:11 André Pönitz wrote: >> >>> On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote: >>>> [...] There

Re: [Development] Views

On May 20, 2019 22:16:11 André Pönitz wrote: > On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote: >> [...] There is no readability difference between the use of a Qt container >> and >> that of an STL container. > > Exhibit A: > > foo().contains(x) > > > Exhibit B:

Re: [Development] Views

Thiago, you partially implying that BC is still needed but with technologies like flatpak or snappy this will maybe not common use case anymore. They provide even behaviour compatibility if you stay with the same runtime. Something which is not provided by binary compability. I personally think

Re: [Development] A deployment tool for Linux

Sounds you want flatpak. ;-) On April 10, 2019 21:43:31 Richard Weickelt wrote: >>> I, as a person, think that a "deployment tool for Linux" is >>> something that spits out packages in half a dozen "native" >>> distribution package formats. >> >> Nope, that tool is called "package maintainer"

Re: [Development] Looking for Feedback QDeferred

And don't let forget excutors: http://www.vollmann.ch/en/presentations/executors2018.pdf They will be end in C++ and it would be nice to be fit in. From: Development on behalf of Denis Kormalev Sent: Monday, March 4, 2019 1:05 AM To: Juan Gonzalez Burgos Cc:

Re: [Development] New API design for file system operations

+2 On February 8, 2019 11:12:25 Christian Kandeler wrote: > On Thu, 7 Feb 2019 16:03:30 + > Volker Hilsheimer wrote: > >> Thoughts, ideas, and pointers to other frameworks that you believe provide a >> good API are welcome here in this email thread before moving to a dedicated >> JIRA

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

I am not sure it would be a good idea because a glyph can be still composed of more than one code points which is language dependent. Some time you want characters, sometimes code points and sometimes glyphs etc.. Would it be not better to use a simple container and then functions on top which

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

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. From: Development on behalf of Allan Sandfeld Jensen Sent: Tuesday,

Re: [Development] QUIP 12: Code of Conduct

Hallo Jason > It was purely about lines of code. It was elegant and beautiful, and brutally > simple. This is aesthetics and if you would reflect about it with other you could find out that is very context sensitive. My experience in this area is that their are many people who prefer

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

Enumerations inside of classes makes dependency breaking harder. We don't use that in Qt but users of our interface may do. It's still possible but much more complex because you generally get much more dependencies. A simple header file for enumerations instead can simply be included without

Re: [Development] QtCS 2018: Third-party and security policy

On June 9, 2018 04:10:58 Thiago Macieira wrote: > There's a session scheduled for Monday (unless it gets moved). Here's what I > will propose. > > 0) Where not really necessary, delete the third-party code and force the use > of a system library (see assimp discussion, can be applied to

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

The Sqlite module is not a plugin but a library. It is linked to a plugin but this plugin is not build in release and normally disabled. Like I said, it can be simply not build for release. Please stick to KISS. On June 8, 2018 16:30:19 Edward Welbourne wrote: > Marco Bubke (7 June 2018 19

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

AFAIK the refactoring plugin is disabled for release. Just do the same for the Sqlite library. On June 7, 2018 23:54:43 Thiago Macieira wrote: > On Thursday, 7 June 2018 06:56:11 PDT Lisandro Damián Nicanor Pérez Meyer > wrote: >> El jueves, 7 de junio de 2018 07:17:10 -03 Marco Bu

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

It is used buy the Clang refactoring plugin, which is not build by default. So I see no urgency in it except it will break it. Let's discuss it if I am back. On June 7, 2018 15:06:57 Thiago Macieira wrote: > On Wednesday, 6 June 2018 23:52:35 PDT Marco Bubke wrote: >> Hi >> >

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

Hi I am on vacation till end of July, I am looking forward to discuss it in August. Best regards, Marco On June 7, 2018 11:13:24 Thiago Macieira wrote: > On Wednesday, 6 June 2018 19:57:55 PDT Thiago Macieira wrote: >> On Wednesday, 6 June 2018 19:09:00 PDT Lisandro Damián Nicanor Pérez Meyer

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

where we can send the crash dumps. From: Development <development-bounces+marco.bubke=qt...@qt-project.org> on behalf of Marco Bubke <marco.bu...@qt.io> Sent: Monday, February 26, 2018 6:29:22 PM To: Edward Welbourne; Robert Loehning; André Pönitz Cc: de

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

Edward Welbourne: > When you look into the feature that no-one uses much, you may find that most > users > that do use it have a crash report following close on the heels of their > use of it; you can make an educated guess at why they don't use it after that. We have already a crash reporter,

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

It would be nice if you can explain what data you want to collect and how it will be help the creator development. In my view it is quite hard to collect data about not implemented features, so you could only provide information about what feature is used. So the data could be used to see what

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

> Well, there are things that are hard to report via survey, e.g. rate of > crashes or memory leaking in clangbackend We have a crash handler in the works, which is much more useful than this. And memory leaks can simply be investigated simply by debugging. I don't see how this plugin could

Re: [Development] Setters: Clarifying the ownership

Using a standard from the Cpp Core Guidelines will have the advantage of better tooling support. And please don't use the preprocessor, it will down slow the refactoring or makes it impossible. From: Development

[Development] Nominating Ivan Donchevskii for approver

I'd like to nominate Ivan Donchevskii for Approver. He is working since spring at the C++ support of Qt Creator. Since then his changes made a strong impact to the C++ support. He worked on the Clang integration for Qt Creator, Clang itself, improved the static analyses, polished the

Re: [Development] Proposal to adjust release candidate process

I think many users see a beta as something you better not touch, but a release candidates can be trusted much more. I know it's not intended that way but people learned by experiences. [?] Maybe "pre release" or "preview" could be a name to show the final status?

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

<mwoehlke.fl...@gmail.com> Sent: Thursday, November 24, 2016 5:36:04 PM To: development@qt-project.org Cc: Marco Bubke Subject: Re: Basing Qt Creator Coding Style on C++ Core Guidelines? On 2016-11-22 06:25, Marco Bubke wrote: > On November 22, 2016 08:17:57 Thiago Macieira wrote: >> Them

[Development] Summary ABI compabilty

Hi I try to gather all arguments so they don't get lost: Short Term ABI compability(1-2 years): * better bug fixing * faster development * faster adoption of standards - con: we don't want to adapt them because our solution is better Long Term ABI compability(5-10 years): * easier

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

On November 22, 2016 08:17:57 Thiago Macieira <thiago.macie...@intel.com> wrote: > On terça-feira, 22 de novembro de 2016 06:13:44 PST Marco Bubke wrote: >> So you say it it does not work because of themeing support? Isn't Qt >> Controls 2 not anymore providing them too. And

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

On November 22, 2016 00:47:26 Thiago Macieira <thiago.macie...@intel.com> wrote: > On segunda-feira, 21 de novembro de 2016 23:18:08 PST Marco Bubke wrote: >> I strongly agree with Andre'. And is a BC break in the time of flat pack >> that bad? As an user I really looking

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

On November 22, 2016 01:30:47 Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com> wrote: > On lunes, 21 de noviembre de 2016 23:18:08 ART Marco Bubke wrote: > [snip] >> And how many applications are Qt only and use no standard lib anyway? Are >> there any numbe

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

On November 22, 2016 02:10:50 Thiago Macieira wrote: > On segunda-feira, 21 de novembro de 2016 21:30:28 PST Lisandro Damián Nicanor > Pérez Meyer wrote: >> I guess GTK maintainers suffer, specially with the last changes they >> announced some time ago about breaking

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

On November 21, 2016 23:57:07 André Pönitz wrote: > On Mon, Nov 21, 2016 at 03:49:49PM -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: >> On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote: >> [snip] >> > - people using Qt in applications distributed

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

On November 21, 2016 20:02:54 André Pönitz wrote: > On Mon, Nov 21, 2016 at 11:06:52AM +, Edward Welbourne wrote: >> 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

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

So how often do you had a BC break in stdlibc++? On November 21, 2016 19:50:23 Lisandro Damián Nicanor Pérez Meyer wrote: > On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote: > [snip] >> - people using Qt in applications distributed by packaging >>

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

On November 21, 2016 14:29:10 Shawn Rutledge wrote: > >> On 21 Nov 2016, at 12:06, Edward Welbourne wrote: >> >> 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

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

On November 21, 2016 13:51:10 Oswald Buddenhagen <oswald.buddenha...@qt.io> wrote: > On Mon, Nov 21, 2016 at 01:37:50PM +0100, Marco Bubke wrote: >> On November 21, 2016 12:58:59 Oswald Buddenhagen <oswald.buddenha...@qt.io> >> wrote: >> > how about tak

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

On November 21, 2016 12:58:59 Oswald Buddenhagen wrote: > On Sun, Nov 20, 2016 at 08:38:50PM +0100, Giuseppe D'Angelo wrote: >> On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen >> wrote: >> > the repository has been created. >> >> I

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

On November 20, 2016 20:39:08 Giuseppe D'Angelo wrote: > On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen > wrote: >> the repository has been created. > > I would also like to point out that, despite we have a repository, we > still don't have a

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

On November 18, 2016 22:13:03 Thiago Macieira wrote: > Em sexta-feira, 18 de novembro de 2016, às 20:37:26 PST, Marc Mutz escreveu: >> There's no reason for Qt to extend its BC guarantees to other libraries. >> STL, GSL, Boost, std::exception, you name it. They are

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

11:35:54 AM To: development@qt-project.org Subject: Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? On Thursday 17 November 2016 10:46:24 Edward Welbourne wrote: > On quarta-feira, 16 de novembro de 2016 17:11:02 PST Marco Bubke wrote: > >> Like you maybe have le

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

Hi This is a Qt Creator topic only so sorry to disturb every body else. 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 because

Re: [Development] Branch for adding Q_DECL_OVERRIDEs

Final can be used by the compiler by optimazing the virtual call away but it has the drawback that you cannot overload it in testing code to mock or fake a class. On October 27, 2016 18:36:01 Giuseppe D'Angelo wrote: > Hi, > > please keep the discussion on the

Re: [Development] clangbackend qtcreator 4.2 memory hogging

If c++ modules becomes supported it could go down but actually you should request that in the clang mailling list. We open a translation unit for every file and they are that big. We research precompiled header to improve speed and maybe they provide advantages in memory usage too.

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

> Why would we want UTF-8? There's no native type for it, unlike UTF-16's > char16_t. And ALL the good Unicode-capable API in most OSes uses UTF-16 (Java, > ICU, Win32, Cocoa, all are UTF-16; POSIX's wide-char API is neither good nor > guaranteed to be UTF-32). UTF-8 is used by many libraries

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

I think it simply a question of time to get used to the STL. You get used to many things. I think we should mind about the new features of C++ which are coming, which cannot integrated very well with Qt because we use a different idiom. I really think we should make it easier for the

Re: [Development] Changing qreal to a float

Hi QMatrix4x4 is still qreal, which is still target depend? Is there any intention to change that? Best regards, Marco ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development