On 12/6/19 7:02 PM, Richard Weickelt wrote:
By the way: does anyone know about an implementation that avoids moc runs in
a similar way how ccache avoids compile runs ?
You mean concatenating header and source files containing a Q_OBJECT macro
and feeding moc the result?
No - the ideas would
On 11/22/19 2:14 PM, Roland Hughes wrote:
There have been many requests over the years to allow QPainter
operations outside of the primary thread. In particular for running
graphs like heart rate monitors which are just a brick on the screen the
user generally cannot interact with.
With X11
On 12/6/19 9:48 AM, Giuseppe D'Angelo via Interest wrote:
This trick is used in several places in Qt itself (look for "includemoc"
in commits). Not only it helps build times but also it produces slightly
better code overall.
By the way: does anyone know about an implementation that avoids moc
On 12/6/19 2:09 AM, Adam Light wrote:
Does anyone else have any ideas of how we could change our build to
improve moc performance when Windows decides to be "slow"?
Something you can try is to include the moc file at the end of your cpp
file. This can be done like this:
#include "moc_XYZ.cpp"
On 10/9/19 5:32 PM, Thiago Macieira wrote:
All cases are good. It just depends on how much you pay.
Today:
"If you have already started the development with an open-source version
of Qt and wish to move to a commercial license you need to have a
written explicit permission from The Qt Compa
Hi Tuukka,
This is not about making closed source applications with LGPL
licensed Qt, or whatever kind of business is done with such.
Of course this thread is also about these options - I'm criticizing
the way how the Qt Company tries to prevent users from taking this route.
The point is that
On 10/8/19 7:13 PM, Ilya Diallo wrote:
In the latter case, the rational is (I guess) to prevent a company,
say, to work with 20 developers for 3 years on an OSS Qt license,
then switch to commercial when it's time to ship the product and the
team is reduced to a core maintenance crew. That lat
On 10/8/19 1:21 AM, Melinda Seifert wrote:
You can use commercial if you previously used Open Source but it’s on
a case by case basis and you need to get approval from the Qt
company.
Like you need to get approval from the Qt company when not having been
Open Source before - it is the basic r
On 10/6/19 12:03 PM, Giuseppe D'Angelo via Interest wrote:
Hey, I linked it two emails ago :-)
Ah yes, sorry.
My response was initially more explicit about FUD, before I decided,
that it is not worth the effort.
Uwe
___
Interest mailing list
In
On 10/5/19 7:57 PM, Giuseppe D'Angelo via Interest wrote:
Anyhow: please direct these comments to your Qt sales representative;
this is NOT a sales mailing list (in other words, chances are high that
no one from sales ever reads these messages).
Asking sales people if you don't need to buy a
On 9/30/19 4:43 PM, Thiago Macieira wrote:
It's not advisable to use nested event loops.
It is not the first time that you gave this warning, but something like
QDialog::exec is simply too handy for GUI development.
Of course there are known side effects, but IMHO it should be the job of
a
Spam detection software, running on the system "mx.qt-project.org",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
C
On 9/10/19 5:42 PM, Giuseppe D'Angelo via Interest wrote:
https://bugreports.qt.io/browse/QTQAINFRA-3072
Looks like something has changed - at least my previous mail was not
marked as spam anymore. Instead I received an email with this information:
"You are not allowed to post to this maili
On 9/10/19 3:08 PM, Alexander Ivash wrote:
Under what conditions? I mentioned that Quick Controls 2 is a must to
make behaviour more deterministic.
F.e QTextInput ( QC2 has nothing to with it ) is completly done in C++
and if you are willing to include private headers ( not private in the
me
Spam detection software, running on the system "mx.qt-project.org",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
C
Spam detection software, running on the system "mx.qt-project.org",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
C
On 3/21/19 2:36 PM, René Hansen wrote:
And it's not all too bad, but if anyone can tell me of a more dogmatic
QtQuick based approach, please let me know.
Qt/Quick applications are always a combination of C++ and QML and making
use of the C++ part is absolutely not bad.
If something is wrong
On Fri, 22 Feb 2019 22:27:49 +1300, Christian Gagneraud wrote:
> If you do not want to support qreal=float anymore, please do not allow
> ./configure to make that choice and maybe get rid of qreal typedef,
> and delete qreal from Qt6 API while you're at it.
Actually there are several versions of
On Thu, 20 Dec 2018 20:27:30 -0200, Thiago Macieira wrote:
> I understand you're working with 4.8. I don't care.
I participated in one of the marketing road shows of the Qt company in
Munich/2017: one of the speakers asked the audience which Qt version they
are using.
I don't have exact number
On Mon, 05 Nov 2018 14:41:11 +0100, Giuseppe D'Angelo via Interest wrote:
> Didn't you hear from Microsoft? They went from being the
> slowest adopter to the fastest -- to this date, MSVC 2017.7 is the
> _only_ C++ compiler that supports the entirety of C++17! That indeed
> shows their commitment
Hi Guiseppe,
> (The topic is still "how to port Qt to another platform".)
It is in the nature of discussions, that they might change direction -
like it happened with the AGILE side track.
> (Yes, I 100% agree that QtQuick could be modularized much further, e.g.
> drop its dependency from QtQm
On Thu, 27 Sep 2018 18:03:55 +0200, Giuseppe D'Angelo via Interest wrote:
> This is another blatant false statement, because you can port just the
> parts of Qt that you need, and even those can be further trimmed down
> using the feature system. (That's actually how you would do a port in
> the f
On Thu, 21 Jun 2018 11:51:59 +0200, Massimiliano Maini wrote:
> I'd need to do something like this: https://imgur.com/MLAEuad
>
> I have a set of (x,y,z) data points and want to plot them on a usual 2d
> plot ( x and y values), but with the line color depending on the z
> values (colormap).
Qwt
On Thu, 15 Mar 2018 14:17:00 +, Shawn Rutledge wrote:
> That sounds interesting. What format do you want to precompile them to?
Well, as all we need is to restore the members of a class exactly, like
they have been in memory, before we wrote them to disk, there should be a
way to do this w
On Thu, 15 Mar 2018 14:26:41 +, Shawn Rutledge wrote:
>> I see that Uwe has pointed out a performance issue which can happen
>> because of multiple renderings due to size changes. Is that it? Or are
>> there other reasons behind preferring PNG icons over SVG?
>
> I think it’s mainly that SVG
On Wed, 07 Mar 2018 20:55:03 +0100, Jason H wrote:
> How is QPicture not appropriate for SVG?
At the time, when Qt changed its APIs from integers to doubles ( Qt 4 )
QPicture::boundingRect() was forgotten, what makes layouting of scaled
pictures too inaccurate.
Another important detail are non
Hi Shawn,
> It should also be considered a bug IMO.
The only obvious part of the whole disaster that IMO qualifies as a "bug"
is the fact, that binding a size ends up in 2 calls - but AFAIK this is
not specific to QQuickImage.
Maybe one could say, that QQuickImage shouldn't do any updates befo
On Tue, 06 Mar 2018 16:55:23 +, Nuno Santos wrote:
> I just had to add it to resources and pass it to the image element.
Using Image works, but its implementation is far from being optimal in
combination with SVGs. For small applications with only few SVGs this
might be no problem, but when
On Thu, 22 Feb 2018 13:54:39 +, Jérôme Godbout wrote:
> I for one would go Qml, since it's the new thing with more development
> on it, which seem more future proof.
On the developer mailing list it has been recently announced, that Quick
Controls 1 is going into deprecated mode.
So at leas
On Wed, 17 Jan 2018 11:59:41 -0800, Thiago Macieira wrote:
> True. Maybe it has never occurred to them that the API would be needed.
> You can help make it happen by adding this API yourself too.
In the case of QSkinny we are not talking about some APIs it is a
fundamentally different philosophy
On Wed, 17 Jan 2018 09:34:54 -0800, Thiago Macieira wrote:
> It is just sharing code. The important difference is that both modules
> are developed at the same time and released at the same time, by the
> same team.
Yes of course, but my project is developed at a different time, released
at a di
On Wed, 17 Jan 2018 23:19:57 +1300, Christian Gagneraud wrote:
> Why do you need private headers in the first place?
For the same reason, why a module like QuickControls 2 is using private
headers of Quick Core.
The qskinny project is about creating a C++ framework ( QML is only
optional ) wi
On Wed, 17 Jan 2018 08:25:35 +, Mitch Curtis wrote:
This how I do it ( see https://github.com/uwerat/qskinny ):
QT += quick quick-private
CONFIG += no_private_qt_headers_warning
To get rid of warnings from Qt headers, when doing pedantic checks I also
have the following lines:
linux {
On Fri, 20 Oct 2017 09:14:09 +0200, Vlad Stelmahovsky wrote:
> I've created much more complex apps using QtQuick 1 on HW much weaker
> than RPi2 (Symbian phones) w/o such laggin as in this simple calc
> example. Obviously, there something wrong with code and/or system setup
A simple push button i
On Thu, 19 Oct 2017 08:06:26 -0500, Roland Hughes wrote:
> 1) It's QML ...
In case you prefer using the Qt/Quick graphic stack without QML you might
be interested in what I'm working on: https://github.com/uwerat/qskinny.
In fact the heaviness of Qt/Quick is not only QML related and I had/have
On Thu, 05 Jan 2017 16:58:00 -0500, Mike Jackson wrote:
> After reviewing the responses and doing some more research online we
> decided to stick with the traditional QWidgets
IMO the only reasonable choice for a classic desktop application ...
> ... for our desktop app but
> get away from the Q
On Sat, 17 Sep 2016 21:20:43 +0100, Sérgio Martins wrote:
> Please state your top ones, even if it was already stated by someone
> else, so we have an idea about which ones matter more.
a) C++ ( far beyond everything else )
The 2 language approach is a pain. In our application we have thousands
On Wed, 03 Aug 2016 13:41:51 -0700, Thiago Macieira wrote:
> It's still a source of errors because the nesting counter can be
> incremented in different ways, depending on what triggered the event. So
> the recommendation remains: avoid nesting like the plague.
void doIt()
{
...
int opti
On Tue, 19 Jul 2016 15:45:44 +0200, Jean-Michaël Celerier wrote:
> Is there some code somewhere ?
Sure on my disk ;)
Being serious: the code is supposed to be available under an Open Source
License, but it needs to have an initial level of quality first. And
there is still a long way to go.
B
On Tue, 19 Jul 2016 11:10:26 +0200, Benjamin TERRIER wrote:
> * you can't even create ...
As I'm currently working on a library offering Quick Controls with an C++
API ( having a QML API as well ) I already have some experience in what
it means.
The very first thing you will notice is that the
On Fri, 08 Jul 2016 18:51:47 +0200, Giuseppe D'Angelo wrote:
> This seems _very_ interesting and worth researching, are you going to
> share some results during the QtCon session you mentioned earlier?
When time has come I will release my package under a Open Source License,
but I first need to
On Fri, 08 Jul 2016 10:19:14 +0100, Giuseppe D'Angelo wrote:
> I think the question was more about measuring CPU and GPU performance
> than memory.
Yes, but as we don't have any problems with the performance of the render
engine we never benchmarked it. And our problem - the time spent for
crea
Hi Sean,
> So what were the results of profiling? CPU usage caused by
> animations/batching, something else? GPU? Bandwidth? Lock contention?
The first time we reported the issue was 2014: https://bugreports.qt.io/
browse/QTBUG-43096. At that time we had to migrate back to Qt 5.1.
When Qt 5.6 ca
On Wed, 06 Jul 2016 18:10:37 +, J-P Nurmi wrote:
> Interesting choice. I would have done the exact opposite. Application
> logic in C++ and UI declaration in QML.
Well this is actually not a choice - we did it in QML and ended up with
a disappointing performance, because of QML. And we did
On Tue, 05 Jul 2016 23:58:48 -0700, Thiago Macieira wrote:
> So what you want isn't QWidget with OpenGL support. We've proven it
> won't work. What you want is a powerful, Scene Graph-based set of
> widgets with native look and feel (that is Qt Quick Controls).
>
> You're probably also asking for
On Wed, 18 May 2016 15:57:04 -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> Now if I add a lot of straight lines (QGraphicsLineItem instances)
> performance (number of movements seen on screen per second) varies
> according the zoom. If I zoom in I get to a point in which everything is
> too
Hi all,
I'm trying to create an application with several QOpenGLWidgets ( no
regular QWidgets involved ), where some of them are on top of others.
My first results are promising, but I couldn't find out how to enable a
transparent background for the widgets on top. I would like to have a
similar
On Fri, 08 Nov 2013 11:47:36 +0100, Bo Thorsen wrote:
> With a 7 year old board, this is what you can expect to start hitting.
> It's so old, that you just can't expect brand new software to run on it.
The strategy of Qt5 is to introduce a new graphic stack but also to keep
the old old one alive
On Wed, 06 Nov 2013 08:03:47 -0800, Thiago Macieira wrote:
>> Shouldn't they be in Qt5OpenGL.dll?
>
> No, they are where they were supposed to be. That's by design.
With some nasty consequences for us users:
Our applications run on several pieces of embedded hardware, where one of
them had bee
On Fri, 27 Sep 2013 11:20:24 -0700, Thiago Macieira wrote:
> The Qt development team grew
> considerably during the Nokia time (which is a good thing of that time
> too), faster than the commercial business.
The insane growth of the Qt development happened before - in the TrollTech
days. From th
On Thu, 26 Sep 2013 14:13:33 -0400, K. Frank wrote:
> Did this "detour" (for lack of a better word) end up being helpful?
Nokia was not interested in the desktop and the previous user base. IMHO
this had 3 effects:
a) LGPL
Good and bad: the business case of selling support licenses is dead
(
On Sat, 23 Mar 2013 09:25:11 -0700, Thiago Macieira wrote:
> You may have heard stories about Wayland and whether it's ready for
> desktop usage. That's irrelevant... it's ready for embedded use already
> and has been for a year.
I have to make a platform decision ( unrelated to Qwt ) in the fol
>> I'm not using X11 at the moment, so it doesn't matter much to me,
>> but this sounds like a significant issue.
>
> Note that you will *not* see that regression if you're coming from Qt
> 4.8. The raster engine is the default in 4.8 already. The native engine
> was default in 4.7 and before.
Hm
On Fri, 25 Jan 2013 11:11:57 +, Mojmír Svoboda wrote:
> but WA_PaintOutsidePaintEvent does not exist anymore
What was useful for the X11 paint engine that doesn't exist in Qt5
anymore.
As your code snippet seems to be copied from Qwt sources you can have a
look at Qwt 6.1 to see how it is
Hi,
I have to admit that I completely missed the existence of the installer
framework so far. Before starting further investigations, please let me
ask if it is a possible solution for me:
I'm maintainer of the Qwt ( http://qwt.sf.net ) library and thought about
offering binary packages that a
On Fri, 16 Nov 2012 09:14:44 +0100, Sam Van Gucht wrote:
>> But my application crashes when I create a QApplication. It crashes in
>> the function QXcbConnection::xi2SetupTabletDevices, when the function
>> XIQueryDevice is called.
>>
>> Did anyone have the same problem or knows a solution?
Happe
On Sat, 28 Apr 2012 10:53:03 +0200, Cyril HAENEL wrote:
> Thus what I need is just a QT app which simulate a TFT screen by
> creating an 480x272 image in which ...
Are you trying to reinvent qvfb ( http://qt-project.org/doc/qt-4.8/qvfb.html ) ?
Uwe
_
On Wed, 11 Jan 2012 22:08:45 +0100, Pier Luigi wrote:
> Have you ever eard of the Haiku Vector Icon Format [*]? Seems best
> suited for icons than SVG.
No, but something like this would be fine.
But the main issue is, that Qt doesn't offer a scalable paint device like
a QImage - what we have to
On Wed, 11 Jan 2012 15:07:33 -0200, Thiago Macieira wrote:
> It would have helped in the scenario I had in my head, which is that the
> sizes are fixed per device.
To make my point: all I need is a scalable vector format, but it doesn't
need to be SVG. Actually SVG is by far not optimal ( slow X
On Wed, 11 Jan 2012 14:05:40 -0200, Thiago Macieira wrote:
> Can't you pre-rasterise the files and store them on the device's image?
> Sounds like a much better solution to me.
The sizes of the icons are the result of the calculation of QLayouts - I
don't know them in advance. They might even ch
On Wed, 11 Jan 2012 11:35:15 -0200, Thiago Macieira wrote:
> A device with limited resources but powerful enough that rasterising SVG
> on the fly isn't an issue?
It is - but as our layouts are fix during the runtime of the application
this only has to be done once. Later the icons are taken fro
On Tue, 10 Jan 2012 09:42:05 -0800, Chris Meyer wrote:
> I extracted this code from my source to convert SVG to QImage using
> QtWebKit. It's untested in this specific form, but should give you the
> idea.
Well this code requires a QGraphicsWebView and QGraphicsScene object -
meaning even one mo
62 matches
Mail list logo
