On Sat, Mar 16, 2024 at 4:01 PM Marc Mutz via Development <
development@qt-project.org> wrote:
> Function != variable ;-)
>
Granted, they're different and using declarations are intended for and work
for _both_ functions and variables.
I was simply providing some context where this syntax is
On Fri, Mar 15, 2024 at 10:48 PM Marc Mutz via Development <
development@qt-project.org> wrote:
> The member variable thing sounds very wrong. I'd be surprised if it
> compiled.
Then you'd be surprised.
> If it does, it's probably something new in C++23 or 26 whereby
> you can use `using` for
Hi,
I imagine you're using a russian IP address, so this[1] should shed some
light on the matter.
Kind regards,
Konstantin.
[1]: https://forum.qt.io/topic/134724/unlock-qt-in-russia
___
Development mailing list
Development@qt-project.org
This thread has been utterly useful, and thanks all for the input. May I
suggest, however, these tips get documented somehow (e.g. in the wiki)?
As it happens, what Eddy and Thiago wrote was truly a life saver for my
current poking into qtbase. Rebuilding the bootstrap lib invalidates
basically
On Mon, Jan 24, 2022 at 8:50 PM Thiago Macieira
wrote:
> If you're talking about code in Qt, simply use std::fma and it'll do the
> right
> thing. It becomes my problem to optimise it so we get the shortest code
> emission, not yours.
>
So as it is now in that case. If it's not my problem but
On Mon, Jan 24, 2022 at 7:32 PM Thiago Macieira
wrote:
> Today, only in the two files with "_avx2" in the name, unless you raise
> the
> CPU architecture yourself while configuring Qt. My proposal is to get that
> on
> Linux by default with the v3 extra build.
>
Yes, this I got from the
Related, but somewhat offtopic for the original thread.
Do we get `-mfma` (or equivalent) added, whenever supported, while we build
Qt. Is it part of the feature detection? Because I want `std::fma` to emit
the instruction(s), but I've noticed that in the code I test a bugfix with
I must force the
Thank you all for the insights!
On Sun, Jan 9, 2022 at 5:02 PM Arno Rehn wrote:
> I don't think that this is possible with CMake.
>
> I've been working around that by (re-)building only the module I'm
> working on with qtbase/bin/qt-configure-module in a seperate directory.
> That single-module
Hello,
In the Qt5 times with qmake I was able to run the makefile generator on the
top of the Qt tree and then import build in Creator for some specific
module I'd wanted to work on. Is something like this still possible for Qt6
and cmake (I'm currently using the default ninja generator)?
The
On Sun, May 30, 2021 at 6:14 PM Giuseppe D'Angelo
wrote:
> > That should work, but it'd be one of them "exceptions", wouldn't it ...?
> ;)
>
> Sorry, exceptions to what?
>
I was simply teasing. I was referring to this thread about QTBUG-71545[1],
where I wanted the application to destroy its
On Sun, May 30, 2021 at 2:05 PM Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:
> I'd tend to agree with idea, but not with the specific solution. You may
> want
>
> 1) to keep the cache alive across multiple QGA::exec() invocations,
> 2) to destroy it only when QGA gets
On Fri, May 28, 2021 at 2:13 PM Volker Hilsheimer
wrote:
> Hey Widget fans,
>
Hola,
> I need your opinions on https://bugreports.qt.io/browse/QTBUG-59888
>
> The UX resulting from our (strange) choice to trigger selection changes on
> mouse press rather than mouse release is indeed quite
On Thu, May 20, 2021 at 11:23 AM Volker Hilsheimer
wrote:
> But the other question is who operates the service. It doesn’t matter if
> the service is Open Source if the community doesn't trust the operating
> entity.
>
Obviously, but Jason has a point. I can even give you an example:
When was
On Tue, May 4, 2021 at 3:04 PM Giuseppe D'Angelo
wrote:
> No. I'd say a qdoc bug/feature request is in order.
>
Right, I opened an issue on JIRA[1] about it, thanks.
On Tue, May 4, 2021 at 6:34 PM Topi Reiniö wrote:
> QDoc uses libclang to parse the C++ sources, and there are cases where C++
Hi,
Is qdoc supposed to mark the mentioned declarations?
I just checked the Qt 6 docs for the QFlags and it doesn't seem to indicate
either, although they are declared as such in code. Am I missing something
here?
___
Development mailing list
-Google-Smtp-Source:
ABdhPJyy5488+rwp6QTJrVNfcSedvCtkpB2ImSSZVagD6JN5bbHBNlrPSuIifeyFpNo+RDkDMSBc
X-Received: by 2002:a05:600c:ad3:: with SMTP id
c19mr1000142wmr.125.1617442547454;
Sat, 03 Apr 2021 02:35:47 -0700 (PDT)
Subject: Re: [Interest] QtQuick over Qt3D (Qt 5.15)
To: Konstantin Shegunov
On Wed, Apr 7, 2021 at 4:51 PM Giuseppe D'Angelo
wrote:
> Uhm... didn't they decide exactly against this? I might have missed the
> memo.
>
Well, apparently I did.
On Wed, Apr 7, 2021 at 5:05 PM Volker Hilsheimer
wrote:
> You didn’t miss any memo. Konstantin, I wonder (genuinely to see what
On Wed, Apr 7, 2021 at 4:20 PM Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:
> Il 07/04/21 14:56, Sze Howe Koh ha scritto:
> > Is it acceptable to remove them during Qt 6's lifetime? Or should we
> > wait till Qt 7?
>
> It's for Qt 7, I'm afraid. We're bound to an API/ABI
On Fri, Feb 21, 2020 at 10:25 AM Kai Köhne wrote:
> Hi,
>
> Another alternative is to actually use C++ attributes for this:
>
> [[qt::emit]] somethingChanged();
>
Nice idea, +1.
___
Development mailing list
Development@qt-project.org
On Tue, Feb 4, 2020 at 8:55 PM Daniel Teske wrote:
> A QObject with a parent on the stack/unique_ptr is double owned and thus a
> problem. The severity of that problem is arguably worse with a unique_ptr.
>
Which is rather typical in well structured and valid threaded code, where
the children
On Tue, Feb 4, 2020 at 12:15 PM Vitaly Fanaskov
wrote:
> I think, if we decide to re-implement parent-child model using smart
> pointers, we would not use unique pointers at all. Even in a methods
> like QObject::makeChild (because ownership is already defined). Shared +
> weak pointers make
On Thu, Jan 30, 2020 at 12:22 AM Matthew Woehlke
wrote:
> Aside from issues with Patreon's reputation
I was not aware of such, but I'm going to take your word for it.
> Besides, I was thinking more along the lines of something that could
> integrate with other OSS tools (e.g. GitHub).
>
On Wed, Jan 29, 2020 at 11:55 PM Matthew Woehlke
wrote:
> We need more open-source-meets-kickstarter...
>
ehm, Patreon?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Mon, Jan 27, 2020 at 4:36 PM Lars Knoll wrote:
> One is a change in policy regarding the LTS releases, where the LTS part
> of a release is in the future going to be restricted to commercial
> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
> into dev first.
On Fri, Jan 24, 2020 at 12:17 PM Laszlo Agocs wrote:
>
> > So it looks like there is a need to have something like Eigen in Qt, at
> least for Qt 3D purposes (faster, better optimized classes, more complete
> API).
>
> Not sure how that conclusion was drawn.
Yeah, me neither. In my view the
Hi.
On Thu, Jan 23, 2020 at 10:56 AM Jaroslaw Kobus
wrote:
> one of the tasks planned for Qt 6 is to move the math3D classes from QtGui
> to QtCore (https://bugreports.qt.io/browse/QTBUG-46653).
>
Why? My personal experience leads me to believe that the transformations
and such aren't really
On Fri, Oct 18, 2019 at 6:40 PM Thiago Macieira
wrote:
> Third option:
>
> char * const key;
Which is my style in my own projects - detaching the asterisk(s) with
whitespaces both sides. And in c++ there are types composed from
multiple tokens already, so it isn't anything original either way.
On Tue, Jun 11, 2019 at 4:04 PM Giuseppe D'Angelo
wrote:
> Well, one difference is that we don't _already_ have an implementation
> of flat (unordered) maps to be replaced by a 3rd party library, and we
> are finding lots of cases where this would be useful...
>
Fair point. We don't already
On Tue, Jun 11, 2019 at 12:03 PM Ulf Hermann wrote:
> 3) Also sort the data on copying. Then you can still share the result.
>
You mean at the point of the shallow-copy (i.e. ref-count increment)? If
so, yes, that could work too, I think.
On Tue, Jun 11, 2019 at 12:46 PM Giuseppe D'Angelo via
On Tue, Jun 11, 2019 at 11:31 AM Ulf Hermann wrote:
> I imagine that a vector which automatically sorts itself on the first
> lookup after any changes if it's larger than X items could be a drop-in
> replacement for most of the places where I misuse QHash or QMap. X could
> be a template
On Wed, Jun 5, 2019 at 9:44 PM André Pönitz wrote:
> On Tue, Jun 04, 2019 at 06:45:26PM +0200, Mutz, Marc via Development wrote:
> > 2. Delete all uses of the deprecated API from Qt itself
>
> ... and that *before* the deprecation happens.
>
> Lately the deprecations left Qt in a state that was
On Wed, Jun 5, 2019 at 12:57 AM Kevin Kofler wrote:
> IMHO, major versions with source compatibility need to actually
> live
> much LONGER, not shorter. At least 20-30 years, with the time at least
> doubling with every new major release. Or just stop doing compatibility
> breaks entirely.
>
What about shortening the major version release time, instead of changing
the whole model?
Say we keep the current model, but instead of doing a major release once in
6-7 years, we fix that to 3 years with two LTS releases - one 1.5 years in,
and then the last minor version before the major
On Mon, Jun 3, 2019 at 2:10 AM Manuel Bergler wrote:
> Why should software be different?
It shouldn't, as already pointed out. That's why well behaved libraries try
to keep compatibility in some reasonable margins.
To throw one more stone here - are you willing to backport patches from
latter
On Thu, May 23, 2019 at 12:15 PM Shawn Rutledge
wrote:
> > On 23 May 2019, at 07:51, Konstantin Shegunov
> wrote:
> > Yes, exactly like, though it'd need to regrow automatically; and on
> regrow it may need to normalize the order of elements (hence the
> "amortized”).
On Thu, May 23, 2019 at 8:12 AM Mutz, Marc via Development <
development@qt-project.org> wrote:
> On 2019-05-22 22:38, Konstantin Shegunov wrote:
> > What about a rather smart (in terms of storage) circular buffer; a
> > vector. Then the push, pop, enqueue and dequeue would
On Wed, May 22, 2019 at 11:30 PM Thiago Macieira
wrote:
> More important than the prepend (unshift) optimisation, QQueue benefits
> from
> the takeFirst (shift) optimisation. That can be added to QVector by making
> by
> moving the begin pointer.
>
What about a rather smart (in terms of
On Tue, May 21, 2019 at 11:26 AM Elvis Stansvik wrote:
> They will not show up in the web search (I think).
>
> They are however available in the debian-debug archive, see
> https://wiki.debian.org/AutomaticDebugPackages
Oh! You got me there. I was not aware of that. Thanks for pointing it
On Tue, May 21, 2019 at 11:04 AM Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:
> which ones of the following guarantee
> integrity of references, i.e., _heap allocate every single element?
>
That's a hard one. Especially since very few could keep in their brain a
list of
On Tue, May 21, 2019 at 9:34 AM Mutz, Marc via Development <
development@qt-project.org> wrote:
> [...]
> This does not make the API simple to use.
Actually it does. Simple, as "easily understood or done" and
self-explanatory, which isn't the case for the Q3Slider's constructor. Yes,
On Tue, May 21, 2019 at 9:49 AM Mutz, Marc via Development <
development@qt-project.org> wrote:
> Oh, a nullptr deref is pretty clear in a backtrace.
Indeed, but my point is that it's relatively useless for the user (or for
the developer for that matter). As you pointed out the dev sees the
On Tue, May 21, 2019 at 12:27 AM André Pönitz wrote:
> > Somehow *suggest* to the user that [s]he's supposed to build in
> > debug mode otherwise they're on their own?
>
> Nobody forces you to use Q_ASSERT.
>
Now you lost me. I don't, it was suggested as a means to prevent at-library
site
On Mon, May 20, 2019 at 11:32 PM Mutz, Marc via Development <
development@qt-project.org> wrote:
> All I'm saying is that there are tons of examples (QGradient) where the
> use of an owning container in the API is just a very bad idea and limits
> the implementor's freedom and/or performance.
On Mon, May 20, 2019 at 10:07 PM Allan Sandfeld Jensen
wrote:
> On Montag, 20. Mai 2019 20:18:32 CEST Mutz, Marc via Development wrote:
> > Where we still, maybe, disagree, is whether d == nullptr is a valid
> > state. The difference is whether member functions other then destruction
> > and
On Fri, May 17, 2019 at 8:49 AM Mutz, Marc via Development <
development@qt-project.org> wrote:
> Qt is a C++ library. If you don't like C++, either stay in QML or use
> Java. No-one uses C++ unless they need the extra performance.
>
I may or may not like where C++ is going, but that's really
On Fri, May 17, 2019 at 12:56 AM Konstantin Tokarev
wrote:
> In C++ there is a convention that ugly things should look ugly in code.
Have a reference for that convention?
> Removing element from the middle or beginning of contiguous container is
> ugly thing. If you need such operation in
>
> On Thursday, 16 May 2019 08:26:08 PDT Mutz, Marc via Development wrote:
> This one is simple: Array of struct -> struct of arrays. Well-known
> optimisation in the games industry.
>
Assuming that the data structure is simple enough and can be kept
contiguous in memory, and the view can be
On Mon, May 13, 2019 at 12:42 PM Konstantin Ritt wrote:
> Writing and proposing a patch would take less time than discussing pros
> and cons here.
>
Which I had in a minute fraction done, as a pass-by in the comments. I'm
not, however, willing to take huge technical debt on the issue by
On Mon, May 13, 2019 at 2:42 AM Christian Gagneraud
wrote:
> On Mon, 13 May 2019 at 07:47, Konstantin Shegunov
> wrote:
> > Doesn't this imply it should be dropped as an API that we can rely on?
>
> No i don't think so, this is just an edge case. I solved it by
> changin
Thanks for chiming in, I do appreciate the thoughts.
On Sun, May 12, 2019 at 1:49 PM Christian Gagneraud
wrote:
> I use to think that Qt could do a better job about FP
> precision/stability, but i had to realise that i was using Qt in a way
> that it was not designed for.
> For example, I tried
Hi,
I'd want to clear the context out of the way, so this is the bug[1] that
got me thinking.
I appreciate that we want to keep external dependencies to a minimum, and
for a good reason, but can we talk about how feasible it is to pull
something (or parts of it) in Qt, even if only internally, to
On Mon, May 6, 2019 at 10:42 AM Lars Knoll wrote:
> Not sure whether it’s most projects, but there certainly are users doing
> it. And we’ve been using the pattern in our examples in some cases as well.
> But I can relate to Allan that creating widgets on the stack is bad style
> (as it
On Fri, May 3, 2019 at 11:02 PM Иван Комиссаров wrote:
> Which should be considered bad practice and banned on an API level
>
On Fri, May 3, 2019 at 11:30 PM Иван Комиссаров wrote:
> By forcing usage of smart pointers, of course.
>
That's a joke, right? Smart pointers aren't pointers, they
On Wed, Feb 27, 2019 at 12:24 PM Joerg Bornemann
wrote:
> I'm not sure, I'm following. The non-static startDetached supports
> everything the static startDetached allowed. No functionality is going
> away, even if the static method is completely removed.
>
Right, sorry. I didn't realize that a
On Wed, Feb 27, 2019 at 9:00 AM J-P Nurmi wrote:
> Is it technically possible to start() and then detach()?
> [...]
>
This is quite important for me. I have a module that implements a
daemon/service[1] (due to QtService being old and not integrating with
windows' service manager) and I use the
On Wed, Jan 9, 2019 at 8:44 PM "André Hartmann" wrote:
> My request to syncronize both [3] lead to the conclusion, to change the
> rule,
> so that empty parameter lists should be written as
>
> [] { // lambda content }
>
If I were to vote, which I won't, I'd vote instead to make the expression
On Tue, Dec 18, 2018 at 9:39 AM Martin Smith wrote:
> I'll argue with you about it being a p1. If the problem is confined to the
> all-members list, it's not a p1 problem because the information is still
> there via the inherits links, which are more useful for seeing what is
> inherited anyway.
Not only are members missing, but links lead noplace. For example in the
mentioned page metaObject() goes to
http://doc.qt.io/qt-5.12/qwidget.html#metaObject which naturally doesn't
exist. From what I can tell nothing that is inherited, beside the things
explicitly overriden, appear in the list.
On Tue, Nov 6, 2018 at 1:07 AM Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:
> Note however that those children are deleted explicitly (via manual
> calls to delete), and NOT via the parent/child relation.
>
Noted. When I started that thread I didn't intend it to become
On Mon, Nov 5, 2018 at 11:02 PM Elvis Stansvik wrote:
> But seems to me it would be a slippery slope to accept more
> exceptions.
You say exception, but I say expected behavior, which is actually the crux
of the disagreement.
> What's next, will I have to implement the destruction
> myself
Hello,
Since we couldn't agree, I'd love to see some more opinions about this
one.[1]
Specifically:
1) Is parenting to the application object a thing?
1.a) ... and should it be allowed (i.e. accepting the proposed change)?
1.b) .. if not allowed, should we put a warning in the documentation that
I've seen that kind of argument before, so that's why I want put a comment
in here.
On Thu, Nov 1, 2018 at 12:58 PM Sascha Cunz wrote:
> I've seen lots of commercial code bases in the past where QObject
> inheriting classes are combined with QExplicitlySharedDataPointer -
> while at the same
On Tue, Oct 30, 2018 at 9:09 PM Thiago Macieira
wrote:
> On Tuesday, 30 October 2018 10:26:15 PDT Konstantin Shegunov wrote:
> > From my point of view qbs is doomed as long as qmake's alive. Either kill
> > qmake and force the developers using Qt (or developing Qt) to use
On Tue, Oct 30, 2018 at 6:41 PM Oswald Buddenhagen
wrote:
> On Mon, Oct 29, 2018 at 12:17:04PM +, Lars Knoll wrote:
> > and investment in promoting it towards the larger C++ ecosystem as a
> > new build tool.
> >
> nonsense.
> all the promotion qbs would need is being used to build qt.
>
On Sun, Oct 28, 2018 at 9:51 PM Thiago Macieira
wrote:
> I'm pretty sure their company HR would want to have a chat anyway.
>
Well, I'm not as sure as you, but I am hopeful.
> That's also a good reason to choose the KDE CoC, as both TQtC and KDAB
> recruit
> heavily from the KDE community and
On Sun, Oct 28, 2018 at 2:08 PM Martin Smith wrote:
> No, it isn't a resolution. Not reacting to a complaint is no resolution.
Given the (current) structure of the community I take that as the offence
not carrying merit.
But even if "the community" does react to the alleged offense, how is
On Sun, Oct 28, 2018 at 10:43 AM Martin Smith wrote:
> >Oh, it is going to end in A resolution, it may not end the way the
> offended party
> >may feel just, but that's true also for the proposed text.
>
> HA! You are not Konstantin Shegunov! A software engineer would imedi
On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira
wrote:
> The answer to all of those questions needs to be "yes". Anything short of
> that
> means the CoC is powerless and just for show.
>
Which was my point exactly.
> Whether there's a termination of employment or not is out of scope, since
On Sat, Oct 27, 2018 at 4:56 PM Martin Smith wrote:
> You just specified a code of conduct. The problem with your code of
> conduct is that it isn't guaranteed to end in resolution.
>
Oh, it is going to end in A resolution, it may not end the way the offended
party may feel just, but that's
On Sat, Oct 27, 2018 at 4:09 PM Martin Smith wrote:
> In that case, if a contributor is mistreated by another contributor, what
> recourse does the victim have?
>
1) To contact the contributor first and try to resolve the issue civilly.
2) To seek help with a third party (another contributor)
+1 for the KDE CoC from me as well.
Better written, clearer and to the point.
On Thu, Oct 25, 2018 at 8:40 PM André Pönitz wrote:
> On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development
> wrote:
> > We do have a Code of Conduct at KDE for about 10 years now, and this
> hasn't
On Thu, Oct 25, 2018 at 1:01 PM Lorn Potter wrote:
> Those do not mean the same as 'empathy', which is the "ability to
> understand and share the feelings of another", or "put yourself in the
> other persons shoes"
>
> I think empathy is a fine word for this, there is nothing vague about it.
>
I think you're over-engineering the whole thing and you don't drive the
point of such a document home. My best suggestion is to simplify (heavily)
the process and the phrasing.
Firstly and most importantly drop the heavy and redundant wording, e.g. "
... pledge to making participation in our
On Wed, Oct 10, 2018 at 8:43 PM Tomasz Siekierda wrote:
> Hi,
> I'm on Kubuntu 18.10. I've made sure the ssh pub key on gerrit is
> correct. And I've used init-repository script to get going.
>
Hi,
Ran into this a few months ago. Force the cipher through the ssh config and
you should get it
Hi Denis,
On Sun, Sep 2, 2018 at 9:34 AM, Denis Shienkov
wrote:
>
> Could someone help me please?
>
I've run into problems on Debian testing recently and it appears to have
been the same problem as you're having. Perhaps you could try something
like this:
GIT_SSH_COMMAND="ssh -c aes256-cbc"
On Tue, Jul 31, 2018 at 2:43 PM, Kai Koehne wrote:
> Hi,
>
> I'm wondering how we can avoid symbol clashes in static Qt libs + user
> code.
>
> a) Prefix all symbols with 'q', like we do for exported symbols.
>
> This requires some bigger patches. See e.g. https://codereview.qt-project.
>
76 matches
Mail list logo
