Re: [Development] Build system for Qt 6

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

[Development] openssl-linked include paths in Qt 5.8

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

Re: [Development] 5.7/5.8 gives unusable static ltcg x86 builds on MSVC 2015/2017

> 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

[Development] 5.7/5.8 gives unusable static ltcg x86 builds on MSVC 2015/2017

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

Re: [Development] QList

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

Re: [Development] syncqt.pl in C++

> 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

Re: [Development] Would it make sense to make QObject moveable in Qt 6?

> On Aug 25, 2016, at 5:48 AM, Marc Mutz <marc.m...@kdab.com> 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 th

[Development] Would it make sense to make QObject moveable in Qt 6?

`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

[Development] Patch to fix ANGLE build for XP targets in Qt 5.7.0

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

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

On Tue, Jul 21, 2015 at 11:47 AM, Thiago Macieira thiago.macie...@intel.com 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 QListT will always be QVector-like? Or would

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

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

Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems

On Tue, Oct 7, 2014 at 11:41 AM, Thiago Macieira thiago.macie...@intel.com 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 ignore

Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems

On Oct 7, 2014, at 8:30 AM, Julien Blanc julien.bl...@nmc-company.com 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

[Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems

, Kuba Ober ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems

On Oct 6, 2014, at 11:21 AM, Thiago Macieira thiago.macie...@intel.com 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

Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems

On Oct 6, 2014, at 2:45 PM, Thiago Macieira thiago.macie...@intel.com 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 solution. I’d think

Re: [Development] New company name for Qt part of Digia and unified web site

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

Re: [Development] New company name for Qt part of Digia and unified web site

, 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

[Development] www.qt.io/download-open-source is broken

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

Re: [Development] QStorageInfo

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

Re: [Development] Qmake Ninja generator

On May 29, 2014, at 6:03 AM, Adam Strzelecki o...@java.pl 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

Re: [Development] Qmake Ninja generator

On May 22, 2014, at 8:55 AM, Joerg Bornemann joerg.bornem...@digia.com 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 that wouldn’t

Re: [Development] The rowsAboutToBeRemoved signal in ListModel

On May 16, 2014, at 3:33 AM, Jędrzej Nowacki jedrzej.nowa...@digia.com 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

Re: [Development] Qmake Ninja generator

On May 20, 2014, at 5:11 AM, Kalinowski Maurice maurice.kalinow...@digia.com 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:

Re: [Development] [QIODevice]How to correctly treat/understand of the documentation?

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 ___ Development mailing list Development@qt

Re: [Development] [QIODevice]How to correctly treat/understand of the documentation?

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 denis.shien

Re: [Development] New snapshot build from Qt 4.8.6 available

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 o...@java.pl wrote: Hi, I there any chance to backport object_parallel_to_source to 4.8.6 as reported here:

Re: [Development] Remove OSX 10.6 Build?

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 [1]: https://developer.apple.com/library/mac/releasenotes

[Development] Reducing number of allocations in metacall argument marshalling

for 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

Re: [Development] Debugging into Qt binaries

On Jan 12, 2014, at 7:16 AM, Mike Krus mike.k...@gmail.com 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

Re: [Development] Debugging into Qt binaries

On Jan 10, 2014, at 6:07 AM, Ziller Eike eike.zil...@digia.com wrote: On Jan 9, 2014, at 6:05 PM, Kuba Ober k...@mareimbrium.org 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

[Development] Debugging into Qt binaries

the official Qt build? Thanks, Kuba Ober ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt's Leak-on-exit policy

On Dec 18, 2013, at 7:17 PM, Andreas Hartmetz ahartm...@gmail.com 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,

Re: [Development] Trigger Qt event loop from external message loop

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 roland.m.winklme...@gmail.com wrote: Thanks very much Olivier and Thiago! That works brilliant. No idea why I

Re: [Development] QML and JavaScript extensions

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

Re: [Development] QML and JavaScript extensions

in mind. Cheers, Kuba Ober ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 4.8.6 Release Plans

On Oct 29, 2013, at 7:58 PM, Calogero Mauceri mauc...@actgate.com 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

Re: [Development] Source build woes on windows

On Sep 16, 2013, at 4:59 PM, Thiago Macieira thiago.macie...@intel.com 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 into two

[Development] Source build woes on windows

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