On Fri, 23 Mar 2018 13:44:03 +, Mitch Curtis wrote:
> As I understand it, clipping (the "clip" property) doesn't prevent items
> that aren't visible (in the sense of being out of the viewport, not the
> "visible" property) from actually being rendered.
In my framework ( https://github.com/uwe
Hi all,
this morning I got a notification about
https://bugreports.qt.io/browse/QTBUG-43096
being closed. I guess many applications had been hit by this issue, but
as I was related to the project that created this bug I would like to
give my summary of what has happened since then:
a)
On the Qt
Hi Robin,
> From my own perspective, I think Controls 1 was a well-intentioned ...
Agreed and to be honest I'm really impressed about what was doable in QML,
but it also showed where its limitations are.
But at the time, when Controls 2 has been started everything was on the
table and - at lea
On Fri, 25 May 2018 14:30:05 +0200, Robin Burchell wrote:
> I have over the years avoided using QQC1 in several projects as
> I knew that the performance simply wasn't up to the task without ever
> trying it "seriously", instead developing custom controls ...
Please let me give a detailed answer
Hi Robin,
> Why does it need to be? I have never needed to subclass QQuickControl,
> personally, so I have never brought this topic up.
For the same reason all other controls from QC2 do subclass it. If you
want to participate in mechanisms ( like font/locale/palette propagation
) that are impl
On Fri, 25 May 2018 22:35:58 +0200, Robin Burchell wrote:
> The first point I would make in reply, though, is
> that the convenience of creating code with a/b/c are going to be
> significantly better in my experience.
Code for d) look like this:
https://github.com/uwerat/qskinny/blob/master/examp
On Sat, 26 May 2018 12:05:38 +, Simon Hausmann wrote:
> P.S.: Are you sure the stops: [ ... ] assignment works?
You are right: I forgot to mention this extra piece of code:
QMetaType::registerConverter< QJSValue, QskGradientStop >(
[] (const QJSValue& value) -> QskGradientStop
Hi Simon,
> I ran benchmarks comparing a release build of 5.12 against 5.1.1 and ran
> the benchmark mentioned in the task, where Qt 5.12 came out in average
> faster by a factor of 4.
Christophers comment in the JIRA ticket raises some questions concerning
the correctness of those benchmarks.
Hi Tomek,
> I quickly reviewed QSkinny and it really nicely exposes C++ to Qml. I
> can't see however, how you made e.g. QskVariant::stops readable from
> Qml. Writing stops is possible due to QMetaType::registerConvertes, but
> how you can iterate overs stop from Qml?
Don't know either, but I'm
Hi all,
when working on our virtual keyboard I had to realize that the design of
QInputMethod is inappropriate to achieve what we need:
a) the input method is tied to the item having the focus
We have a touch screen but also an special input device, that offers a
wheel to navigate along the fo
Hi Simon,
> But my initial guess is that this isn't an inherent design
> problem of the input method API.
Well, one problem is that the input context needs to know about the
current item, as it has to correspond with it. But QInputMethod::show/
commit/reset/update/hide do not transfer any inform
Hi Simon,
> While it's true that show(), etc. don't have the focus object as a
> parameter, you do have a three ways
Yes, sure: show() is not the problem.
( We also have situations, where the virtual keyboard is started by
pressing a button, while the input should go to some sort of label
On Fri, 06 Jul 2018 08:50:44 +, Shawn Rutledge wrote:
> But there’s the
> trend of using image-based styles more, which contributes to the
> annoyance that you don’t actually have system-wide control over colors
> and styles.
At least for Qt/Quick I'm not sure if this a trend Qt has created b
On Wed, 29 Aug 2018 16:43:40 +0300, Denis Shienkov wrote:
> So, there are no way to improve an acceleration and to minimize the CPU
> loading?
It depends on the requirements of your application, but when it comes to
oscilloscope alike widgets your best choice is Qt4/X11.
The X11 paint engine is
On Thu, 30 Aug 2018 14:26:34 +0300, Denis Shienkov wrote:
> Yeah, seems that Qt5 && X11 && 'xcb' backend with the Qwt 6.2 and
> QwtPlotOpenGLCanvas does help a bit. The iMX6 CPU usage now is ~50%
> (instead of previous 100%).
I have been attending one of the Qt roadshows last year in Munich. One
On Thu, 30 Aug 2018 14:26:34 +0300, Denis Shienkov wrote:
> Yeah, seems that Qt5 && X11 && 'xcb' backend with the Qwt 6.2 and
> QwtPlotOpenGLCanvas does help a bit. The iMX6 CPU usage now is ~50%
> (instead of previous 100%).
A small correction for others reading this: trunk is Qwt 6.3. The main
On Thu, 30 Aug 2018 07:50:41 -0700, Thiago Macieira wrote:
> The result of (b) is a retained-mode scene graph. It's in the QtQuick
> library.
I know, but now we have Qt 5.11 and it is fair to review this result:
the API of the scene graph - as it is today - is so far from offering a
comparable
On Thu, 30 Aug 2018 15:47:34 -0700, Thiago Macieira wrote:
> You can always just use QPainter on a QPixmap and paint that pixmap on
> your QSGPaintedItem. It won't be particularly fast, but it will work and
> do what you asked.
After some conversation with Denis: the use case of this thread is a
On Sun, 02 Sep 2018 14:48:37 +0200, Jean-Michaël Celerier wrote:
> For this kind of work I'd recoment QNanoPainter, ...
I also gave this hint to Denis - without having any experience with it
myself. When I have more time I will check if its is possible for Qwt to
benefit from this backend.
Do
On Thu, 30 Aug 2018 07:50:41 -0700, Thiago Macieira wrote:
>> From my experience with the QSkinny project I'm tempted to say that it
>> would even be possible to implement the Qt/Widgets API on top of
>> Qt/Quick core.
>
> So long as you ditch the paint event for most of the classes, leaving
> th
On Mon, 03 Sep 2018 16:38:51 +0200, Simon Hausmann wrote:
> ... it's not necessarily a
> good overall investment of time when the scene graph provides a better
> opportunity to get closer to the theoretical maximum of performance - by
> design.
In German we have the phrase: "Besser ein Spatz in d
On Mon, 03 Sep 2018 12:39:22 -0700, Thiago Macieira wrote:
> Your criteria for "competitive" are different than the maintainers'.
I was referring to the work of Gunnar and Kim, but comparing X11 with
Raster and the quality of the implementation of the Raster paint engine
are interesting topics
On Tue, 04 Sep 2018 12:21:29 +0300, Denis Shienkov wrote:
> Uwe,
> what if I try to back-port my application from Qt5 to Qt4 with X11
> support (on iMX6).
This is what I would try first in a situation like yours. Don't forget to
set the graphic system to "native" - the default since 4.8 is raste
On Tue, 04 Sep 2018 14:38:47 +0300, Denis Shienkov wrote:
> How I can do it for Qt4? Do you mean, I need to specify an appropriate
> '-platform' option before starting of my application on Qt4?
https://doc.qt.io/archives/qt-4.8/qapplication.html#setGraphicsSystem
You can even run opengl as back
On Tue, 04 Sep 2018 20:51:38 +0200, Martin Koller wrote:
> added the native X11 graphicssystem support from Qt4 to Qt5
Very cool.
Andrew told me that there were 2 concurrent attempts to revive X11 as the
situation for running widget applications on remote desktops is simply
not good, when usin
On Wed, 05 Sep 2018 09:56:36 +0100, Sérgio Martins via Development wrote:
>> What needs to be done to make it become effective ?
>
> export QT_XCB_NATIVE_PAINTING=1
I did a quick check with using QPainter on a QPixmap and indeed it runs
the X11 paint engine. Using Qwt with a current Qt version
On Wed, 05 Sep 2018 13:04:39 +0300, Denis Shienkov wrote:
> Uwe, wow :) What Qt5 version are you use?
Seems to work with Qt5 >= 5.10.
Uwe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Wed, 05 Sep 2018 09:55:41 -0700, Thiago Macieira wrote:
>> It also raises questions about the status of the X11 paint engine.
>> Several bugs have been closed because of not fixing the X11 paint
>> engine anymore.
>
> This being the reason why the X11 engine is not good for everyone.
O.k. - b
On Mon, 10 Sep 2018 16:30:32 +0300, Denis Shienkov wrote:
> but I don't see any differences using the QT_XCB_NATIVE_PAINTING=1 or
> without of it.
> The CPU usage still is a big ~71% in both cases.
As long as you are updating the tick labels 10 times a second I would
expect, that you have a CPU
On Wed, 24 Oct 2018 07:17:09 +, Ulf Hermann wrote:
> Please review it.
Qt Community, Qt Contributors, Qt Project, Qt Company - these are
different things and whenever I see someone who is speaking in behalf of
the Qt project I'm wondering who is actually speaking.
The document already has
On Mon, 29 Oct 2018 00:53:01 +0100, Lydia Pintscher wrote:
> PS: As someone on the fringes of the Qt Project some emails in this
> thread sadly make me see part of the project in a different light.
I'm not too much interested in the topic of an CoC - not even in the
discussion about it - but tha
On Tue, 30 Oct 2018 09:59:28 +0100, Olivier Goffart wrote:
> What Lars said, if I read the email properly, is that the Qt Company
> does not see a business value in developing it further.
Yes and this is relevant if it is relevant for the maintainers of Qbs. Do
we have a statement from them so f
On Mon, 29 Oct 2018 18:46:18 +0100, Olivier Goffart wrote:
> In Qt5, we also need the name for the string-based connection syntax.
I'm not sure if I'm ontopic for the Metatype system with my comment, so
please excuse me if I'm hijacking this thread for a moment.
I have this code:
https://githu
On Tue, 30 Oct 2018 19:24:26 +, Adam Treat wrote:
> Lars gave a keynote saying pretty much the same. Simply is not true that
> we are planning major source compatible breakage for Qt6 so let's stop
> saying that.
When will the already deprecated QQuickControls 1 module going to be
finally re
On Thu, 01 Nov 2018 10:24:16 +, Tuukka Turunen wrote:
> Things can always be improved, and constructive feedback is always
> welcome.
The bottom line of this all is of course the fundamental question if the
Qt Project is intended to be more than simply a way how to contribute to
the product
On Thu, 01 Nov 2018 11:23:31 +, Tuukka Turunen wrote:
> Of course mailing list discussion is also completely fine.
It is more than that: it is the place where all fundamental decisions
concerning the Qt project ( like f.e. deprecating modules ) have to be
announced and discussed first - bef
On Mon, 05 Nov 2018 21:31:26 +0200, Konstantin Shegunov wrote:
> 1) Is parenting to the application object a thing?
The title of the bug report is about QCoreApplication, while the demo
code is a QApplication - so I'm not 100% sure if I completely understood
the discussion.
But at least for QA
On Mon, 12 Nov 2018 10:29:15 +0300, Valerii wrote:
> Sometime need to use Qt 5.6, ...
Qt 5.6 is LGPL V2, what means the Qt company ( ~= Qt Project ) has a
strong interest in not supporting it - especially for environments where
yocto is made for.
So if your platform wants to make a LGPL V2 of
Hi all,
I just received 2 messages about: automated bulk change closing old
issues in the "Need more info" state.
- https://bugreports.qt.io/browse/QTBUG-68874
- https://bugreports.qt.io/browse/QTBUG-66264
I have no idea why they have been set to "Need more info" - actually one
of them has bee
On Mon, 19 Nov 2018 16:36:45 +, Shawn Rutledge wrote:
> Also, every week we have a team of 2 people triaging bugs. Part of that
> job is to check all the bugs that are in “need more info” state, and
> decide whether the info is now sufficient.
In the case of my bugs: in one of them it is tot
On Mon, 19 Nov 2018 20:00:30 +, Volker Hilsheimer wrote:
> I understand that the “need more info” -> auto-closing bot workflow is
> to some degree a bit of a probe to see if someone still cares.
A bug is a bug and if the one who has reported it has lost the interest
in it months/years later
On Thu, 10 Jan 2019 07:24:01 +, Frederik Gladhorn wrote:
>> Ours is LGPLv2+ as usual, FWIW.
>
> Which sadly makes it unsuitable for inclusion in Qt.
I'm maintainer of the Qwt library ( https://qwt.sourceforge.io/ ), that
exists since Qt 1.1 - but there are also other popular Qt plotting
li
On Thu, 10 Jan 2019 10:48:37 +, Tuukka Turunen wrote:
> Related to your comment about the Qt Charts being limited I would tend
> to disagree.
https://www.qtcentre.org/threads/69718-QChartView-and-QScatterSeries-
overrdide-the-label-of-a-QPointF
https://www.qtcentre.org/threads/69094-3D-Plot
On Thu, 10 Jan 2019 13:24:14 +0100, Vlad Stelmahovsky wrote:
> Qwt is nice but supports only QWidgets, right?
True, but Qt/Charts is also QWidgets only.
Uwe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/
On Thu, 10 Jan 2019 14:21:59 +, Kari Oikarinen wrote:
>> True, but Qt/Charts is also QWidgets only.
>>
> Not quite: https://doc.qt.io/qt-5/qtcharts-qmlchart-example.html
According to https://code.woboq.org/qt5/qtcharts/src/chartsqml2/
declarativechart_p.h.html this is a wrapper around QChart
On Fri, 11 Jan 2019 09:16:12 +0100, Samuel Stirtzel via Development wrote:
> There is a property that enables OpenGL rendering for _some_ plots
What will work when using QChart as QWidget, but I would assume that it
does not have any effect for the QML path - QPainter on QImage is
hardcoded in
Hi,
all arguments for doing Continuous Integration for Qt ( https://
blog.qt.io/blog/2016/08/08/coin-continuous-integration-for-qt/ ) are also
valid for 3rd party code using Qt.
F.e. with Qwt ( https://qwt.sourceforge.io ) I'm supporting trillions of
environments I have never seen myself. Actua
Hi,
thanks for the all the hints in this thread - I will check them if I
can't find a service, that is more specific:
a)
The very first of my problems is to know about the platforms I need to
test. I guess the list of all operating system and compiler combinations
can be found somewhere in th
Hi all,
in the end all advice goes into the direction of using one of the
standard services in combination with using my own brain when working on
the code.
Unfortunately nobody pointed out a realistic way how a 3rd party project
could make use of the infrastructure used by the Qt project nor
On 3/22/19 5:19 PM, Denis Shienkov wrote:
My goal it is to accelerate my QWidget application in some way... I
use the QWT library to render a curves..
When setting QT_XCB_NATIVE_PAINTING ( Qt >= 5.10 ) you are usually
running into an hardware accelerated path, that is much faster, than
what yo
On Fri, 22 Mar 2019 19:06:24 +0300, Denis Shienkov wrote:
I'm trying to build a Yocto image, but the config tests fails on
'executing config test egl-x11' test with:
We have an iMX6 board running with X11, so in general it should be
possible. But this is using an early version of Qt5 - before
Ön Fri, 22 Mar 2019 17:06:32 +0100, Allan Sandfeld Jensen wrote:
Sounds like XCB isn't as well optimized as Qt is
Nice joke - but only when X11 falls back on some software emulation it
might be the case, that the Qt implementation is better than that one.
Note though, that there are number of
On 3/24/19 9:33 AM, Denis Shienkov wrote:
Yes, I too run X11 on my iMX6 board, but, seems it running without of
any acceleration (I use -platform xcb option to run my app).
Unfortunately I don't have easy access to our project running on the
iMX6 board anymore. But our BSP was made with build
On 3/23/19 11:09 PM, Allan Sandfeld Jensen wrote:
Software implementation is the default for X11 painting, with accelerated
paths being addons.
Having those addons is usually pronounced as: the system supports the GPU.
Sure there are systems, where this is not the case and things fall back
t
On 3/24/19 10:41 AM, Allan Sandfeld Jensen wrote:
Note though that the recommended way of doing hardware accelerated painting
these days with Qt, is using QML or the QtQuick scenegraph from C++. QPainter
being so sequential and imperative will never be able to take full advantage
of OpenGL becau
On 3/22/19 8:28 PM, Konstantin Tokarev wrote:
BTW, if your main concern is the performance of real-time plotting,
it's extremely unlikely that you'll get better results on EGL/X11
than on EGLFS or EGL/Wayland. Note that you can use QWidgets on any
of these platforms without restrctions.
Not be
On 3/24/19 1:13 PM, Allan Sandfeld Jensen wrote:
Because imperative in the case of QPainter means immediate. The
result is expected to have been committed to the paint device when
the call returns.
In case of the X11 paint engine this means that the points have been
sent to the X server - not
On 3/24/19 1:21 PM, Allan Sandfeld Jensen wrote:
As for the code you showed, that is so 90s. Please enable anti-aliasing, and
try again. Or do any kind of advanced pattern or line endings and joins.
Again: we are talking here about something like an oscilloscope, where
we have to draw a polyl
On 3/24/19 2:53 PM, Allan Sandfeld Jensen wrote:
... and I also advocate for the OpenGL engine.
Agreed as this is one is available on Windows as well.
But unfortunately OpenGL and X11 have been dropped with Qt5 and while
X11 had returned with Qt 5.10 I'm not aware of a replacement for
"-gra
On 5/21/19 4:58 PM, Thiago Macieira wrote:
Note I said QtXml is deprecated, but it might actually be in Done
state. I don't remember. Does anyone? Where's our authoritative
source?
The difference between Done and Deprecated is whether we're telling
you to start porting code away.
My use ca
On 5/24/19 2:30 PM, Giuseppe D'Angelo via Development wrote:
We're talking about code that users should _stop_ using anyhow,
and port away from it, right?
Please also consider the situation of 3rd party libraries ( like Qwt ),
that have to support Qt5/Qt6 from the same code base - probably fo
On 6/3/19 10:50 AM, Giuseppe D'Angelo via Development wrote:
How is this even an argument? Qt will need to evolve and acquire
features to remain competitive.
The probably most important module - Qt/Widgets - sits on a graphic
stack, that had been identified as not being competitive many years
On 6/3/19 1:34 PM, Kevin Kofler wrote:
So I disagree with the assertion that Qt needs more features to
remain competitive.
Come on - a toolkit ( Qt/Widgets ) for writing user interfaces, that
does not make use of the graphics hardware, is begging for being replaced.
Quick Controls 1 was onc
On 6/3/19 2:35 PM, Bernhard Lindner wrote:
What would be your story proposal? "Make Widgets great again"?
That would be one I would like to see.
But the story I'm actively working on is about a different Qt/Quick
framework. I hope, that we are allowed to give a presentation of what
this is
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/24/19 11:13 AM, Bogdan Vatra via Development wrote:
Considering that QtCS and QtWS are both in Berlin and both in Nov,
is there any reason why QtCS date was not choose immediately after
QtWS (7-9)?
Actually I was asking myself the same.
I don't know if anyone is interested in what I'm wo
On 9/28/19 8:49 AM, Simon Hausmann wrote:
Instead of an idle timer, all imperative triggered onFooChange
handlers are queued up and called right before the next frame.
Property binding is not the only notification mechanism and if its
synchronous character is not appropriate for a specific sit
Hi Chris,
should individual items have to know/track this ...
Well, anchoring is also based on size changes, but uses a different type
of notification -> item change listeners.
Not sure why the authors decided to introduce yet another type of
notification - instead of using event + event filt
On 10/2/19 4:36 PM, Jason H wrote:
There is fontSizeMode: Text.Fit, .HorizontalFit and .VerticalFit.
Horizontal fit is what you want in that situation. But the whole
implementation is lacking because you can't actually ask the Text
what size it used to render so that other text items on the sc
On 10/2/19 5:19 PM, Pierre-Yves Siret wrote:
While using layouts in the Qt Quick world, you use Layout attached
properties to give hints to the layout system :
Sure it is a subset of the options you have with the corresponding
layouts of the widgets world.
It is possible to set the explicit
Hi all,
thanks a lot for allowing me to join the QtC Summit this year.
I'm wondering if anyone is interested in my experiences with using the
Qt/Quick technology in a non standard way. I was specifically thinking
of the QSkinny theming system and the implications of doing scene graph
node com
On 11/8/19 9:51 AM, Richard Weickelt wrote:
doing scene graph node composition ? > What is the latter?
It is mostly about having a lower memory footprint.
a)
With QML you only have access to ~heavy objects like QQuickItem and the
controls are usually compositions of basic items like text/im
Hi all,
I started to play with Qwt on Qt5 and one of the incompatibilities I
have to solve is that the following method is gone:
void QPixmap::fill(const QWidget *, ... );
In the documentation it is qualified as obsolete - left for
compatibility issues only - but in fact it is not implemented
On 04/10/2012 06:47 PM, Samuel Rødal wrote:
> What's your use case?
QwtPlot is a composite widget, where one of its children is a canvas (
QWidget ) to display the data.
For this special widget the Qt::WA_OpaquePaintEvent attribute is enabled
and therefore I have to render the background inside
On 04/10/2012 08:03 PM, Uwe Rathmann wrote:
>
>> Maybe QWidget::render() with DrawWindowBackground
>> and no DrawChildren can be used instead?
> Guess this will work - I will try it.
Unfortunately QWidget::render doesn't work. In my use case I'm inside of
QWidget::
On 04/10/2012 09:43 PM, Andreas Aardal Hanssen wrote:
> Den 21:10 10. april 2012 skrev Uwe Rathmann <mailto:uwe.rathm...@tigertal.de>> følgende:
>
>
> You want to take a screenshot of the widget from within the widget's
> own paintEvent?
No, I need a replacement f
Hi all,
When testing Qwt with Qt5 I was running a NX ( http://www.nomachine.com
) remote desktop. Local was a SuSE/Linux 11.2, remote ran a SuSE 12.1/Linux.
With about half of the Qwt applications I had the following effect: as
soon as I move the mouse over the application window ( Xfce4, focus
On 04/13/2012 06:41 PM, Thiago Macieira wrote:
> Therefore, *ALL* Qt libraries must be either static or shared. Mixed
> builds will not be supported
Maybe this is a silly question, but what makes a library to be a Qt
library ?
Or asking the other way round: what is the difference between a module
Hi Thiago,
my interest is of course to benefit as much as possible from the ideas
and solutions of the Qt development
and I believe the best way should be to organize my code and build
environment like Qt libraries do.
So please let me check your list what might be possible for Qwt:
> 1) where
Hi Lars + Thiago,
let me continue in a new thread:
On 04/15/2012 12:58 PM, lars.kn...@nokia.com wrote:
> Look at the definition of a Qt add-on. I think that might fit nicely
fo Qwt.
> In any case, if you want your library do live under the qt-project
> umbrella we can most likely find a solu
On 05/08/2012 04:13 AM, Alan Alpert wrote:
> It's this "compulsory" part that I don't understand. The current situation is
> that if you don't want to use QML you don't use it.
Lars wrote in his blog about the vision behind Qt5, but isn't the main
idea behind this one:
a) application development
On 05/15/2012 02:13 AM, Donald Carr wrote:
> QML will be useful for anyone who wants to have designers
> get proactively involved in the UI/system software development of user
> interfaces for any number of embedded/dedicated devices. Once the
> qmlscene application can run, you can start working d
On 05/18/2012 07:36 AM, Иван Комиссаров wrote:
> Btw, you're saying that painter technology is outdated?
Well it is also the API for rendering PDF ( and other paint devices )
documents. Having common code for screen and PDF rendering is absolutely
not outdated - and is possible using QSGPaintedI
On 05/18/2012 09:07 AM, marius.storm-ol...@nokia.com wrote:
> Often it's hard to beat the performance of the main CPU(s for most people
> these days) filling in a polygon directly, rather than handing it off to a
> GPU.
Guess this is the reason behind the decision why in Qt 4.8 raster has
become
On 05/22/2012 10:53 AM, d3fault wrote:
> Old Slogan: Code Once. Create More. Deploy Everywhere.
I'm afraid the options will be: code twice or to deploy not everywhere.
While Qt4 widgets were a full replacement of Qt3 widgets it is not clear
when - or if ever - Qt components will be able to supe
On Tue, 26 Jun 2012 07:05:35 +, gunnar.sletta wrote:
> The lines left above highlights the general problem... The QPainter API
> is very feature rich and opens up for a number of use patterns that are
> less than ideal for performance.
Please don't forget that QPainter is more then renderi
On 06/27/2012 07:12 AM, Girish Ramakrishnan wrote:
> As you say, one solution is to have distros package the Qt4 and Qt5
> libs with different prefix as /usr/lib/qt4 and /usr/lib/qt5. Certainly
> makes it easy for us but I guess there is a reason why all libs are
> stuck under /usr/lib ?
Well Qt i
On 06/29/2012 09:04 AM, gunnar.sle...@nokia.com wrote:
> I see a people having a certain technology, say charting, which is
> encapsulated in a QWidget, and it should be possible to integrate those
> technologies into QtQuick 2.0.
In fact this is not a good example as the code for displaying ch
On 07/04/2012 08:33 PM, Thiago Macieira wrote:
> And you also need to tell me that the classes are generally useful, even
> outside of any relation to OpenGL (which was their original goal).
Qwt would also have interest interest in classes like QPointF3D, but
this is not what QVector3D is ( or a
On 07/05/2012 11:32 AM, Thiago Macieira wrote:
> Before that, you need to tell us if Eigen isn't enough:
>
This is not what - at least - I had in mind. I was thinking about
algorithms like:
- Sutherland Hodgman
- Douglas Peucker
- Quadtrees, R-trees
- Interpolation ( bilinear, trilinear ... )
-
On 07/06/2012 07:54 AM, Laszlo Papp wrote:
> In any case, I would call for QPointF3D (and similarities) again.
Qwt offers this implementation:
http://qwt.svn.sourceforge.net/viewvc/qwt/trunk/qwt/src/qwt_point_3d.h?revision=1083&view=markup
The fact that QwtPoint3D exists shows, that QVector2D i
On 07/06/2012 03:29 PM, Thiago Macieira wrote:
> QWidget was written before properties could have NOTIFY signals. That's why
> its properties don't notify of changes.
What doesn't explain, why QWidget doesn't indicate changes of its
geometry by signals. Maybe the reason once was that this type o
On 07/09/2012 11:30 AM, Thiago Macieira wrote:
> But we need to explain the difference between QPointF / QVector2D and
> QPointF3D
> and QVector3D. A point's coordinates are equal to that of the vector pointing
> to the point in question from the origin of the coordinate system.
>
> Laszlo, you're
On 07/20/2012 09:02 AM, gunnar.sle...@nokia.com wrote:
> Based on the experience we had from the widget stack and graphics view,
> we early on concluded that for applications which have
> moderate amount of animations, partial updates hurts a lot more than
> it gains.
I already had several
On 07/20/2012 12:32 PM, Andreas Aardal Hanssen wrote:
> Partial update support doesn't help for applications that don't _need_
> it, rather. And high-end mobile phones where there's enough CPU and GPU
> power for the UI, which is the focus of QML 2 and the SceneGraph, don't
> need it.
What abo
On Thu, 11 Oct 2012 14:33:30 +, Verbruggen Erik wrote:
>> I have personally never seen an actual use case where a cosmetic pen
>> makes sense, but I assume there are reasons for having i so anyone
>> creating an explicit QPen(Qt::black, 0.0) should get a 1.0 pixel thick
>> line regardless of
On Fri, 12 Oct 2012 10:10:59 +, Bache-Wiig Jens wrote:
> True. There are certainly plenty of valid use cases out there and some
> of those would require a minor change in Qt5 if we go ahead with this
> change.
Basically it is about if you want to have a pen width in model or paint
device co
On Fri, 12 Oct 2012 12:21:30 +, Bache-Wiig Jens wrote:
> I will leave that question for the graphics guys. I find it really
> strange that the performance impact of this would be significant and
> doubt that this is currently the case but I could easily be mistaking.
In Qwt I have an example
On Fri, 12 Oct 2012 12:21:30 +, Bache-Wiig Jens wrote:
> After all what is the point of doing a
> major version unless we don't even allow ourselves to change broken
> defaults.
There is nothing broken: it's a well defined API that behaves exactly
like it is documented. Your suggestion is a
On Fri, 12 Oct 2012 17:02:17 +0200, Samuel Rødal wrote:
> I'm not sure
> how valid that use case is these days though.
The use case I have in mind are oscilloscope alike widgets - for Qwt it
is a very common one.
For a widget being updated several times a second it is completely
unimportant if
1 - 100 of 157 matches
Mail list logo
