ould be able to put that up on GitHub sometime.
Cheers, Kuba Ober
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
doesn't
help. Am I missing something, or is this a bug? OPENSSL_PATH also seems to be a
no-op.
Thanks, Kuba Ober
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
> 18 apr. 2017 kl. 04:37 skrev Mikkel Krautz :
>
> MSVC 2015 has buggy magic statics, see
> https://bugreports.qt.io/browse/QTBUG-58318 and
> https://connect.microsoft.com/VisualStudio/feedback/details/3121209
>
> I worked around the issue by disabling them with -Zc:threadSafeInit-.
Wow, thank y
the heap corruption is detected in a heap free from one
of the Q_GLOBAL_STATICs in somewhere in Qt.
Cheers, Kuba Ober
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
23 mars 2017 kl. 17:22 skrev Thiago Macieira :
>
> You're contradicting yourself now. If private inheritance is not is-a, then
> you can't tell me not to use private inheritance because QString isn't a
> QStringView.
>
> I don't want QStringView to appear to users as a base of QString. I just
> 7 mars 2017 kl. 15:54 skrev Thiago Macieira :
>
> Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore escreveu:
>>> The Qt Company has now very recently made a decision to now go and invest
>>> the man power required to turn qbs into a product we can fully support in
>>> the fut
> On Aug 25, 2016, at 5:48 AM, Marc Mutz wrote:
>
> On Wednesday 24 August 2016 20:05:56 Kuba Ober wrote:
>> `QObject` is already pretty much a handle to the underlying data due to
>> pimpl. So that’s a good first step.
>
> I challenge the notion that QObject is a h
`QObject` is already pretty much a handle to the underlying data due to pimpl.
So that’s a good first step.
To support this, the `QObject*` (and derived types) would be replaced with
`QObject::Handle` that keeps a pimpl C pointer. E.g. we’d have `QObject::Handle
* QObjectData::parent, QList QOb
Attached is a patch against 5.7.0 release to fix ANGLE to build for the Windows
XP target. I don’t have the time to submit a proper change via gerrit, so I’ll
leave it out here for grabs if anyone is interested.
Other than that, 5.7 builds fine under MSVC 2015 configured with -target xp
-skip q
On Tue, Jul 21, 2015 at 11:47 AM, Thiago Macieira wrote:
> On Tuesday 21 July 2015 10:19:59 Matthew Woehlke wrote:
> > On 2015-07-21 01:06, Thiago Macieira wrote:
>
> > Is it possible to have Qt type traits
> > on a type T such that QList will always be QVector-like? Or would it
> > be impossible
That's an interesting observation. Would it be easy to add an api to QList
and QVector that would somehow keep track of the empty spots and use them
if available? In a `QList`, it would require only an extra pointer to the
first "empty" member slot, the slots would act as a singly-linked list.
Same
On Tue, Oct 7, 2014 at 11:41 AM, Thiago Macieira
wrote:
> On Tuesday 07 October 2014 10:38:47 Kuba Ober wrote:
> > Just to be very clear: it is currently impossible to make a truly
> portable
> > file management utility with Qt’s core APIs. Why? Because it will simply
> &g
On Oct 7, 2014, at 8:30 AM, Julien Blanc wrote:
> On 07/10/2014 12:11, Tomasz Siekierda wrote:
>> For file paths, I feel QString is really enough.
>> Changing it to something else because of a few corner cases seems like
>> an overkill to me. We already have a lot of classes that are connected
>
On Oct 7, 2014, at 6:11 AM, Tomasz Siekierda wrote:
> On 7 October 2014 11:16, Marc Mutz wrote:
>>> Ugh, that begins to sound like Java. Let's have a wrapper for a
>>> wrapper... please don't go that way.
>
>> We have QSize and QPoint and they're used ubiquitously in Qt. But, by your
>> ration
On Oct 6, 2014, at 2:45 PM, Thiago Macieira wrote:
> On Monday 06 October 2014 13:30:29 Kuba Ober wrote:
>>> This was discussed to exhaustion in Qt 5's development process. The
>>> conclusion is to remain at status quo since there is no good, technical
>>>
On Oct 6, 2014, at 11:21 AM, Thiago Macieira wrote:
> On Monday 06 October 2014 11:12:57 Kuba Ober wrote:
>> Thus, how does Qt deal with a directory listing with such “invalid” file
>> names? Do they survive the round-trip through a QString and QDirIterator?
>> Would it be
Is
there a policy of gradual degradation, or is a null pointer dereference an
acceptable outcome?
Cheers, Kuba Ober
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
, Kuba Ober
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
should be scolded until it sinks in. I’m not
kidding. This is form over substance at its finest. I like modern designs, but
they must be actually usable. qt.io right now is like a very well manicured pig
(with apologies to bacon).
Cheers, Kuba Ober
ibutions must be upstreamed.
>
> We all want contributions by FOSS users of Qt after all, no?
I’d go further and cetegorically state that the qt.io site, as it currently
stands, seems to be designed to spread licensing FUD and is intentionally
deceptive.
Cheers, Kuba Ober
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
the owners of Qt spend for anything besides the code
is, to us as the end users, *our* money burned for frivolities.
Cheers, Kuba Ober
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
ification, if necessary. This is definitely an enum, not a bool.
> I'll block any patch that tries to give a certainty where the lower level
> doesn't give us certainty.
Yes, please do!
Cheers, Kuba Ober
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
f
how qmake works and it shows).
Cheers, Kuba Ober
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Jul 4, 2014, at 11:33 PM, Thiago Macieira wrote:
> On Friday 04 July 2014 19:02:39 Jake Petroules wrote:
>> Keep in mind that object files are not source code. There is no harm that
>> can be done to your IP by providing them as required by the license. If
>> someone really wants to reverse en
On May 29, 2014, at 6:03 AM, Adam Strzelecki wrote:
> Putting my 2¢ in, Qmake is IMHO good enough. Qbs is kind of vaporware, sparse
> documentation, needs Qmake to build (woot?!).
>
> Altogether it sounds like a clinch, we don't want to extent Qmake with ninja
> or anything, because there com
On May 22, 2014, at 8:55 AM, Joerg Bornemann wrote:
> On 21-May-14 21:36, Kuba Ober wrote:
>
>> Bootstrapping is about the only possible glitch I see with Qt being built
>> with QBS.
>> I mean, good luck bootstrapping QML without Qt built. Or is that something
>&
On May 16, 2014, at 3:33 AM, Jędrzej Nowacki wrote:
> On Friday 16 of May 2014 12:33:49 Ben Lau wrote:
>> Why? Is there any special reason to implement in this order? or it is a bug?
>
> It look like a bug.
It *is* a bug. No doubt about it.
Cheers, Kuba
On May 20, 2014, at 5:11 AM, Kalinowski Maurice
wrote:
> What Ossi tries to say is that QBS takes a couple of different approaches.
> You can find an old blog post describing the details here:
> http://blog.qt.digia.com/blog/2009/10/12/to-make-or-not-to-make-qmake-and-beyond/
>
> But to be cle
lly,
I have notifications of the USB transactions being finished, and of the device
FIFOs emptying.
I could do software DTR switching if I needed it. Using stock drivers it’s
impossible. I only
use it for diagnostics, though.
Cheers, Kuba Ober
___
Develop
of the buffer as requested in the argument to `read` and
return to the user.
On platforms where there is no non-blocking API for step #1, the read and write
is forced to
use the buffer only, as it currently does.
Cheers, Kuba Ober
On Apr 21, 2014, at 12:35 PM, Denis Shienkov wrote:
> Thi
I confirm that this change is needed, and I have multiple workarounds for it in
the code
that uses Qt 4.8.
Thanks, Kuba
On Mar 18, 2014, at 6:25 AM, Adam Strzelecki wrote:
> Hi,
>
> I there any chance to backport object_parallel_to_source to 4.8.6 as reported
> here:
>
> https://bugreports.
ed without dropping 10.6 support, then?
For what it’s worth, I’ve updated to Mavericks a couple days after release, but
straight from 10.6! I’ve evaluated 10.8 in the meantime, but wasn’t running it
most of the time. So I’ve been a 10.6 user on 3 machines up till Oct 2013.
Cheers, Kuba Ober
every
metacall event.
As an extension of this approach, one could provide a factory method in
`QMetaCallEvent`
that would allocate the proper amount of memory all in one go (to fit the
event, the
arguments, and possibly the types when it owns the types).
Does this make sense?
Cheers, Kuba Ober
On Jan 12, 2014, at 7:16 AM, Mike Krus wrote:
> as far as I know, debug builds on OSX are not redistributable because they
> directly reference the location of the source files.
> So you need to do your own build and keep the source files in the same place.
Both gdb and lldb offers a way of sub
On Jan 10, 2014, at 6:07 AM, Ziller Eike wrote:
> On Jan 9, 2014, at 6:05 PM, Kuba Ober wrote:
>
>> I’m trying to figure out the most constructive way of ensuring that an OS X
>> build of Qt, installed with the source code, can be actually debugged by
>> stepping int
rces when installing the official Qt build?
Thanks, Kuba Ober
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Dec 18, 2013, at 7:17 PM, Andreas Hartmetz wrote:
> 2) reminds me of a crazy idea I've had once... freeing memory (not
> object destruction!) at application exit really serves no other purpose
> than making leak checkers happy. Not saying that this isn't an
> important goal, btw. So shutdown c
Is this supported on all platforms now? IIRC it did not work OS X last time I
tried, but yes,
it did work great on Windows.
— Kuba
On Dec 14, 2013, at 3:25 PM, Roland Winklmeier
wrote:
> Thanks very much Olivier and Thiago!
> That works brilliant.
>
> No idea why I forgot that QThread must
as I’m concerned, .ui files should die a quick and painless death. They
belong to the dustbin of history.
Cheers, Kuba Ober
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Oct 29, 2013, at 7:58 PM, Calogero Mauceri wrote:
> The Qt documentation states that QDir::currentPath() returns "The
> application working directory". Shouldn't the workind directory be
> initialized with the path the application was launched from?
No, it will be initialized with whateve
the platforms of your choice
and for your purposes, and stick to it - meaning it’s on you to integrate it.
Note that V8 is out of the question on many app stores due to sandboxing
requirements.
If you want your platform to be usable on the ever-more-powerful mobile
platforms, that needs to be kept i
On Sep 16, 2013, at 4:59 PM, Thiago Macieira wrote:
> On segunda-feira, 16 de setembro de 2013 14:17:41, Kuba Ober wrote:
>> I'm trying to build 5.1.1 from source (.zip download) on Windows using
>> MSVC2012, in a separate prefix (shadow) build. So far I've run int
I'm trying to build 5.1.1 from source (.zip download) on Windows using
MSVC2012, in a separate
prefix (shadow) build. So far I've run into two issues:
1. configure.bat fails to bootstrap without .gitignore being present. Wouldn't
it be better to check for
presence of configure.exe? Are we only s
43 matches
Mail list logo
