Hi all,
> What started as an attempt to provide a few building blocks for
making > it easier to build asynchronous APIs taking any kind of
callable (like > QTimer::singleShot ...
Sorry for posting without checking your implemented solution:
one of the goals of my QSkinny ( https://github.com
On 6/4/22 23:20, Giuseppe D'Angelo via Development wrote:
I'd tend to agree; for some of our customers we indeed used H.264
encoding using VDPAU/VAAPI.
Actually H.264 covers the idea of sending differences between 2 frames
only - but without requiring any support of Qt/Quick.
However you will
Hi all,
sorry for hijacking a thread in a slightly different direction, but as
I was working on a VNC solution for Qt/Quick for EGLFS recently.
My VNC server ( BSD-3-Clause license ) can be found here:
https://github.com/uwerat/vnc-eglfs
The main reason why I'm not happy with the official VNC p
Servus Ulf,
What part of the docs do you mean here?
https://doc.qt.io/qt-6/qqmlengine.html#QML_ANONYMOUS
"Declares the enclosing type to be available, but anonymous in QML.
The type cannot be created or used as property type, but when passed
from C++, it is recognized."
Thought that "property
Hi Ulf,
thanks for the hints.
instead of using QQmlMetaType::registerCustomStringConverter() you > can add a static create() function that takes a QJSValue as argument
> to your class or have a ctor that takes QJSValue. Then register the >
type using QML_ANONYMOUS and it should be possible to
Hi,
when testing the Qt 6.2 rc I noticed that registering custom string
converters with
QQmlMetaType::registerCustomStringConverter() has been dropped.
( Yes, QQmlMetaType is from the private API where no compatibility
policies are made )
Actually I'm not interested in having a custom strin
On 12/5/19 6:12 PM, Giuseppe D'Angelo via Development wrote:
In this light, what's the idea of a global minimum size useful for?
It is/was useful for widget applications running on devices with touch
screens, where the default metrics from the styles are too small.
You could argue that a go
Hi Shawn,
FWIW I did try to make that point during the session, since you
weren’t there to do it yourself, that you would like to have
something like a table of QVariants instead of only colors (to
include things like icons and border line widths and radii), and
also that the ColorRole enum sh
On 12/4/19 4:07 PM, Volker Hilsheimer wrote:
That’s cool! Sadly, many of our widgets (for instance, none of the
item views), and none of our quick controls respect the globalStrut
property.
QApplication is about widgets, while Qt/Quick is usually QGuiApplication
and should be no argument here
On 11/26/19 12:35 PM, Olivier Goffart wrote:
"QML Strict is as subset of QML which is more maintainable and
performs better"
Isn't it that way:
QML is for convenience but expensive. C++ is often less convenient but
with better performance and lower memory footprint. QML Strict is a
compromise
On 11/23/19 11:26 PM, Thiago Macieira wrote:
Wrapping int() around requires more manual work.
I understand, but I think this is the type of change that will eventually
become a problem down the road. We think it can help with porting, but it may
later introduce subtle bugs by truncating sizes.
On 11/22/19 11:01 AM, Friedemann Kleint wrote:
https://wiki.qt.io/Qt_Contributors_Summit_2019_Qt_6_Changes_/_Migration
Maybe one aspect I would like to add: there is a lot of software, that
has to be compilable with Qt 5 and Qt 6. Especially when your product is
library you can't decide whic
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,
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 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
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
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 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
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
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 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
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 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 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 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 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 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 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/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 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/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 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
Ö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 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
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
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
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 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
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
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 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 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 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 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 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
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, 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
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 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 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 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 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 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 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 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, 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, 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 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: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 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 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 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 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 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 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 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 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 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 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 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 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 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
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
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 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 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 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.
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
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
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 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,
> 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
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
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
On Mon, 29 Jan 2018 06:59:06 +, Jani Heikkinen wrote:
> - '5.6' will move in 'very strict' mode - '5.9' will move in 'strict'
> mode.
This type of discussion has to be lead, before making a LTS promise !
Trying to change this later - without having any argument beside, that
maintaining stab
On Tue, 16 Jan 2018 18:38:48 +0100, Kevin Kofler wrote:
> So just use QString(), or define your own static instance of it if you
> really want to microoptimize it that much.
No it is simply that the first version of Qwt was for Qt 1.2 ( before
QString even existed ) and during a history of almos
On Tue, 16 Jan 2018 17:54:43 +0100, Giuseppe D'Angelo wrote:
> headers of 3rd party libraries
> should be included under -isystem, not -I, to disable warnings in their
> headers.
Yes as there seems to be no BC break ( thanks to all correcting me, I
should have a deeper look at the code before )
On Tue, 16 Jan 2018 17:26:51 +0100, Alexander Nassian wrote:
> Deprecated since Qt4 ...
According to qstring.h:
#if QT_DEPRECATED_SINCE(5, 9)
...
#endif
But come this is not about me and if I missed, that an API has been
declared as deprecated. It is about what to best in the current situation
On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote:
> Just change your code to use "= QString()", no #ifdef necessary.
The "just change" introduces a binary incompatibility - right ?
Please be aware, that Qwt is part of almost any Linux distro - according
to sourceforge it has more than
Hi all,
I received a bug report concerning a header of the Qwt library ( http://
qwt.sf.net ), that is using the deprecated QString::null.
Sure this is only a warning, but it is obviously something where Qwt
users get irritated as they can't fix code of a 3rd party header.
The offending line lo
On Mon, 28 Aug 2017 21:41:15 +0200, Jean-Michaël Celerier wrote:
> * apparently QQuickWindow has some ties to the QML engine but in my
> experience you can just create new QQuickItem from c++ and add them as
> child of the rootItem and it works.
F.e. https://github.com/uwerat/qskinny does exactly
Hi Lars,
> 5.6.3 is planned for Summer (current plan is August), close to 18 months
> after the first release. So yes, the 'very strict’ mode would be coming
> somewhat early, but more by 6 months than a full year.
Or to put it this way: 5.6 LTS guarantees, that all serious bugs found
during the
On Wed, 10 May 2017 09:21:37 +0200, André Hartmann wrote:
> From Lars original mail:
>
> > Of course, we will also continue to support 5.6 for the promised
> > three years. We are planning to release 5.6.3 in Summer, after which
> > 5.6 will move into the 'very strict' mode as defined in the
On Tue, 09 May 2017 13:35:52 +, Lars Knoll wrote:
> So we are now planning to make Qt 5.9 a LTS release. It's been 3 minor
> releases since 5.6 and a lot of good things have happened in Qt, so this
> should be very good news to those of our users that don't always want to
> be on the bleeding
On Tue, 25 Apr 2017 06:05:38 +, Martin Smith wrote:
> Use \internal in their qdoc comments to tell qdoc not to include them.
What would be incorrect as those APIs are only internal for C++, but
public for QML or v.v. And sometimes you have "see also" references
inside of docs for a method t
On Mon, 24 Apr 2017 17:09:43 +, Martin Smith wrote:
> It doesn't need a separate comment, just something in the one common
> comment that indicates the class is both C++ and QML.
Most of the decisions about what parts of the APIs have to go to the QML
docs can indeed be made without any addi
On Mon, 24 Apr 2017 15:08:25 +, Shawn Rutledge wrote:
> I guess we haven’t run into this very frequently yet because so few
> classes have both a C++ and a QML API within the same class.
Well, this is exactly my use case. All my controls are 100% implemented
in C++ offering a full featured C
On Tue, 22 Nov 2016 18:05:20 +0100, Friedrich W. H. Kossebau wrote:
> Q1: what would be a good system path pattern (on *nixoid systems) for
> Qt-based libraries to install their QCH files to?
Qwt ( http://qwt.sf.net ) offers a qch file and is available for quite
some time. So you could check, wh
On Wed, 09 Nov 2016 09:04:23 +, Miikka Heikkinen wrote:
Hi Mikka,
> I’m Qt Charts maintainer. It is true that Charts have been on back
> burner for a good while now, as I’ve been assigned to other tasks, but
> it’s not abandoned by any means.
Maybe you could shed some light on the future of
On Tue, 08 Nov 2016 13:30:45 +0100, Jeandet Alexis wrote:
> Our goal is to improve QtCharts to be able to use it in our scientific
> softwares. So we need to improve the current dynamic with OpenGL and/or
> improve performances of non OpenGL plots.
Have you ever considered to use a 3rd party libr
1 - 100 of 157 matches
Mail list logo
