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 i
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: Develop
+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 3D
+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 Stud
+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 Stud
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
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
Devel
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
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 p
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:
> [
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 is n
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:
>
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
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" :)
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: de
+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 ti
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 u
You can use std::string which as small string optimization instead of
QByteArray too. In many cases where you would use const String &foo you can use
std::string_view, so you are more flexible.
From: Development on behalf of Allan
Sandfeld Jensen
Sent: Tuesday
Is it not nice to share your knowledge why it is not possible? 😉 Is it because
the meta type information could be created later? What about adding a constexpr
version like: QMetaEnum::compileTimeFromType? Or do we wait for static
reflections?
From: Development
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 intera
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 any
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 qtimagefo
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
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
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
>>
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
r instance where we can send the crash
dumps.
From: Development on
behalf of Marco Bubke
Sent: Monday, February 26, 2018 6:29:22 PM
To: Edward Welbourne; Robert Loehning; André Pönitz
Cc: development@qt-project.org; Ryein Goddard; qt-crea...@qt-project
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,
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 s
> 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 he
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 on
behalf of Eric Lemanisser
Sent: Saturday, Jan
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 Windows
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?
w Woehlke
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:
>> Theming and styling is a
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 li
On November 22, 2016 08:17:57 Thiago Macieira 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 is there no technical
&
On November 22, 2016 00:47:26 Thiago Macieira 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 forward to flat pack, s
On November 22, 2016 01:30:47 Lisandro Damián Nicanor Pérez Meyer
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 numbers?
>
> Good question, I
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 API/ABI (sorry, I don't reme
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 by packaging
>> > syst
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 actual content of
>> >>
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
>> systems (read "Linux dis
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 discussing the actual content of
QUIPs.
>
On November 21, 2016 13:51:10 Oswald Buddenhagen
wrote:
> On Mon, Nov 21, 2016 at 01:37:50PM +0100, Marco Bubke wrote:
>> On November 21, 2016 12:58:59 Oswald Buddenhagen
>> wrote:
>> > how about taking the existing processes seriously and exercising social
>>
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 would also like to point out that, despite we have a rep
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 tool for properly discussing the actual conten
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 outside of Qt's
>> realm and
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 learned there are C++ Core Guidelines. They are
> >> already very comprehensi
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 th
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 mailing list, so others can ch
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.
> 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 and
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 develope
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
54 matches
Mail list logo