On Tue, Jun 18, 2024 at 04:53:32PM +0200, Giuseppe D'Angelo via Development
wrote:
> Hi,
>
> On 18/06/2024 10:15, Alex Blasche via Development wrote:
> > Our biggest issue is the adoption of Qt by users moving from one major
> > release to the next. The deprecations start to become a liability
On Mon, May 27, 2024 at 09:55:37AM +0200, Giuseppe D'Angelo wrote:
> Hi,
>
> On 25/05/2024 13:03, apoenitz wrote:
> > As an open source application developer I mostly care about SC, as SC
> > breakages
> > means actual work for/me/.
>
> To better understand
On Fri, May 24, 2024 at 06:29:41PM +0200, Giuseppe D'Angelo via Development
wrote:
> Hi,
>
> One of the discussions at the past Qt Contributors' Summit was about our BC
> policy:
>
> https://wiki.qt.io/Two-way_BC_in_Patch_Releases
>
> We had a consensus for implementing some changes, but I
On Thu, Mar 28, 2024 at 12:14:35PM +0100, Friedemann Kleint via Development
wrote:
> Hi,
>
> I'd say performance should be a consideration for autotests since they are
> compiled and run over and over again in the CI. So, string theory should be
> applied to avoid unnecessary conversions and
On Mon, Mar 18, 2024 at 02:00:06PM +0100, 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
On Fri, Mar 15, 2024 at 07:16:59AM +, Marc Mutz via Development wrote:
> Summary as of 2024-3-14 EOD: QObject::event() has to stay public.
Ok.
> Please note that this means that any override (and all new QObject
> classes should contain one, since, in case we ever need it, it might not
>
On Tue, Mar 05, 2024 at 10:43:50AM +, Volker Hilsheimer via Development
wrote:
> > On 4 Mar 2024, at 15:56, Kai Köhne via Development
> > wrote:
>
> > Hi Marc,
> > I've nothing against using '#pragma once' for private/internal headers.
> > But you said you mainly want to have this to
On Fri, Feb 23, 2024 at 09:49:17AM +, Jøger Hansegård via Development wrote:
> >> [...]
> >> Would an option be to change from:
> >>
> >> Avoid the use of anonymous namespaces in favor of the static keyword
> >> if possible. A name localized to the compilation unit with static is
> >>
On Wed, Feb 21, 2024 at 06:56:41PM +, Jøger Hansegård via Development wrote:
> >> Our Qt coding conventions ([1]https://wiki.qt.io/Coding_Conventions)
> >> has a statement on the use of unnamed (anonymous) namespaces. As far as
> >> I understand, this statement is now outdated.
>
> >
On Wed, Feb 21, 2024 at 04:26:52PM +, Jøger Hansegård via Development wrote:
>Our Qt coding conventions ([1]https://wiki.qt.io/Coding_Conventions)
>has a statement on the use of unnamed (anonymous) namespaces. As far as
>I understand, this statement is now outdated.
[I'll assume
On Fri, Feb 09, 2024 at 06:51:44PM +0100, Philippe wrote:
> >So, as much as I'd like for some of the things I'mworking on to be
> >able to benefit from C++ 20, I'd also say that we should rather slow
> >down, and only require C++20 if we have something to show for it.
>
> C++20 makes for a more
On Fri, Dec 15, 2023 at 05:40:28AM +, Marc Mutz via Development wrote:
> On 13.12.23 18:36, Thiago Macieira wrote:
> > So, +1 for me on going ahead.
>
> Thanks!
>
> Is anyone else here for/against?
To me this doesn't look like a new feature, so I don't see the feature freeze
blocking this
On Fri, Dec 15, 2023 at 04:25:43PM +, Volker Hilsheimer via Development
wrote:
> > On 15 Dec 2023, at 16:19, Sune Vuorela wrote:
> >
> > On 2023-12-15, Elias Steurer via Development
> > wrote:
> >> No, I still need all the get/set/notify functions to change/get the
> >> variables from the
On Sat, Dec 02, 2023 at 11:25:16AM +0100, Giuseppe D'Angelo via Development
wrote:
> On 30/11/2023 19:39, apoenitz wrote:
> > I propose to make this setup an official Module of Qt Creator, and herewith
> > also nominate Jarek as Maintainer. Jarek has been p
On Thu, Nov 30, 2023 at 07:41:06PM +, Fabian Kosmale wrote:
> Hi,
>
> I agree that it would be nice to properly separate Solutions (to enforce their
> reusability, and to make it easier to include the module into other projects).
>
> I'm also convinced that Jarek would do a good job as the
Hi all.
As you may know, we've started to separate parts of code originally created
specifically for Qt Creator from other parts of Creator's infrastructure in
order to make them more easily reusable in other projects or possible become a
proper Qt module at some time. These "Solutions" are
On Tue, Nov 21, 2023 at 05:00:43PM +0100, André Somers wrote:
> > If not, could we start propagating QTreeWidgetItem or QStandardItem in
> > those examples instead to avoid reinventing?
>
> No, please. I would suggest to instead deprecate these classes, at minimum
> the Widgets (QListWidget,
17 matches
Mail list logo
