Doh, turns out they're all there in a different subdirectory that I wasn't
aware of ...
https://download.qt.io/new_archive/qt
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
René J.V. Bertin wrote on 20240526::14:25:20 re: "Getting "really old" Qt
sources"
>I can manage to check out the skeleton at the commit (tag) of interest (say,
>v5.3.2) but the actual sources aren't there.
I'm beginning to get the idea that there's a perl (i.e. contrived...) script
that must
On Sunday May 26 2024 14:33:35 apoenitz wrote:
>Versions down to 1.41 are at https://download.qt.io/archive/qt/
>
>Do you really need even older ones?
>
Sorry, I meant Qt *5* sources. That archive only holds a seemingly random
collection of "mijor" versions, nothing between 5.12 and 5.1 .
R
Hi,
Qt have decided (in their wisdom?) to retire the sources of "really old"
releases from their servers. I assume they're still available via git
(including the mirrors on github, I hope) but I'm drawing a blank in checking
out the "everywhere" source tree from the github:qt/qt5 repo. I can
On Tuesday April 11 2023 19:03:54 René J.V. Bertin wrote:
>OK, it gets weirder: the issue doesn't exist with Qt 5.9.8 built off the same
>sources on Mac...
Well, apologies for the noise, this was all a false alarm.
I've learned that the shared-mime-info db does indeed contain file "magic" data
On Tuesday April 11 2023 16:02:04 René J.V. Bertin wrote:
>Hi,
>
>I just discovered that Qt 5.9 mis-identifies webp images as RIFF audio when
>allowed to determine type from content - and for very obvious reasons.
>By Qt 5.12 this issue was addressed
OK, it gets weirder: the issue doesn't exist
Lars Knoll wrote on 20230411::16:40:08 re: "Re: [Interest] Webp files and
QMimeType"
>Mime types are determined from the mime database package. By default Qt uses a
>copy of the freedesktop.org package. It lives in
>qtbase/src/corelib/mimetypes/mime. Just copying the content of that directory
Hi,
I just discovered that Qt 5.9 mis-identifies webp images as RIFF audio when
allowed to determine type from content - and for very obvious reasons.
By Qt 5.12 this issue was addressed, and curiously it didn't exist in Qt 4.8.7
either.
I'm running a few systems that are limited to Qt 5.9,
Hi,
I have some old Qt4 code I'm porting to Qt5 that includes this
```
void
MyApplication::renderDone()
{
QPalette palette = desktop()->palette();
palette.setBrush(desktop()->backgroundRole(), QBrush(renderer->pixmap()));
desktop()->setPalette(palette);
Hi,
I'm tinkering with the old KDE4 login manager for X11, KDM, porting it to
Qt5/KF5. On startup, the greeter component kills all existing clients of the
display using basic X11 calls in C. This was apparently never a problem, but it
is under Qt5 where the greeter ends up killing itself.
Is
Hi,
AFAIK users of Unix systems can get Qt to use plugins they installed themselves
in a custom/personal location. Is there a way to check programmatically where a
given, loaded plugin lives?
In particular, is there a straightforward way to filter out styles from the
output of
Thiago Macieira wrote:
Well well, I turn my back a couple of days and there's a whole lot of
interesting things going on behind it :)
> On Monday, 20 July 2020 22:46:36 PDT Thiago Macieira wrote:
>> So the common denominator of SLM and SNB is the WSM (Westmere).
Indeed, my i7 is a Sandybridge
Hi,
According to the documentation, where in Qt4/X11 one could create a "foreign"
QWidget with QWidget::create(WId id, ...), in Qt5 one has to do something like
externalWindow = QWindow::fromWinId(id);
if (externalWindow) {
externalParent =
On Saturday July 18 2020 10:20:44 Thiago Macieira wrote:
>That's a Braswell-based Atom:
Or rather a Celeron (whatever the exact difference is)?
https://en.wikichip.org/wiki/intel/celeron/n3150
>So -march=silvermont.
Thanks, will try though
Hi,
I know it goes against "suggested wisdom" to tinker with compiler options when
building Qt code, but in my experience you do need to tell the compiler what
instruction set extensions it must enable. In any case, my binaries built on a
recent'ish Celeron (N3150) ran fine in a VM on a 2011
On Sunday July 12 2020 18:02:00 Donald Carr wrote:
>@rene: I would recommend reading:
Remember, I didn't know about CopperSpice until a few days ago. Does it
interest me as an alternative, sure, but not as anything more than that.
Also please remember that my post was about QtWebKit.
>to
On Saturday July 11 2020 05:26:39 Roland Hughes wrote:
Is there even a way to determine the actual WebKit version when you don't have
the sources, one that doesn't rely on trusting the user agent string offered by
the web browser?
>to the Qt API and its relentless pursuit of worthless QML.
On Friday July 10 2020 06:58:34 Roland Hughes wrote:
>and this documentation link for CopperSpice
>https://www.copperspice.com/docs/cs_api_1.6/concepts-webkit.html
>
>They have a "slightly" newer version of WebKit.
...
>You might want to see how much pain would be involved in porting your
On Thursday July 09 2020 22:30:56 Konstantin Tokarev wrote:
>If such glue library is not a part of QtWebKit, it would have to deal with
>having Qt4 and Qt5 in the same process. That would be no easier than wrapping
>any other unmodified Qt5 module for use in Qt4 application.
I don't see why.
On Thursday July 09 2020 19:14:35 André Pönitz wrote:
>Are the applications you are interested in publicly available?
Most of them should be, but I've already admitted that the main one is the KDE
PIM suite. Not exactly a medium-sized application in my book, and it contains
components (which I
On Thursday July 09 2020 15:49:52 Konstantin Tokarev wrote:
>> I don't see the problem here, as long as we're talking about actual
>> individual processes?
>
>Individual process which are in fact just different entry points of the same
>shared library. Building same files twice for Qt4 and Qt5
On Thursday July 09 2020 14:21:53 Konstantin Tokarev wrote:
>I don't know how complex is said application, but almost certainly it would be
>easier to port it to Qt5 instead (and more useful to community, as Qt4 had
>reached EOL many years ago)
I know, but you know what they say about things
Hi,
Call me stupid or whatever you like, but I am hanging on to a few Qt4
applications that never got a satisfactory (to me) Qt5 successor, and which use
QtWebKit to render HTML documents.
It's happening more and more often that I come across such documents that don't
render properly in
Hi,
Periodically I get curious what I'm missing out on not being able to run a
recent proper WebKit(2)-based browser (i.e. Safari) and start wondering how
suitable such a browser would be as a usable alternative to the Firefox or
Chromium-based behemoths - and how much less resource hungry it
Giuseppe D'Angelo via Interest wrote:
> What issues are we talking about?
General slowness, remote GLX/EGL quirks depending on the remove X11 server. And
a few issues when running on Mac with the XCB QPA. AFAIK that is not officially
NOT supported (and it's relatively trivial to get to build)
Hi,
This could come across as a subtle new form of heresy, but is anyone aware of
(work on) a GTk-based QPA plugin for Qt? Not a style or platform theme plugin,
but an actual alternative for the XCB QPA plugin. In general I find that
GTk-based applications are more suitable for use with a
Hi,
I have an application with a lengthy shutdown procedure that's been known to
get stuck. So, I added
static bool coreShuttingDown = true;
QTimer::singleShot(6, [&] {
if (coreShuttingDown) {
// when our time is up, raise the SIGHUP signal that
René J.V. Bertin wrote:
> Concretely: I have built KDE Dolphin for Mac, and find I can copy/move files
> by dragging them from the Finder and dropping them onto a destination folder
> in Dolphin (e.g. for copying to a remote server that isn't accessible through
> the Finder). For some reason the
Hi,
Can someone point me to a succinct overview of the basics of drag-and-drop
support in Qt applications?
Concretely: I have built KDE Dolphin for Mac, and find I can copy/move files by
dragging them from the Finder and dropping them onto a destination folder in
Dolphin (e.g. for copying to
On Thursday April 09 2020 13:41:51 René J.V. Bertin wrote:
> Is there a way to indicate that you have no use for the bearer stuff and not
> have it waste resources?
NB: deleting the bearer plugins doesn't seem to stop the bearer thread from
being created (and the code suggests it might even do
Hi,
As far as I understand Qt's bearer management feature is not relevant for
desktop (including laptop) systems where connectivity is handled by the system
and a priori permanent. So why does an application that just wants to do simple
stuff over a network connection (and use Qt APIs for
Thiago Macieira wrote:
> The chance that it has been overwritten is 100% at this point.
Are you certain this is true on all platforms? I seem to recall one where you
can get at argc,argv through global variables (or where they functions...),
possibly OS X or otherwise MS Windows.
> This was a
Thanks for the answers; I almost missed them because of GMane changes.
> Sorry, it's a bug in the application code.
I was beginning to think as much.
> QCoreApplication keep s a reference to argc. Since main() has exited, the
> reference is now dangling
I suppose this depends on the runtime,
Hi,
I call
QString arg0 = qApp? qApp->arguments()[0] : QString();
in order to get the application name in a function that can also be called
during the global destruction phase. I've never seen issues with that with Qt
<= 5.9 but just had a crash with Qt 5.12.6 :
#6 0x7f5e8f133dfa
A thought:
What would be the proper way to implement something that behaves like a QTimer
with delay 0 (= fire as soon as the event loop becomes available) but with an
interval (= fire as soon as the event loop becomes available after at least X
msec of pause)? Add a QThread::msleep() call
On Saturday October 05 2019 09:29:17 René J.V. Bertin wrote:
>But Q*Animation in basic form shouldn't need to be so much more intensive,
>right? You'd be doing the same work in a finger-painting approach if you want
>the same animation parameters (here, rotate from 0 to 360 in 2s with 16ms
On Friday October 04 2019 23:56:13 André Pönitz wrote:
Hi,
>I'd take a step back here and check what is really needed for the
>purpose.
That was my actual purpose here... Thing is, in order to indicate "we're busy",
you can toggle a state (green becomes red), play a waiting music or display a
Giuseppe D'Angelo via Interest wrote:
> By default non-QQ2 related animations run every 16ms. Do you have a
> minimal testcase showcasing a suspicious activity of an animation?
I never said anything about suspicious activity (and the idea that something
could be wrong with Q*Animation on my
Hi,
A discussion about CPU load recently came up with the author(s) of the newish
KBusyIndicatorWidget in the KF5 KWidgetsAddons framework, after I noticed that
the test/demo utility runs at 12-13% CPU (according to `top`, on 2 CPUs, a
lowly N3150 and a much faster i7). I find that
[resent in adapted form from the plasma-devel ML in hope of getting a reply
here]
Hi,
I had a recent run-in with a style hint that should actually be a platform
(QPA) specific property (à la AA_DontUseNativeMenuBar; see QTBUG-77928) and
then realised it could be useful to have a standalone
On Friday September 13 2019 18:26:53 Konstantin Tokarev wrote:
>FWIW, you can find patches for LibreSSL support at
>https://bugs.gentoo.org/562050
Interesting, thanks.
R.
___
Interest mailing list
Interest@qt-project.org
I finally got around to upgrading OpenSSL and getting to work Qt 5.9 with it.
It
required an additional change that I hadn't found in the 5.10 branch: accepting
the newer version during the configure phase :)
Hi,
Has anyone noticed a surprising interaction between the (set)WindowModified()
feature, setWindowTitle() and the style in use, on Mac?
I do not yet understand it perfectly myself, but in a rough outline, if you
1) call setWindowModified(true) and then
2) change the title with
Sérgio Martins wrote:
> I only know of the LTO problem when building Qt with clang (closed as
> WONTFIX in both Qt and Clang trackers IIRC)
The problem with the bootstrap static library not being recognised as such,
despite having been created with llvm-ar?
R.
On Thursday July 25 2019 17:27:43 Vadim Peretokin wrote:
>I think you meant https://github.com/RJVB/QEmuStringView
Yes, I thought that'd be evident ;)
It was an interesting exercise. I didn't manage to get everything related to
constexpr features to work but that's probably to be expected, and
Took me a bit more trial & error than I thought, but here's something with
which
almost all tests pass:
github:RJVB/QEmuStringView
R.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Hi,
I've been coming across code that uses QStringView but that I'd like to be able
to build against Qt 5.9 . I have thus been thinking of ways to achieve this and
am hoping on some constructive feedback (= not of the kind "just use Qt 5.1x
already ;) )
I haven't seen a clear, succinct
Nikos Chantziaras wrote:
> Unfortunately, there is no way to disable the preview.
I run my own Qt version which isn't 100% stock anyway, so I introduced an env.
variable check for QT_FONTCOMBOBOX_NO_PREVIEW in QFontFamilyDelegate::paint()
which determines whether the font family and size are
On Thursday May 30 2019 18:16:25 Konstantin Tokarev wrote:
>
> Have you considered using regular QComboBox with list of font family names,
> obtained from QFontDatabase?
Yes, of course. Not entirely as easy as setting a QFontComboBox property :)
R.
Hi,
Is there a way to prevent font previews in the QFOntComboBox widget, or do
application which offer to deactivate the feature have their own implementation
of a comparable widget?
Thanks,
R.
___
Interest mailing list
Interest@qt-project.org
On Tuesday May 28 2019 15:27:54 Jim Prouty wrote:
Thanks,
>Or, if you want to load them from your bundle, put them in (for example)
>Your.app/Contents/Resources/Fonts, the value is only the bit after
>Contents/Resources, namely "Fonts".
I wasn't aware of this Info dict key but I also tweaked
On Sunday May 26 2019 14:10:46 Elvis Stansvik wrote:
>to check if p is 1, else check if p is 2. With the default: added with
>the unreachable hint, it's enough for it to generate instructions to
>check if p is 1, because if it isn't, then it is 2 for sure (because
>the default:, which covers
Giuseppe D'Angelo via Interest wrote:
Hi,
> On the other hand, Q_ASSUME(cond) tells the compiler that cond is true,
After reading the MS doc I sort of understand how you can use the construct to
implement a Q_UNREACHABLE (but in the example given I don't see the codegen
advantage of `default:
On Saturday May 25 2019 11:05:39 Elvis Stansvik wrote:
> E.g.
>
> Q_ASSUME(!atWar);
>
> if (atWar) {
> fireNukes(); <-- Oops, nukes may not be fired, even if at war,
> because compiler may have taken the hint and assumed we're not at war
> }
>
> Microsoft seems to have a nice article about
Hi,
I can't seem to wrap my head around what one can do with Q_ASSUME, i.e. which
will be the code for which the compiler won't emit code (and how the compiler
could know not to emit code as a function of a runtime condition?!)
Squinting at the macros it seems evident that you cannot do
Hi,
Is there a known issue when using QFDb::addApplicationFontFromData() or
QFDb::addApplicationFont() with an embedded resource path in Qt 5.9 on Mac? I'm
getting a crash; as far as I can tell the CTFontRef creation from the font data
succeeds but the CoreText call to fetch the font
Thiago Macieira wrote:
> Qt 5.10 and up do have a detection to see if you have 1.0 or 1.1. OpenSUSE has
> no need for that, since they know which version their distro has.
About that: is there a way to get the detection to use pkg-config to determine
the location of the openssl headers?
Thiago Macieira wrote:
> Qt 5.10 and up do have a detection to see if you have 1.0 or 1.1. OpenSUSE has
> no need for that, since they know which version their distro has.
I was thinking it might be something like that.
Could make it risky to use their patch, if they don't take particular care
Thiago Macieira wrote:
> openSUSE has it:
> https://build.opensuse.org/package/show/openSUSE:Leap:15.1:Update/libqt5-qtbase
>
> But I recommend finding the other ones to see if any of them missed any
> backported fix.
Thanks, will try to see if Arch has one too (their equivalent for Qt4 didn't
On Thursday March 21 2019 20:49:21 Allan Sandfeld Jensen wrote:
> Just find the patch from one of the distros that did already did the
> backporting. There are at least two, but probably more.
Hah, thanks - that would have been a great answer to my initial question! ;)
You don't happen to
Thiago Macieira wrote:
>> 5.9's support ends in May 2019 (probably a bit later because we are able to
>> make the 5.9.9 release).
Where then are 5.9.8 and 5.9.9? http://download.qt.io/official_releases/qt/5.9/
still goes to 5.9.7 only.
R.
___
>> Actually, it doesn't: 5.9 support ends in May 2020, OpenSSL 1.0 in Dec 2019.
>
> You're off by one year. 5.9.0 was released May 29, 2017.
>
> (probably a bit later because we are able to
> make the 5.9.9 release).
That means some of the dates in the wikipedia article are wrong... but not the
>Because it is a major rewrite of QtNetwork code interfacing with OpenSSL. Such
>change
>cannot go to LTS branch [1]
Now maybe (though I'd argue this is a bug fix; OSSL 1.0 will go EOL 5 months
before Qt 5.9). But that was not the question.
5.9.0 was released on May 31st 2017
Konstantin Tokarev wrote:
> It would be better to upgrade Qt in MacPorts
MacPorts provides the latest and also a whole range of older Qt versions (down
to Qt 5.5 I think). It has to, because Qt doesn't support a sufficient range of
OS versions for our purposes.
> Which distribution already stopped shipping OpenSSL 1.0?
See my other email: for now this is for MacPorts, but I'm guessing Qt may not
want to depend only on an OpenSSL variant that's EOL.
Moving to 5.10 may be relatively trivial on Linux but not on Mac, if you want
to
keep supporting OS
>You should either use Qt >= 5.10 or build against OpenSSL 1.0.2
Wrong answer :P
If Qt 5.9 is still in LTS it should get commit
cfbe03a6e035ab3cce5f04962cddd06bd414dcea cherry picked from the dev branch
before 1.0 reaches EOL later this year.
Is that commit sufficient? Getting it to apply to
Hi,
I just learned that Qt 5.9 apparently doesn't build against OpenSSL 1.1 . Does
anyone already have a fix for this?
If not I'll try to adapt Debian's OSSL 1.1 support patch for Qt4; that might
even be upstreamable supposing there will be further Qt 5.9 releases ?
Thanks,
R.
Thiago Macieira wrote:
>
> Enabling the new dynamic tags is an option chosen at configure time for
> binutils. Looks like you have yourself to blame for not enabling the new tags.
> Yes, it's very specialised knowledge and you can be excused for not knowing,
> but this is what you get for
Thiago Macieira wrote:
> Use eu-readelf -d on one of your binaries or libraries and see if they have
> RUNPATH and RPATH entries.
I don't have eu-readelf, what package/project would that be part of?
I vaguely recall having a discussion about these things a few years back, I
think about how Qt
Thiago Macieira wrote:
Hi,
1
> more likely, a *library* difference: something may be calling
> QCoreApplication::setLibraryPaths(). instead of
> QCoreApplication::addLibraryPath().
I thought about that too, but can now say that I can indeed switch between the
2
behaviours simply by including
Hi,
I wanted to test something against a newer Qt version than my customised 5.9.7
build so I used the official installer to get 5.12.1 and wrote a little wrapper
that sets up LD_LIBRARY_PATH and QT_PLUGIN_PATH appropriately to run existing
binaries against this Qt version.
One hurdle: my
Hi,
What options are there to add widgets (e.g. a preview widget) to QFileDialog
instances or descendants, which will work with "native" dialogs?
I'm looking into an issue with Scribus where this is achieved by embedding the
entire QFileDialog instance into its parent, i.e. by setting it to be
On Friday February 22 2019 20:31:57 Jason H wrote:
>removeItem: Note: The ownership of widget remains the same as when it was
>added.
This is the part that isn't clear. "Ownership [as] when it was added", I
decided that this had to mean "before it was added" instead of "after it was
added"
On Friday February 22 2019 17:45:05 Jason H wrote:
>I am not 100% sure, it's been a while, but I would assume that the layout is
>not the true parent, combined is.
The docs aren't exactly clear on this subject, at least not with the sort of
reading glasses I usually have on when I don't
Hi,
Consider
```
SomeWidgetClass *a = maybeReturnSomeWidget();
SomeOtherQWidgetClass *b = maybeReturnSomeOtherWidget();
QWidget *combined = new QWidget();
QVBoxLayout *layout = new QVBoxLayout();
layout->addWidget(a);
layout->addWidget(b);
combined->setLayout(layout);
if (doWeLikeItCombined) {
Hi,
I just noticed something strange in the huge compiler commandlines you tend to
get while building KDE applications. An application configured to build with
clang adds qt5/mkspecs/linux-g++-64 to the header include path (with -isystem,
at that).
At first I thought this was an error in that
Thiago Macieira wrote:
> Almost all the compression libraries support streaming mode. Some will have a
I'm not aware of any libraries that apply HFS compression to a stream, but
above
all, I'm not aware of any way to write HFS resource forks incrementally. I
never
tinkered with them at this
Thiago Macieira wrote:
> Transparent compression is fine.
But that's only because there is also transparent decompression, otherwise
you'd
be in exactly the same boat.
Ultimately I don't think it matters where the compression takes place, in
filesystem code or in userland code. As long as
Marian Beermann wrote:
> The easiest way is probably a QIODevice wrapper implementing the HFS
> compression.
> Although I'm honestly surprised someone designed an
> interface like this. "Neither smart nor good" might be a ML-friendly way
> of putting it.
What interface?
The compression stage
Thiago Macieira wrote:
> where that is supported. Just get the file descriptor from QFile, do the
> ioctl/fcntl/whatever that turns the feature on and write the correct byte
> stream.
You realise that you're basically saying not to use QFile at all in this
application (there are cheaper ways to
Thiago Macieira wrote:
>> HFS compression in QFile would really be Mac-specific, most 3rd-party HFS
>> drivers for other OSes do not even support the feature.
>
> Then I don't see us supporting this in QFile.
Of course the feature doesn't have to support only HFS compression. There are
On Monday December 17 2018 22:35:23 Konstantin Tokarev wrote:
> I'm not sure about ZFS, but other mentioned file systems support per-file
> compression
> setting. In Linux this is done by setting FS_COMPR_FL flag in FS_IOC_GETFLAGS
> ioctl
Interesting, I didn't know about this. It certainly
Thiago Macieira wrote:
> How does that work? Is that just an ioctl, fcntl or a similar system call on
> the open file descriptor? If so, you can do it right now.
Unfortunately, no. Decompression is transparent like you'd expect from a
filesystem level for of compression, but you have to do the
Hi,
Is anyone aware of a QFile subclass (or comparable) that writes data using HFS
compression if the filesystem supports it (HFS+ and APFS)?
If not, and that's more of a question for the development ML: has thought ever
been given to make this an option in the QFile class itself?
Using HFS
Sérgio Martins wrote:
> FWIW, I just tried -flto with clang-7.0 and gold-1.16 and can't
> reproduce QTBUG-43556 anymore.
Good to know, I use the "regular" ld v2.3.0 (~gold for other reasons I cannot
really remember).
In the FWIW register: does clang 7 continue the trend of being noticeably
On Thursday November 08 2018 16:32:17 Allan Sandfeld Jensen wrote:
Thanks Allan, but you were a tad late to the party ;)
> Note however that newer QtWebEngine comes with the same platform limitations
> regardless of what Qt they are built against as QWE always have harder
> limitation due to
On Wednesday November 07 2018 14:48:30 Kai Koehne wrote:
> What we're trying to support though is building a newer qtwebengine.git
> against older Qt versions (usually last LTS).
>
> For your example with Qt 5.8 I'm not sure, because there were some
> configuration system changes that probably
Hi,
Out of curiosity, how feasible would it be to deploy a more up-to-date
QtWebEngine on a system that's stuck on an older Qt version. I understood from
a previous exchange that QWE is much more a "thin wrapper" around the actual
web engine than QtWebKit is, with the intention of making it
On Wednesday November 07 2018 11:13:29 Sérgio Martins wrote:
> Can you share a link to a LLVM or Qt bug report where you're expecting
> improvements ?
It was on this mailing list.
I haven't tried with Qt but I manage to use -flto with clang on Linux by making
sure a recent enough ld (and not
Thiago Macieira wrote:
> More importantly, the decompression times: gzip took 0.84s, zstd 0.30s and xz
> 2.81s. But bzip2 needed 6.6s.
I cannot reproduce those relative performance figures on neither of my
machines.
On a 95Mb directory I'm getting on my Mac (tar -c dir | $compressor $opts >
Thiago Macieira wrote:
> Off-topic: no one uses bzip2 anymore. It's slow to compress, slow to
> decompress and produces worse results than xz.
Xz is even slower, and on the machine these numbers came from that difference
is
more important in this case.
> Both are -O3 -march=native -g1 builds.
On Monday November 05 2018 16:34:31 Allan Sandfeld Jensen wrote:
>I build all of Qt regularly with clang to make sure qtwebengine works like
>that
Have you tried 5.9.x recently? I ran into an issue that appears to be known
(and fixed upstream) where gn fails to link because of missing
On Monday November 05 2018 12:03:31 René J.V. Bertin wrote:
>In my experience clang generates significantly more compact binaries
Quite: bzipped tarballs of everything except the examples, translations, QWE,
QtWebView and Qt3D:
-rw-r--r-- 1 root root 363M Sep 8 13:22
On Monday November 05 2018 16:50:10 Jean-Michaël Celerier wrote:
>it's just the release / dynamic configuration that crashes, and I don't
>know how to instruct Qt's configure to keep debug symbols for release
>builds of the tools in order to get a proper stacktrace.
I use these arguments to
On Monday November 05 2018 12:10:15 Jean-Michaël Celerier wrote:
> I tried building everything with clang 7 and libc++ last week but hit a
> qlalr segfault during build. I've been trying to debug it ever since to no
> avail.
Building with libc++ and the very latest Clang may just have been a
Hi,
Last time I asked the advice was still not to bother with trying to build (all
of) Qt with clang on Linux. Is that still the case or is it now safe to use
clang (5 or 6)?
In my experience clang generates significantly more compact binaries, which
should reduce load times. Build time
Thiago Macieira wrote:
>> delivered. I can fix that by forcing a Qt::DirectConnection, which seems to
>> be signal safe (according to a sig_atomic_t state "inSignalHandler" var)
>> but is it?
>
> QMetaObject::activate() locks a mutex, so it's not async-signal-safe. That
> means you cannot emit a
On Friday October 19 2018 16:11:34 Jason H wrote:
> There are two ways:
> By direct invocation (same thread only)
> Or
> By inserting an event into an event loop of the appropriate thread (same or
> different thread).
> Queued connection just ensures that if direction invocation is available,
Does Qt serialise slot calling, iow, will it queue signals emitted and deliver
newer ones only when the previous slot invocation completed?
Qt::QueuedConnection does kind of suggest it might, which begs the question if
there's a way around that in this situation?
Context: my graceful exit
On Tuesday October 16 2018 06:47:04 Kai Koehne wrote:
>There's a good chance this got fixed in Qt 5.12:
>
> https://codereview.qt-project.org/#/c/203587/
Ah! I was already building the Assistant from the dev branch (against Qt 5.9
currently) so I should be able to test this (but only in the
1 - 100 of 667 matches
Mail list logo
