se, the sources won't be removed. One can always rebuild the binaries
if needed.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development
I trust that he will make a
> good approver for the Qt project.
+1
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
h
n't test C++20 mode with 2019 for a day or so, and some changes that
trigger 2019's broken C++20 support went in. If we don't drop 2019 by 6.8
release, we should force it to only compile in C++17 mode.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer -
that, I'm
ok. As you can still access by casting to a base, that had better be a good
reason.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Develop
On Friday, 15 March 2024 11:03:19 PDT Thiago Macieira wrote:
> On Friday, 15 March 2024 10:09:31 PDT Marc Mutz via Development wrote:
> > I like simple rules. "Overrides should have the same access level as the
> > initial virtual function." is a simple rule.
>
> Am
On Thursday, 28 March 2024 01:06:37 PDT Björn Strömberg wrote:
> example on spectrum on the support on modules: [unmaintained, deprecated,
> life-support, full-maintenance, feature-development]
The .gitmodules file for qt5.git is that.
--
Thiago Macieira - thiago.macieira (AT) int
h the next
Qt minor release and include in the next release set.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-
ve
absolutely no clue on reviewing XCB stuff, but I had to click every link to
make sure none of them was a QtCore issue I might have missed.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signat
d then asking this list. Don't wait months and years: you're
entitled to getting a review within one month. The worst that can happen are
that someone decides to make a permanent rejection because they can't justify
accepting.
--
Thiago Macieira - thiago.macieira (AT) intel.com
a non-GUI environment. A
class called QDesktopServices is really just about GUI desktops. Further,
QPlatformIntegration *IS* QPA. You can't move that class to QtCore.
I suggest having a background hook that QPA registers with QtCore so that
QtNetwork can use to launch the browser if QP
ms and promised not to do it again.
So QDesktopServices can't be moved. You can add a new class to QtCore.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development m
For QDesktopServices, at least there is no
object and therefore no one is expecting to have functions with it as part of
the mangled name.
Those two platforms are:
- Darwin (macOS, iOS, etc.)
- Windows
So not insignificant. And moreover, the two platforms where no one EVER runs
without a G
rate from QDesktopServices when
we already have that and cannot remove it until Qt 7. And I'd like an argument
why the API should be in QtCore, as opposed to QtNetwork (it's a browser after
all).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Cloud
sign an API now that will work with intents/activities.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.o
al argument.
Not necessarily. We can have a private hook like the one you implemented, such
that the dependency isn't there. My request was about front-end API.
> The logical argument is that a) QUrl itself and b) QMimeTypeDatabase,
> which co-determines which program to run on openUrl(
io/cgit/qt/qtbase.git/tree/src/widgets/widgets/qtoolbutton.h?
h=v5.15.13-lts-lgpl
Therefore, your issue is that you've compiled something against the Qt 6
headers.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Cloud Engineering
smime.p7s
Descrip
On Tuesday 7 May 2024 10:03:21 GMT-7 Thiago Macieira wrote:
> So I want to know of a use-case where all of the following are true:
> * application is GUI-less (i.e., is a background service)
> * application has no GUI counterpart
> * application is definitely running in a GUI
he non-UI component
doesn't want to use QCoreDesktopServices::openUrl in the first place: it wants
to communicate with its UI component through whichever communication mechanism
it has established.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Cloud
: your headers don't match the library you have. You have to match.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
of success.
That assumes we will have something. I am not convinced yet that any
application exists where the three conditions I mentioned in another email are
met.
And besides, you've just said that the replacement may have a different API.
That implies we haven't finished design
allowing
whichever reply this is to come from that separate thread.
The above isn't cmptest. It's tst_qsettings. But you can see other tests
having the same problem too, like tst_qguichronotimer.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet
I don't understand how
> as the CI doesn't print the relevant gtk frames in the trace to examine
> its code.
Please confirm that your changes require that you reply to something requested
from other applications. If so, make sure you can reply from the XCB event
thread.
--
Thiago Ma
and it hangs... But I'm unable to
> reproduce that myself to debug.
Maybe the issue is something that you've stopped doing because you're now
doing this.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Engineering and Quality
smime
and detect
whether our dispatcher is QXcbGlibEventDispatcher. If it is, then don't use
the new feature.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Engineering and Quality
smime.p7s
Description: S/MIME cryptographic signature
--
Development ma
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
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 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: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 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
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
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
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
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.
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
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
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
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 -
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
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
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
.
>
> (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
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.
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 -
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
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
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
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
'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: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
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
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
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
--
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
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 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
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
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
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
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
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 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
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 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 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&
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
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
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
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
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
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
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 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
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 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
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
Linux distributions may
update soon to this version of PCRE, Mac OS X isn't likely to get a new
version until 10.8 in 2013 and Windows users will never have it.
At the same time, we need configure to support -system-pcre, with the
appropriate checks for the UTF-16 API.
--
Thiago Macieira -
On Monday, 12 de December de 2011 19.34.21, Thiago Macieira wrote:
> On Monday, 12 de December de 2011 18.03.53, aaron.kenn...@nokia.com wrote:
> > > $ git reset --hard d28b6a024826aaa48a8b3e69c096d01c91aff2c9
> > > Checking out files: 100% (894/894), done.
> > > HEAD
;
esac
That means the V8 snapshot is permitted in cross-compiling only when the host
is 32-bit i386.
How does one build Qt in cross-compilation mode these days?
I'm perfectly happy to stop testing ARM at all...
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architec
They don't look like they are thread-safe, at least not the qInitDrawHelperAsm
function.
Is that function supposed to be thread-safe?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 5
lication-
processors/armada-600/assets/armada610_pb.pdf
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
De
andy Bridge laptop.
I'd also like to compare the previous SSE2 to the current SSE2 code.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista
On Friday, 30 de December de 2011 12.35.44, Thiago Macieira wrote:
> I have an ARM and a MIPS cross-compilation builds. My host machine is a
> 64-bit x86-64. Configure was run with no flags related to V8.
>
> It told me:
> V8 module .. yes
>
> mkspecs/qconfig.pri
ndering if no developer is cross-compiling on their own
machines.
By the way, do we have 64-bit builds running?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnä
eans startup penalty for v8, but no functional
> regression.
Please make sure it's documented that, if you're building for ARM and you're
on a 64-bit machine, you should use -platform linux-g++-32 to get most
performance.
--
Thiago Macieira - thiago.macieira (AT) intel.com
S
n keeping track of
windows that are not in your process should be similar.
[1] https://bugs.kde.org/show_bug.cgi?id)0316
[2] https://bugs.kde.org/show_bug.cgi?id)0317
[3] https://bugs.kde.org/show_bug.cgi?id)0363
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source
t changing QCoreApplication's
API -- a new class would be better.
You may also want to investigate how this would integrate with a concept like
Android's "wakelock", which is a way for applications to tell the kernel that
an on-going job is happening and the CPU should not com
On Monday, 2 de January de 2012 06.38.17, gunnar.sle...@nokia.com wrote:
> On Dec 30, 2011, at 6:34 PM, ext Thiago Macieira wrote:
> > They don't look like they are thread-safe, at least not the
> > qInitDrawHelperAsm function.
> >
> > Is that function suppo
Here's how my work currently stands:
On Thursday, 29 de December de 2011 17.00.09, Thiago Macieira wrote:
> 1) Drop the MMX code and the 3dNow! extensions now
Done. Also dropped the detection mechanism in qsimd.cpp, configure and
configure.exe. I also updated the macros to be simpler to
-less API (such as KJob)
It's simpler to expose the data pointer in QList and let users manage pointers
on their own. It's more efficient, since there's no man-in-the-middle.
Yet that's no good reason to expose the internal implementation details as the
front-end API.
--
Thiago Mac
imple API in QtCore, if you guys can propose a
good API, but I will definitely not agree to it being ref() and deref() in
QCoreApplication.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 5
On Monday, 2 de January de 2012 14.39.40, Stephen Kelly wrote:
> On Monday, January 02, 2012 10:51:31 Thiago Macieira wrote:
> > > Does the manager keep track of its delegates?
> >
> > Good question. I guess it would depend on the windowing system, if we have
> > a
On Monday, 2 de January de 2012 11.10.57, Thiago Macieira wrote:
> The code is compiling fine with GCC on x86, x86-64; ICC on x86-64 and I have
> a linker error on ARM with Neon.
make clean solved the linker error. All my working configurations now build the
code:
gcc x86-64 64-bit -march
On Monday, 2 de January de 2012 16.47.50, Stephen Kelly wrote:
> If wake locks are as simple as you describe though, it sounds like
> something similar would work just fine.
That might be. I was actually hoping you'd spend an hour to investigate what
it takes.
--
Thia
On Monday, 2 de January de 2012 13.14.28, Thiago Macieira wrote:
> I will proceed to merging qblendfunctions and qmemfunctions into the draw
> helpers.
Done with the blend functions, including the removal of the big 16x16 tables
of scaling, transforming and blending functions. The d
of a moot point. I don't think GnuTLS
> is in the LSB, but the LSB navigator site is currently down so I can't
> easily check.
I remember voicing my concerns about NSS when LSB decided to standardise on
it. The reason was then that Qt could *not* use NSS, since it was developed i
On Tuesday, 3 de January de 2012 11.31.17, craig.sc...@csiro.au wrote:
> On 03/01/2012, at 11:27 AM, Thiago Macieira wrote:
> > On Tuesday, 3 de January de 2012 10.57.11, craig.sc...@csiro.au wrote:
> >> Unfortunately, OpenSSL is not part of the LSB, so if you want SSL support
n't need to
keep even the QHttpResponseHeader class.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This
; be able to redefine it to use both Qt namespace and my modules'
> namespace.
I suggest you use your namespace at the end of your .cpp file and #include the
moc output. This improves the compilation time, makes better code and reduces
the need for weird changes in moc.
--
Thiago Macieira -
coded somewhere else or is
> there already a general solution in place (too much New Year's optimism)?
My guess is people cross-compiling won't build qttools in the first place.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology
701 - 800 of 6728 matches
Mail list logo
