those I listed. Let's not do it again without
strong reason.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
r comes out with the feature, we may get compilation errors.
Our users understand that we cannot test things that don't exist, so older
versions can fail to compile on new compilers (or produce a lot of warnings).
Issuing fixes is enough.
--
Thiago Macieira - thiago.macieira (AT)
; So, is the CI just using a totally outdated toolchain?
More than likely we're just missing an -l flag or equivalent to link to the
necessary implementation. If that's the case, it's no different than libstdc++
which requires adding -lpthread to your link command-line.
--
Th
eems like it. Like I said, we've never required the C++11 standard library
and we need to be sure the feature we need is supported before we commit to
it.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
__
7;
> > from where it is then went in Qt 5.13.0 and future releases
> If you want to see where the patch is currently available just click on
> the review ( https://codereview.qt-project.org/c/qt/qtbase/+/259142 )
> and then on 'Included In'.
There's a bot now that
rds in C++14 and C++17
so they got new numbers (I think the "relaxed constexpr" is one such). But you
should know you're targetting that particular feature and thus that it had a
different number than the baseline.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Ar
On Thursday, 19 September 2019 06:23:26 PDT Giuseppe D'Angelo via Development
wrote:
> On 18/09/2019 01:37, Thiago Macieira wrote:
> > Marc's proposal is that we should accept that these things are rare and
> > simply correct when they do happen. Since our code is test
rom dropping features or an entire
platform.
Still, it's a decision we can make. I'm not opposed to it, as I have been
bitten by Integrity's compiler shortcomings before (see QRandomGenerator's
integration log). But it's a *decision* to *change* our policy.
--
T
ied for
performance and shortcomings and we can even submit fixes if we feel like it.
EXCEPT for Integrity.
[*] Note the blog author's initials :-)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
__
On Thursday, 19 September 2019 03:17:12 PDT Giuseppe D'Angelo via Development
wrote:
> On 18/09/2019 17:33, Thiago Macieira wrote:
> >>> We've never required C++11 Standard Library. We've only required the
> >>> core
> >>> languag
that allow us to quickly get all the output from those classes and see if
there's something unexpected, compared to other tools and system
configuration.
Ditto for highdpi.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Sys
hat function above? Assume there's less than 0.1% of them doing that.
Anyway, what's the correct way to specify now that one of my external monitors
is highdpi but the other isn't?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect
tion
for X11 then: continue using the variables as they are.
> If possible, I’d like us to move away from relying on setting environment
> variables, and/or switch to specifying per-screen DPI instead of a scale
> factor.
Sure, but where, on X11?
--
Thiago Macieira
On Wednesday, 25 September 2019 11:08:39 PDT Elvis Stansvik wrote:
> Large parts of the world did not grow up with inches. I know I'd have
> a hard time to hold up my fingers to show an inch...
For most people, "DPI" is an arbitrary number ranging from 72 to 288...
s your warranty :-)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Thursday, 26 September 2019 00:08:34 PDT Allan Sandfeld Jensen wrote:
> On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote:
> > > If possible, I’d like us to move away from relying on setting
> > > environment
> > > variables, and/or switch to spe
e);
const QProperty &firstName() const;
private:
QProperty m_firstName;
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
scale
> >>>> factor.
>
> On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote:
> >>> Sure, but where, on X11?
>
> On Thursday, 26 September 2019 00:08:34 PDT Allan Sandfeld Jensen wrote:
> >> xrandr?
>
> Thiago Macieira (26 Septe
ue_ptr deleters, not like QScopedPointer's deleter.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.o
ct to (say, a projector in a conference
room)? Does it:
a) keep the physical one from the monitor?
b) use 96x96?
c) use one of the other monitor's settings?
(hint: a, b and c are wrong)
Right now, I need exactly two values: the display panel's multiplicative
factor of 2 and the
les the fonts *again* so I get huge screens. So I'm
setting for readable GTK text with tiny icons.
Firefox seems to work fine and has right-sized icons. Google Chrome is scaled
to 225%.
> If this logic could be contained within the XCB platform plugin, and the
> result reported to
On Monday, 30 September 2019 11:06:18 PDT Matthew Woehlke wrote:
> IOW, the example would look like:
>
>
> fullname.setBinding(
> [](Foo const* self){
> return self->surname() + " " + self->lastname();
> });
How does the QProperty class
pen
source and there's no cannibalisation.
From a non-open point of view, that's not my place to comment. I firmly
believe in "why you should licence your next library GPL".
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software P
PL-2.0 MPL-2.0-no-
copyleft-exception NCSA NTP OFL-1.1 OpenSSL Public-Domain SGI-B-2.0 Unlicense
Zlib bzip2-1.0.6
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing li
est this can happen in C++23, lLet's table this discussion
until 2028.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://
ttps://github.com/fmtlib/fmt is MIT-licensed. If we can leverage the
implementation, it's a path forward.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Thursday, 17 October 2019 23:02:06 PDT Kai Pastor, DG0YT wrote:
> char *const key vs. char* const key
Third option:
char * const key;
I've seen all three in Qt source, though I think your first one is the one
that strictly follows our coding style guidelines.
--
Thiago
from other people, like
backtraces, or just plain looking at past history via git show and git blame.
You *have* to deal with the original.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
ing to release from the 5.12 branch directly, since the rate of
change is small enough?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-proje
hich LTS we had said we were going to do it for.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
can call setlocale() after QCoreApplication has. It's possible that they,
unknowingly, override our choices and change the C library back to an
incorrect state. If we do set the environment, this cannot happen.
Another side-effect is that in a Qt-based graphical
imple one-liner opt-in for applications that
> want to engage in "strict parenting" might be an option, too.
How about making the resetting opt-out, instead of opt-in?
QT_NO_OVERRIDE_LC_CTYPE?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
ot open ??.qm: No such file "..., 45Cannot open ??.qm: No such
file or directory
> > How about making the resetting opt-out, instead of opt-in?
> > QT_NO_OVERRIDE_LC_CTYPE?
>
> I was more thinking of a runtime option. Like
>
> QCoreApplication::setPropagateOurChoice
e to
suppress the Qt's override not sufficient?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
to setlocale(LC_ALL, "").
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
ior value.
That only applies to QProcess. It will not apply to third-party components
that fork helper processes.
It's possible atfork() could do this, but I'm not sure. it won't catch all of
them, especially those that prepare the environment before forking (like
execve
be non-configurable).
I don't disagree on the statement. I just disagree on whether it's harmful.
*Not* calling qputenv could be harmful too.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Monday, 4 November 2019 11:18:12 PST André Pönitz wrote:
> A parser accepting the output of one might or might not be able to
> handle the second.
A driver would set LC_ALL in the environment when it calls gcc.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect -
On Monday, 4 November 2019 11:50:01 PST André Pönitz wrote:
> On Mon, Nov 04, 2019 at 11:38:07AM -0800, Thiago Macieira wrote:
> > On Monday, 4 November 2019 11:18:12 PST André Pönitz wrote:
> > > A parser accepting the output of one might or might not be able to
>
On Monday, 4 November 2019 10:55:03 PST Thiago Macieira wrote:
> I'll do a full search on Clear Linux to see if there's any software that
> checks the return value of setlocale().
All "setlocale" calls.
First, the calls that to strcmp: I found comparisons in gn
Qt to
> this.
>
> Intuitively, it seems that port qt to a non-posix system can be a
> titanic task, but at least I want to evaluate the manpower for this.
Yes, don't go there. The only non-POSIX system supported is Windows.
--
Thiago Macieira - thiago.macieira (AT) intel.com
So
about compiler buggy with
> templates for example.
I was proposing that the barrier of entry is that the compiler supports C++98.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knar
.
>
> This also doesn't seem to be too hard.
I didn't get what you meant here. I only care that it's compatible with
existing source.
I think qdbusxml2cpp and qdbuscpp2xml should be bootstrapped and compiled to
host. qdbus doesn't need to be bootstrapped and it should be
the conclusion we could adopt a standardised solution.
That was Wayland.
So Wayland replaces QWS in Qt 5.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgata
PlatformSupport
into smaller libs.
This will be hard to do with qmake, so the easier way out is to remove the .a
altogether and use .pri files only. That requires moving the Wayland platform
plugin back into qtbase.
[1] https://codereview.qt-project.org/18023
--
Thiago Macieira - thiago.macieira
ee, there's no way to do that with standard qmake options.
We'd need to remove the library from "QT", which means we lose the -I
(include) options too.
And before anyone suggests "fixing the bug" note where the bug is: it is NOT a
bug in qmake. The bug is that QtPlatfo
On segunda-feira, 12 de março de 2012 11.50.17, morten.sor...@nokia.com wrote:
> On Mar 12, 2012, at 11:24 AM, ext Thiago Macieira wrote:
> > Anyway, either way this library will be gone. The most likely solution is
> > that we will break it up into many smaller .a libraries.
>
s a static lib with only
private headers.
As I said before, if this is essential, we should consider *proper* public
API. Keeping it like it is qualifies as "hack".
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel
hack qmake to support this
behaviour.
And do it again once we switch buildsystems in Qt 5.1 or 5.2, since "mandatory
dependencies are optional" is not usually a feature.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Int
t; to this list, or ask on IRC. Thanks.
Can you tell us which changes were necessary to fix the compilation? Knowing
which areas have caused issues in the past might help targeting in the future.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology
On terça-feira, 13 de março de 2012 09.22.21, tang ke wrote:
> hi all:
> I want to build the qt5 with cross-toolchain, the target arch is mips,
> the qt5 build support it?
When I last checked the build with Yocto's MIPS toolchain, it worked.
--
Thiago Macieira - thiago.macieira
7;t mind that qtbase does not compile for MIPS in the alpha
> > d.) ???
>
> I'd go for (b), but if possible only for MIPS.
Note that most users do not build the tests. So the build will not stop for
them.
-Werror should never be enabled on non-developer builds.
--
Thiago Maciei
hat the real headers we ship in a
> publicly-configured Qt are free of warnings.
Well, since this is a test, no. The -Werror should stay.
However, anywhere else than a test, -Werror should not be enabled.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open So
On quarta-feira, 14 de março de 2012 23.55.06, Thiago Macieira wrote:
> On quinta-feira, 15 de março de 2012 08.32.43, Rohan McGovern wrote:
> > You did approve the change which enables it, though
> > 7e970eb58c71dc08981575c648a04d258dbf0684, I mean.
> > Do you think this te
nings that we
hadn't seen before, and old versions we have not tested will produce old
false-positive warnings. For those reasons, enabling -Werror for anyone but us
is a mistake.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Ce
ure whether it
> can be done before Qt6 that way.
Refactoring the tools now is a complete no-go.
You want to:
- change how the tools accept parameters
- in tools that don't have good command-line parsing infrastructure
- 4 weeks after feature-freeze
--
Thiago Macieira - thiag
Just a reminder:
any Qt 4.8 fixes that are relevant to Qt 5 should go into Qt 5 first, before
they go into Qt 4.8.
Exceptions are fixes that are not relevant for 5.0 or are already fixed there.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source
On sexta-feira, 2 de março de 2012 10.27.56, Thiago Macieira wrote:
> Hello
>
> QPointer was ported to a QWeakPointer backend and deprecated early in Qt 5
> history. However, QPointer is used throughout our code and, I can expect, in
> user code too. Replacing it with QWeakPointer
, as you said, a ultra corner case. but it's not too hard
> to implement, I just don't know if is worth to implement this.
We'd probably implement this as either:
-Wl=
or
-W
And then parse the "l" as "linker flags" and then break the commas as different
optio
--
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 is a digitally signed message part
oactive
[2] my changes will make it use a lock, which means the initialisation will be
performed exactly once too, obviating the need for the initialisation function
to be thread-safe. However, my current solution is not deadlock-free.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software
On sexta-feira, 16 de março de 2012 12.38.57, Thiago Macieira wrote:
> Type *object()
> {
> static Type *pointer;
> if (!pointer) {
> pointer = new Type;
> initializer
> }
Add here:
return pointer;
> }
>
> that is equally as thread
-- Forwarded message --
Subject: [Releasing] Qt 5 alpha 20120314: linux g++ C++11: build summary
Date: sexta-feira, 16 de março de 2012, 14.45.12
From: Thiago Macieira
To: releas...@qt-project.org
The following modules built out-of-the-box:
qtbase
qtsvg
;t meet the minimum requirements is to
upgrade. Running brand, new and bleeding edge Qt 5 on an old system is not a
target for us. Simply upgrade -- at the very least the requirements.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
s and it's
been around for years.
The fact that the LSB is stuck in time is not a reason to hold Qt back from
important technology. I think it's important we do the opposite: help LSB 5.0.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Tech
ute, that's going to be a serious road block
> for them to move to Qt5.
Support is pretty much consistent. Every Linux distro uses X.org, which uses
XCB.
As for LSB, it's a matter of it being stuck in time in 2006/2007.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Softwar
he QWidget backgrounds show black (menus, tree views, etc.). I have not found
any crashes on startup.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15,
s that restore compatibility with
Qt 4?
After discussion here and maintainer's approval, of course.
--
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
the Qt build system.
Note that it needs to be an fPIC-static library, which most distributions do
not provide, nor is it the standard build of static libraries when compiled
with autoconf / automake.
If you want an XCB library that you can link into a plugin, you'll need to do
a bit of hacking
ly raising test coverage of qtbase.
While the statement is true, I don't think it's the cause of the problem.
qtdeclarative is well-known for depending on the internals of QtCore and
QtGui. Internals are not unit-tested and will probably never be.
So the breaking of qtdeclarative will continu
Usually, the rule of thumb is that "if Debian stable has it, then everyone of
note has it".
That of course doesn't include really-really-long term releases like RHEL4.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Cente
problem.
Cleanup for the sake of cleanup was never allowed. There were plenty of "###
Qt5" tasks that weren't done.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556
re of any place where I wrote
code that depended on a specific order. If that happened, it was an
unintentional mistake.
[1] note that the order is stable. Two hashing tables with the same elements
must produce the same order.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Archit
On segunda-feira, 19 de março de 2012 11.17.29, André Somers wrote:
> Op 19-3-2012 10:42, Thiago Macieira schreef:
> > They shouldn't rely on that at all. The documentation of QHash says
> > that it produces an arbitrary but stable[1] order.
> >
> > [1] note that
On segunda-feira, 19 de março de 2012 10.42.44, Thiago Macieira wrote:
> [1] note that the order is stable. Two hashing tables with the same
> elements must produce the same order.
Actually, thinking a little more about this, I might be wrong.
If two elements produce the same hashing val
l be
made public. We don't want you to accidentally leak privileged information
(which includes people's names, unless they consent to having it public).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - R
On segunda-feira, 19 de março de 2012 14.28.35, Kent Hansen wrote:
> Den 19. mars 2012 10:32, skrev ext Thiago Macieira:
> > On segunda-feira, 19 de março de 2012 08.01.41, lars.kn...@nokia.com
wrote:
> >>> Yes, in some ways I feel this is adding complexity to the test setup t
On segunda-feira, 19 de março de 2012 21.29.12, Shawn Rutledge wrote:
> 2012/3/18 Thiago Macieira :
> > so users can test. So far, in my testing, I have found that Qt Creator
> > compiles and runs, with Qt Quick parts (I don't know if 1 or 2) show fine,
> > but the QWid
On terça-feira, 20 de março de 2012 07.21.37, jiang.ji...@nokia.com wrote:
> Hi Thiago,
>
> On Mar 19, 2012, at 9:50 PM, ext Thiago Macieira wrote:
> >> That started happening sometime between 17 Feb. and now, FWIW; I
> >> suspect it's quite recent. At l
On terça-feira, 20 de março de 2012 09.45.02, jiang.ji...@nokia.com wrote:
> Hi Thiago,
>
> On Mar 20, 2012, at 8:31 AM, ext Thiago Macieira wrote:
> > That's the point: I don't want it to convert. I want to configure my
> > system to use "Monospace" and
On terça-feira, 20 de março de 2012 09.45.02, jiang.ji...@nokia.com wrote:
> Hi Thiago,
>
> On Mar 20, 2012, at 8:31 AM, ext Thiago Macieira wrote:
> > That's the point: I don't want it to convert. I want to configure my
> > system to use "Monospace" and
On terça-feira, 20 de março de 2012 14.02.27, jiang.ji...@nokia.com wrote:
> On Mar 20, 2012, at 1:58 PM, ext Thiago Macieira wrote:
> >> Font matching in QPA is pretty much broken for these cases, I have a WIP
> >> patch to fix this: http://codereview.qt-project.o
On quarta-feira, 21 de março de 2012 22.01.09, Denis Shienkov wrote:
> I tried to connect it to my project (Qt5):
>
> #include
Add to the .pro file:
QT += core-private
Then:
#include
This will work.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - I
t works for me here.
--
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 is a digitally signe
On quinta-feira, 22 de março de 2012 20.54.54, BOUCARD Olivier wrote:
> The file teapot.h from Qt5 contains this:
>
>
> #ifndef CUBE_H
> #define CUBE_H
>
> I think this is a typo. Copy&paste are really dangerous commands... ;)
HTTP error code 418
--
Thiago Macie
ly
does is tell qmake to stop and reload a different configuration. But it doesn't
change how qmake sees the world.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Kna
onstraints but is not an actual primitive (fundamental). I don't know if
we'll ever need the difference, but I'd rather we had it proper if it doesn't
cost us much.
The closest definition that C++11 has for our Q_PRIMITIVE_TYPE is either
"scalar type" (arithmetic,
eview the "port" of other code:
https://codereview.qt-project.org/21064
https://codereview.qt-project.org/21493
Most of the changes are only performance improvements since the API retains
compatibility.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Arch
t Gerrit shows unrelated too
http://codereview.qt-project.org/21067 only rebase - Gerrit shows unrelated
http://codereview.qt-project.org/21068 only rebase - Gerrit shows unrelated
http://codereview.qt-project.org/21751 new change
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software A
added
in September, before we changed our headers) and one behaviour change reversal
caught by QDesktopServices. And one extra attempt due to a network test
timeout failure.
We *really* need the topic branch reviewing feature back in. It's no fun
staging 19, 20, 20 and 21 changes...
--
Th
] the enum already has the reserved bits for RemoveHost and RemoveUserName
and has had them since Qt 4.0. We could add them later.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
On quinta-feira, 29 de março de 2012 23.31.38, Thiago Macieira wrote:
> Staged, re-staged, re-re-staged and once again for good measure, and it's
> in :-)
Oh, did I mention I had a QEXPECT_FAIL sneak in due to a feature that David
added to QUrl after I had already completed my work,
n always override
> it, I'm fine with that ;-)
How would it decrease performance?
--
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
On sexta-feira, 30 de março de 2012 17.00.15, Stephen Kelly wrote:
> On Thursday, March 29, 2012 23:31:38 Thiago Macieira wrote:
> > We really need the topic branch reviewing feature back in. It's no fun
> > staging 19, 20, 20 and 21 changes...
>
> Did you consider stagi
On sexta-feira, 30 de março de 2012 18.41.46, Olivier Goffart wrote:
> On Friday 30 March 2012 12:23:59 Thiago Macieira wrote:
> > Use of QVarLengthArray should *only* be done with primitive types, the
> > fixes applied to it during Qt 4.x lifetime notwithstanding. So the user
>
On sábado, 31 de março de 2012 18.14.50, Stephen Kelly wrote:
> On Friday, March 30, 2012 12:45:44 Thiago Macieira wrote:
> > On sexta-feira, 30 de março de 2012 17.00.15, Stephen Kelly wrote:
> > > On Thursday, March 29, 2012 23:31:38 Thiago Macieira wrote:
> > > > W
ght lead to confusion.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed m
necessitated moving the optimisations and improvements to
the recoder before QUrlQuery was added.
I've never tested if that reordering introduced failures in existing tests.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology
to deploy such apps - everything else will be in vein.
I don't think Apple will ever allow that. I don't think Apple will allow
executing any code that isn't loaded strictly from disk.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Techno
)used Stephen's goodwill to review
simple things, but I don't expect him to understand the message delivery path
for example.
What is the suggested procedure?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden
601 - 700 of 6737 matches
Mail list logo
