cally register an enum with the meta-type
> system (so that QMetaEnum.metaType().isValid() returns true)?
Sure. And registration is automatic anyway.
All you should need to do is pass the necessary QMetaType
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI
he metatype of properties and methods
Additionally Metatypes for enums and properties are mandatory too. For
methods, they are allowed to be nullptr.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIM
to the meta-object. It would
> be nice to be able to register an enum with the meta-type system
> dynamically.
Or you can set the EnumOrFlag flag in the QMetaProperty flags field to force
the
constructor to search.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer -
he release is near.
The feature system is not guaranteed to work. If you use *any* -no-feature
option, you assume responsibility for submitting build fixes. This task didn't
get assigned to me, but if it had been, I'd have closed it with that.
--
Thiago Macieira - thiago.macieir
On Tuesday 1 October 2024 07:53:13 GMT-7 Thiago Macieira wrote:
> Update: this is a real regression. However, meta objects for private classes
> weren't working properly before either, so this only changed what fails.
>
> Tracking in https://bugreports.qt.io/browse/QTBUG-129570
On Tuesday 1 October 2024 07:53:13 GMT-7 Thiago Macieira wrote:
> Update: this is a real regression. However, meta objects for private classes
> weren't working properly before either, so this only changed what fails.
>
> Tracking in https://bugreports.qt.io/browse/QTBUG-129570
On Monday 30 September 2024 15:22:48 GMT-7 Thiago Macieira wrote:
> 2) Jøger reports that VS is failing to compile the meta object of a private
> class. I think that's a compiler bug, because there is an equivalent test in
> tst_Moc and that compiles. I can't reproduce the is
On Thursday 12 September 2024 06:59:55 GMT-7 Thiago Macieira wrote:
> > +1 for that! That's one of the things that we pay attention to during API
> > review in Qt, so hopefully all new Qt APIs will either use `enum class`,
> > or explicitly define an underlying type.
>
t a git show of this commit shows the annotation:
Notes (cherry-picks):
6.7: 8dd7aba7fd2e6edeee33e97879f7e891028bad7d
And that commit is name-rev'ed to tags/v6.7.0-rc1~141.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
a76dec51de48af99132b91 (which is dated over 3 months before
the first public commit) and Marius S-O wrote:
Add hardcoded qclass_lib_map.h based on 4.8
This is only until UIC/Designer handles this properly
Permanent temporary...
--
Thiago Macieira - thiago.macieira (AT) intel.com
er we have to write
the keyword or not).
That said, the inline keyword can be omitted for functions, so moving it to
the right where we usually won't try to grep makes some sense.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System
On Thursday 19 September 2024 08:07:19 GMT-7 Thiago Macieira wrote:
> On Thursday 19 September 2024 01:11:54 GMT-7 Halla Rempt wrote:
> > Who knows whether anyone is using it? There are zillions of projects using
> > Qt out in the world, but the people developing Qt keep assuming
submitting to useless clean-ups that nobody
> seems to have thought were an imposition. I've been through Qt1..2..3..4..5
> and now going through 6.
And the reports we've had is that however painful this transition is, it's the
least painful of all.
--
Thiago Macie
> also inline.
Yeah, but by the same token you could be searching for static inline, of which
we have far more in our sources.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographi
to adopt.
Arthur doesn't conclude very well whether constinit comes all the way first
(because it modifies how the initialisation happens) versus being placed where
constexpr would be.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & S
> Whether inline or constexpr comes first has none, IMNSHO.
I'm thinking of new code and how we usually write code. We don't enforce the
static inline / inline static, for example, but most people write the former.
I'm just wondering which one we prefer.
--
Thiago Mac
erefore, our constexpr variables should be explicitly inline too, to avoid
those problems. The question is only the order in which we spell those two
keywords out.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
p 'static constexpr inline' \* '!*/3rdparty/*' | wc -l
57
$ git sgrep 'static inline constexpr' \* '!*/3rdparty/*' | wc -l
53
$ git sgrep 'inline static constexpr' \* '!*/3rdparty/*' | wc -l
16
$ git sgrep 'inline constexpr stat
ttps://codereview.qt-project.org/c/qt/qtbase/+/586454:
QMetaMethod: make some QByteArray-returning methods slightly faster
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signatur
On Tuesday 10 September 2024 10:33:32 GMT-7 Thiago Macieira wrote:
> Is this supported? I didn't know about it until yesterday. I doubt anyone is
> using it, though it's possible some code carried over from Qt 3 was left
> unmodified like that.
QGroupBox:
Q_PROPERTY(Qt::
On Tuesday 10 September 2024 10:12:10 GMT-7 Andreas Aardal Hanssen wrote:
> Tir 10 sep 2024 kl. 18:55 skrev Thiago Macieira:
> > Any objections?
>
> Please don’t break source compatibility?
It does appear that a Q_PROPERTY of a Q_FLAG whose getter and setter operate
on integers
On Tuesday 10 September 2024 09:55:24 GMT-7 Thiago Macieira wrote:
> 1) I will fix moc to *not* manipulate int for property enum types, which
> means it will not use QFlag at all
https://codereview.qt-project.org/c/qt/qtbase/+/589897
If we need to keep compatibility with integer gette
if'ed on sizeof(QFlags) == sizeof(int)
4) I will not mark them or QFlag as deprecated
Any objections?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development
On Tuesday 10 September 2024 04:56:40 GMT-7 Thiago Macieira wrote:
> In Qt 3, QVariant could only contain a closed set of types, so QObject::
> QObject::setProperty would only be able to write QFlags if the QVariant
> contained an int, and QMetaProperty already had isEnumType() at
in type compared
to the norm.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
) = _t->flags(); break;
case 2: _t->setFlags(*reinterpret_cast< Qt::WindowFlags*>(_v)); break;
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development m
ommit did not include any changes to moc, tst_moc or testlib.
But there is one change in COIN itself relating to the windows minimal-static
build, which was the update from MSVC 2019 to 2022.
I also see more than one qt5 integration passing earlier today.
--
Thiago Macieira - thiago.macieira (
> nothing to do with C++26/29 contacts.
And this proprietary solution of ours could be made so it throws for user-
compiled inline code, but not for the same inline functions compiled inside
the Qt libraries. In this case, I agree it can be done.
--
Thiago Macieira - thiago.macieira (A
in a bad state.
Either way, it doesn't change our conclusion. Throwing on precondition
violation is a useful tool for unit-testing some APIs and we want to have
that, but using it in production code is dangerous because it's untested. Use
at your own peril.
--
Thiago Macieira - thiago.ma
proper correction code for it.
>
> I have that "correction code".
Sure, but "bugs happen". I am arguing that putting the contract checker into
exception mode expands the blast radius of when those bugs do occur.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal
ure/promise doesn't know how many results will be provided, so there's
a race condition in it flagging the future has arrived with more results
arriving.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smim
tst_QList can test its
operator[], but tst_QObject shouldn't.
I don't think we'll prohibit this. But it will be a gun and there's your foot
over there...
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Enginee
time
choice (as Marc says, decided by the owner of main()), we'll need to be very
clear we do not support it and do not recommend it.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
work. I'll even review the patches and
provide feedback. But I don't think it's a good use of our time, especially
when we call out to non-Qt code that isn't exception- or even unwind-safe
(q.v. the crashes on macOS on ARM64).
--
Thiago Macieira - thiago.macieira (A
On Saturday 31 August 2024 08:26:06 GMT-7 Thiago Macieira wrote:
> You can now choose: 64-bit QFlags or MSVC 2019. I don't think it's worth
> keeping compatibility with the old moc way of doing things for a now 5-year-
> old compiler. More to the point, I refuse to do the work
On Saturday 3 February 2024 09:08:25 GMT-7 Thiago Macieira wrote:
> The compiler is pretty buggy and has several, unfixed conformance issues
> with C++.
>
> One year ago I asked on the interest mailing list about using a non-latest
> MSVC:
> https://lists.qt-project.org/piper
exception may be generated
anyway. Because that noexcept expression is currently noexcept(true) for all
major Standard Libraries whose headers I can see, there is no behaviour change
and no incompatibility.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Plat
of restricting to performance-critical code. Either we
use the macro everywhere where we apply a noexcept where preconditions exist,
or we don't.
Said macro should be tied to the precondition itself, if we can. I haven't
looked at the syntax: can one macro in one location expand to precond
On Thursday 29 August 2024 13:33:55 GMT-7 Marc Mutz via Development wrote:
> On 29.08.24 17:31, Thiago Macieira wrote:
> > What I'd like to change is:
> > - for inline code, where the function's noexceptness is likely to be used
> > in a>
> > noexcept exp
knows* whether something threw or not.
Examples are QStringView::sliced() or the QCborStreamReader members.
What I'd like to change is:
- for inline code, where the function's noexceptness is likely to be used in a
noexcept expression elsewhere and that causes slower code to be used
-
checked
preconditions that may throw, we copy their solution and apply the same.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Developm
ting
each element in case the *comparison* throws, even if the element copy/move is
noexcept.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Tuesday 27 August 2024 10:29:05 GMT-7 Ville Voutilainen wrote:
> On Tue, 27 Aug 2024 at 17:15, Thiago Macieira
wrote:
> > The point is that this putative mistake has no consequences, today. It
> > remains to be seen whether it will with contracts, when those come. When
> &g
so doesn't operator[].
>
> We can decide otherwise -- and that's orthogonal to if and when
> contracts actually land, as Marc says.
Can we decide otherwise? Doesn't the underlying Standard C++ library
implementation's choice make the same choice for us?
--
Thiago Macie
n whether it will with contracts, when those come. When contracts
come, if those noexcept are a problem, then both libc++ and libstdc++ will
deploy a solution, which should suffice for us too. Until then, I don't see a
reason to deprive ourselves of any potential benefits that the noexce
ould allow having one set remaining in a
build type and not the other too. But it might be confusing to teach our own
developers.
I don't remember what the issue with Q_ASSUME was any more. As we failed to
reach an agreement, there was no point in retaining any knowledge about why. I
just
(which it
may if it has a precondition).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
those noexcepts?
And where does it end? Do any pointer dereferences imply a precondition and
thus not-noexcept?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
ector::operator[]. Are you
proposing that it a) become non-noexcept, b) have its UB not defined by the
boundary of the precondition, or c) have a precondition that cannot be turned
into an exception?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Monday 26 August 2024 13:12:55 GMT-7 Thiago Macieira wrote:
> "Q_ASSERT don't affect noexceptness"
>
> Or
>
> "noexcept(false) if you call other, noexcept(false) functions from your
> code", which includes all the pthread cancellation points in gli
On Monday 26 August 2024 13:12:55 GMT-7 Thiago Macieira wrote:
> "Q_ASSERT don't affect noexceptness"
>
> Or
>
> "noexcept(false) if you call other, noexcept(false) functions from your
> code", which includes all the pthread cancellation points in gli
hat happens to parameters that have non-noexcept destructors?
We have both callee-destroys and caller-destroys systems.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signatu
On Monday 26 August 2024 15:47:10 GMT-7 Ville Voutilainen wrote:
> On Mon, 26 Aug 2024 at 22:29, Giuseppe D'Angelo via Development
>
> wrote:
> > Il 26/08/24 19:56, Thiago Macieira ha scritto:
> > > I'd like to request Qt code not obey that rule. In my o
On Monday 26 August 2024 13:12:55 GMT-7 Thiago Macieira wrote:
> "Q_ASSERT don't affect noexceptness"
>
> Or
>
> "noexcept(false) if you call other, noexcept(false) functions from your
> code", which includes all the pthread cancellation points in gli
uggy implementation or
corrupted memory. Neither of which you can recover from with C++ code.
[This code isn't noexcept because QUuid::fromRfc4122 wasn't noexcept when it
was written]
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform &am
as compiled without exception support.
So I am asking that we be pragmatic and cater for the needs we have, not the
hypothetical needs that have not yet materialised in 15 years.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Enginee
rithm, and so on).
Then let's go for it: a clazy warning.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project
On Monday 26 August 2024 12:27:47 GMT-7 Giuseppe D'Angelo via Development
wrote:
> Il 26/08/24 19:56, Thiago Macieira ha scritto:
>
> > I'd like to request Qt code not obey that rule. In my opinion, it's a
> > defect
in the contract implementation rather than on
rue before the method is called and
therefore the method's own noexcept specification does not apply *yet*.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Devel
destructor.
A compile-time warning implies having a way to disable it with "I know that,
just ignore it" which is maintenance for us. My problem with this is the cost
on us, to maintain such a thing that has never been a problem and likely never
will.
--
Thiago Macieira - thia
On Monday 19 August 2024 15:59:15 GMT-7 Thiago Macieira wrote:
> I replaced the use of std::array with plain arrays. It's now passed with a
> full precheck, even on INTEGRITY. Please review the series.
GHS compiler bug:
"/home/qt/work/qt/qtbase/src/corelib/kernel/qtmochelpers.h&
On Sunday 18 August 2024 09:07:27 GMT-7 Thiago Macieira wrote:
> On Saturday 17 August 2024 22:13:44 GMT-7 Thiago Macieira wrote:
> > I'm running it through the CI now to see if there's anything I
> > missed and if QNX and INTEGRITY will join us or if they will keep t
On Saturday 17 August 2024 22:13:44 GMT-7 Thiago Macieira wrote:
> I'm running it through the CI now to see if there's anything I
> missed and if QNX and INTEGRITY will join us or if they will keep the old
> moc- generated content. I will not spend any time at all trying to
&g
On Sunday 11 August 2024 10:31:06 GMT-7 Thiago Macieira wrote:
> It might be possible to consult the string array and avoid having to have
> string indices all over the place. This will require some more testing,
> especially with the QtOpcUA::NodeIds massive listing.
>
> I may
cases, to silence the tidy tool, you should cast
the signed type to the unsigned equivalent and not use intcmp().
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
On Friday 9 August 2024 13:26:12 GMT-7 Thiago Macieira wrote:
> I've thrown it at the CI to check more:
> https://codereview.qt-project.org/c/qt/qtbase/+/582313
Making lots of modifications but it seems to be working. I've also managed to
also calculate the metatype array a
autogen/include/moc_qtpropertymanager.cpp
2844668 ./qtopcua/src/opcua/OpcUa_autogen/include/moc_qopcuanodeids.cpp
QOpcUa::NodeIds contains a single enum with 16162 entries. I'll need to test
that too. The other ones are not big meta objects; the files are big because
there are multiple classes in
f another bit extracted into the QMTI, and impact everyone else's
runtime to check that bit and warn or reject. We'd probably not do the runtime
checking at all, because of the side effect and because the construction of the
user code as above could mean the developer never sees the pro
very cumbersome anyway. I
think I have a better solution anyway.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.or
On Thursday 8 August 2024 11:22:39 GMT-7 Thiago Macieira wrote:
> My solution is to have moc parse a new declaration Q_DECLARE_FLAGS64, which
> indicates the flag is 64-bit, and then generate different data. I have not
> implemented Q_FLAGS64 or Q_ENUM64 yet.
An alternative solution I a
r we can have moc generate the same
content for both macros, regardless of class.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-p
On Tuesday 9 July 2024 03:33:16 GMT-7 Marc Mutz via Development wrote:
> We should really try to fix this before 6.8.0 (LTS).
I won't have time for QDataStream and especially QTextStream & QDebug, which
are required for QMetaType.
--
Thiago Macieira - thiago.macieira (AT) intel.com
27;s not a problem that needs solving.
We already enforce in QCoreApplication where it matters: the setlocale() call.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Systems Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
users, how to market the versions, and
whether it is worth the hassle are completely separate topics.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Systems Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing
Either
way it's a choice and choices can be revisited.
Saying that C++20 code is cleaner (corollary: C++17 code requires typing more
or has worse performance) is a feature, not a bug.
Anyway, I am convinced and will review your patches, next week.
--
Thiago Macieira - thiago.macieira (AT) i
On Tuesday 11 June 2024 12:44:11 GMT-7 Marc Mutz via Development wrote:
> On 11.06.24 21:08, Giuseppe D'Angelo via Development wrote:
> > Il 11/06/24 07:12, Thiago Macieira ha scritto:
> [...]
>
> > > I'd like to know how much breakage this solution or mine w
'd warn them by making the code fail to compile if they used it
wrongly in the first place.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Systems Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing
On Tuesday 11 June 2024 12:08:45 GMT-7 Giuseppe D'Angelo via Development
wrote:
> Il 11/06/24 07:12, Thiago Macieira ha scritto:
> > I'm arguing that such code is likely already broken (producing mojibake)
> > for
> > non-US-ASCII content, so having U+FFFD inste
On Tuesday 11 June 2024 12:09:17 GMT-7 Giuseppe D'Angelo via Development
wrote:
> And it's not 2. 🏴 is 7 code points.
And that requires 4 code units (bytes) per code point in UTF-8, for a total of
28 bytes.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Princ
t was a lot of work
> to get there).
We're talking 6.9 at this point.
I'd like to know how much breakage this solution or mine would imply.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Systems Engineering
smime.p7s
Description: S/MIME
nt encodings probably
already has bugs.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Systems Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
highly-specialised conversion
code because this is critical to us and I'd like to see it used. So how do we
ensure that in those contexts we use our code, which is not and cannot be
inline?
How do we format onto a QString?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer -
it's what fmtlib did, so no one has looked into that".
We have and we need it. We also would like to have the ability to allocate
buffer in the output, write to it, and only then let the output know how much
we've written. I could not find a way to do that with std::formatter.
.
>
> (Not to mention formatting _into_ char16_t, which would unlock something
> like QString::format to *create* a QString!)
Yup, I think we need to engage SG16 before continuing with this. We need
char16_t to be enabled on the generic formatters, for one thing.
It might be tha
on Windows until UTF-8 is deployed
there. Which means we can assume terminals are always UTF-8 too.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Engineering and Quality
smime.p7s
Description: S/MIME cryptographic signature
--
Development m
n't trust the binaries you
download from download.qt.io except for development: for your releases, you
should build Qt from source.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Engineering and Quality
smime.p7s
Description: S/MIME cryptographic si
ted to retain compatibility with the negligible amount of
Qt 6 software that existed before the option was introduced. But now they're
locked into it for the duration of Qt 6.x.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Engineering and Quality
sm
and our users' more difficult in
another.
> Does this sound good?
Yes.
For me, there's no such thing as LTS anyway, so I don't care about anything
6.5 beyond 6.5.3. This policy doesn't affect *me*.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer -
if someone does check that you can throw through Cocoa frames, then it
would be worth having the unwind info, if nothing else to support the case of
"emergency save in main()".
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Engineering and Qua
Which then might ideally be something we support in the
> build system through a toggle.
That definitely needs fixing. At a minimum, the #recovering-from-exceptions
section is wrong, because we know the exception can't propagate through the
event loop.
The #signals-and-slots section is wha
at all event handlers and all slot invocations as noexcept and
catch your own exceptions before they go back to Qt code. This is the reason
why we decided it was ok to disable exceptions in QtWidgets itself, because we
didn't think we could guarantee survivability in the first place.
--
Th
it's entirely possible that GDK isn't getting the reply it needs because
that reply was sent to our Display and connection and thus handled by our
thread.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Engineering and Quality
smime.
y to the XInternAtom didn't arrive. You need to deduce
a reason why the X server would fail to send that.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Engineering and Quality
smime.p7s
Description: S/MIME cryptographic signature
--
Develop
hether the Gtk3 theme is loaded (which means GDK is in
use in the main thread) and don't use your new technique.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Engineering and Quality
smime.p7s
Description: S/MIME cryptographic signature
--
Dev
but the patch
doesn't apply in Qt 6. So things fail there, with positions for sub-menus or
windows not to correct.
Beyond that, both for kwin- and plasmashell-provided components (titlebar,
status bar), the icons were wrong because they were not scaled up. I think
those two overri
On Tuesday 14 May 2024 13:24:12 GMT-7 Ilya Fedin wrote:
> On Tue, 14 May 2024 12:59:29 -0700
>
> Thiago Macieira wrote:
> > Assuming that Canonical did not patch libgdk,
>
> Well, that is a very optimistic assumption:
> http://archive.ubuntu.com/ubuntu/pool/main/g
On Tuesday 14 May 2024 12:30:42 GMT-7 Thiago Macieira wrote:
> Those may be inlines. If I try addr2line, then the frames are:
Using gdb instead of addr2line:
frame 6:
Line 116 of "x11/../../../../../gdk/x11/gdkproperty-x11.c" starts at address
0x773d8
and ends at 0x773eb .
On Tuesday 14 May 2024 12:30:42 GMT-7 Thiago Macieira wrote:
> Those may be inlines. If I try addr2line, then the frames are:
> gdk_x11_atom_to_xatom_for_display at ??:?
> gdk_x11_lookup_xdisplay at ??:?
> gdk_x11_display_broadcast_startup_message at ??:?
> gdk_x11_drag_cont
On Tuesday 14 May 2024 12:13:29 GMT-7 Thiago Macieira wrote:
> #6 0x7fe3fc6e93d8 in gdk_x11_atom_to_xatom_for_display () at
> /lib/x86_64- linux-gnu/libgdk-3.so.0
773d3: e8 58 7f fb ff call 2f330
773d8: 4c 89 e6mov%r12,%rsi
That woul
On Tuesday 14 May 2024 11:44:24 GMT-7 Thiago Macieira wrote:
> Think in terms of side-effects. It doesn't care how Qt does it, but the
> side- effect of what we are doing could be important, since we're sharing
> libxcb internal state, the xcb_connection (I think), and the
1 - 100 of 3495 matches
Mail list logo
