Before going to a binary format, I’d first like to check whether we can further
speed up the parsing. I’ve done some work in that area in spring, but I know
there was still quite some room to improve it.
Cheers,
Lars
From: Jiergir Ogoerg f35f22...@gmail.commailto:f35f22...@gmail.com
Date:
On Thu, Oct 31, 2013 at 1:42 AM, Thiago Macieira
thiago.macie...@intel.comwrote:
Should we consider so, how about undeprecating API before Qt 6.0
deprecated
in Qt 5.X?
Undeprecating API is fine.
Thanks.
___
Development mailing list
Hi,
I dislike those because we're incurring overhead at shutdown to do
something
that doesn't need doing, except to keep tools happy.
For the platform printer support, it makes sense since it can
potentially have handles open or similar. Not sure about the ICU leak,
though?
Regards,
There is already a caching mechanism in place for the Compose file,
can we make use of that? -
http://kdemonkey.blogspot.co.uk/2008/04/magic-trick.html
On 31 October 2013 07:38, Knoll Lars lars.kn...@digia.com wrote:
Before going to a binary format, I’d first like to check whether we can
Hi,
i agree and for the ICU part. Calling u_cleanup will free resources owned
by ICU libraries. Converters used by Qt are already properly released so
this is not an Qt issue.
From ICU Api help: The use of u_cleanup() just before an application
terminates is optional, but it should be called
-Original Message-
From: development-bounces+kai.koehne=digia@qt-project.org
[mailto:development-bounces+kai.koehne=digia@qt-project.org] On
Behalf Of Luka Vilar
Sent: Thursday, October 31, 2013 12:22 PM
To: Kleint Friedemann
Cc: development@qt-project.org
Subject:
Le 31/10/2013 12:29, Koehne Kai a écrit :
I'm not completely opposed to calling u_cleanup(), but we've to keep in mind
that ICU API might get called very late (e.g. even in destructors of static
objects, when someone decides to add say a qDebug() there). What happens if I
call ICU API after
The .compose-cache file stays empty even after a few reboots.
Using Fedora 20 KDE version, 64 bit.
I noticed the post is 5+ years old, has it been tested on
(modern) Fedora and does it still work with modern versions of Kubuntu?
Particularly, what should I do to make it work on Fedora (20)?
On quinta-feira, 31 de outubro de 2013 12:21:46, Luka Vilar wrote:
i agree and for the ICU part. Calling u_cleanup will free resources owned
by ICU libraries. Converters used by Qt are already properly released so
this is not an Qt issue.
Let me ask you this:
what happens if Qt was loaded by
On quinta-feira, 31 de outubro de 2013 07:38:00, Knoll Lars wrote:
Before going to a binary format, I’d first like to check whether we can
further speed up the parsing. I’ve done some work in that area in spring,
but I know there was still quite some room to improve it.
I'm also improving the
On quinta-feira, 31 de outubro de 2013 15:57:13, Cristian Pallarés wrote:
Hi folks,
https://codereview.qt-project.org/60346
I've waited quite a bit for this feature. C++11 already ships this
implementation, which makes std::shared_ptr very powerful, but the review
process for the Qt
Great, of course you're a much better/smarter programmer than me,
but how much time of the whole parsing and loading
(which is done line by line which is slow) does fromUtf8()
take? If it's only like 10-20% then even if it's optimized to work 10 times
faster in the end it's a much smaller
I noticed the post is 5+ years old, has it been tested
on (modern) Fedora and does it still work with modern versions of Kubuntu?
I haven't tested it myself recently and I have no idea whether it
works with current versions of Ubuntu or whether
it ever worked on Fedora.
Regards,
Rob.
On 31
Am Donnerstag, 31. Oktober 2013, 17:52:28 schrieb Jiergir Ogoerg:
Great, of course you're a much better/smarter programmer than me,
but how much time of the whole parsing and loading
(which is done line by line which is slow) does fromUtf8()
take? If it's only like 10-20% then even if it's
Hi,
I'm trying to port KDAB's DeclarativeWidgets[1] to Qt5. I've got it running
for trivial QML files, however as soon as there are child widgets the
running program aborts.
The abort is caused by QObject::setParent, which contains this little gem:
Q_ASSERT(!d-isWidget);
Apart from not
I'd argue that it's setParent with the bug. It's conceptually valid to
have a QWidget with a QObject parent but no QWidget parent, but it
won't really show up until you try to use them in QML. If you do this
with non-QML QWidgets, then it won't show up on screen so the user
will think they've made
16 matches
Mail list logo
