Re: [Development] Requesting a repository for Lottie-Qt implementation
Shawn Rutledge wrote: > https://github.com/kbroulik/lottie-qml looks like a JS/canvas thing? As I understand the code, the KDE implementation at that link uses the upstream Lottie JS/web implementation with a fake browser DOM shim that implements those few DOM methods that the JS code needs in terms of Qt Quick. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
On 10/01/2019 15:08, Shawn Rutledge wrote: The next problem is how to use custom shaders and adjustable uniforms without breaking batching in the scene graph; today, the number of draw calls goes up if you do that. This is the reason we don’t have GPU-calculated AA line charts, and it’s also the reason we don’t have the nice Ellipse that I wrote for Qt Quick. Every custom shader runs in a separate batch (that’s unavoidable). Shaders can’t have dynamically adjusted uniforms (for animation, or for limiting the scope of rendering of a vertex array), or even uniforms that vary between instances, without breaking batching, and that’s a terrible limitation that I would like to see solved somehow in a future scene graph implementation, if there’s any way. glDrawElementsInstanced() in ES 3 and OpenGL 3 can be used or if you want to go further you can index into uniform buffer objects or SSBOs and use things like glMultiDrawIndirect. There are equivalents in Vulkan/Metal/DX12 of course. However, limiting everything to the feature set provided by ES 2 won't allow this type of optimisation as you are forced to do more on the CPU side. Cheers, Sean ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Running AVX2 code in the CI
Hello Commit c8c5ff19de1c34a99b8315e59015d115957b3584[1] was allowed to pass the CI despite failing tests in a non-blacklisted test. It's fixed in [2] which is integrating now. The reason this was allowed is because none of the machines in the CI are testing the AVX2 codepaths in qdrawhelper_avx2.cpp. So this commit is to ask that we add at least one machine (preferably Linux) that has that capability. AVX2 along with FMA was introduced with the Haswell architecture[3] (fourth generation Intel Core, according to the marketing name), first launched in late 2013. That makes the architecture over 5 years old and it means a lot of our users have the feature. We ought to test it and even benchmark if we can. [1] https://codereview.qt-project.org/249410 [2] https://codereview.qt-project.org/249572 [3] https://en.wikipedia.org/wiki/Haswell_(microarchitecture) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QAbstractVideoFilter, the pipeline and QImage
> From: "Val Doroshchuk"
> Hi,
> thanks for explanation.
> Does it sound good to try to create a data storage, where converted data is
> located per real frame, (which will be created on first filter).
> Followed filters will use QVideoFrames with custom
> QAbstractVideoBuffer::UserHandle and id from the storage?
I don't know about the QAbstractVideoBuffer::UserHandle method. That's why I'm
having this conversation. I don't know what the best answer is. I was playing
with the idea yesterday of just using the metadata with a
QString("%1_%2x%3").arg(cvMatType,width,height) key and checking to see if that
exists at whatever pipeline stage needs it. This way, I can just return the
frame, skip the conversion back and pay for only the mats I need.
Unless there's a better way? One thing I wondered is since it's a runnable, is
this happening on multiple threads (or cores? - if available) Are there
multiple frames "in flight"?
From: Jason H
Sent: Wednesday, January 9, 2019 4:28:01 PM
To: Val Doroshchuk
Cc: Qt development mailing list
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage
>> I really want a QAbstractVideoBuffer *QVideoFrame::buffer() which I can then
>>cast to my custom type.
> Sorry, but just a note.
> QAbstractVideoBuffer is an abstraction that was supposed to be an impl of
> accessing to data, nothing more.
>> I'm trying to implement a QAbstractVideo buffer that uses cv::Mat
> Why you need to use cv::Mat there?
> If needed, you could create QAbstractVideoBuffer::UserHandle and return an id
> to access to cv's data without downloading/uploading within mapping.
Because the video frame needs to be converted to a format that OpenCV
understands. Various OpenCV functions need particular pixel representation
types: grayscale 8 bit, floating point, float or int array if 3,4 color
channels. I basically want to do this conversion once, then pass that on to
later stages in the pipeline. In general the OpenCV functions don't modify the
frame itself, but produce information about the frame. The filters I have emit
the results of the computation in some cases (a list of line segments for
houghLines) while others, like sobel, create a new image. Depending on the
pipeline, I might want multiple OpenCV representations. I generally use
QPainter though, to draw on the frame after having gotten the information.
>> I think there should be class(es) that converts a QVideoFrame to a cv::Mat,
>>and one that converts from cv::Mat to QVideoFrame: filters: [toMat, blur,
>>sobel, houghLines, toVideoFrame]
> Is it performance wise operation to convert QVideoFrame to cv::Mat and back
> in this case?
> (qt_imageFromVideoFrame(QVideoFrame) can convert to QImage, and should be
> relatively fast)
Well, I generally don't need to convert back, though this is possible. There
are OpenCV functions that produce an image. I'm fine with using OpenCV to
extract info and keep the drawing in Qt (QPainter). So there's no need for me
to convert it back. Though I will say that the OpenCV functions are _very_
fast, supporting multiple acceleration methods (uses Eigen). I wrote my own
implementations of some of them purely in Qt, and the OpenCV stuff puts them to
shame. Image saving is the only thing where Qt is faster (IMHO, empirical
evidence not yet collected). One other technique I use is to scale the image
down (say by 50% or 25%) which quarters or 16ths the time respectively, if I
don't need pixel perfect accuracy.
I would expect some way to attach cv::Mats to a frame. That way I could look
through what mats are available, and only pay a penalty when I have to. If a
previous filter operation already produced a 8bit gray scale, I would just use
that, and if it doesn't exist create it. Later filters could then use it, or
create their own.
if (!frame.containsMat(CV_8U)) frame.insertMat(CV_8U, frame.toMat(CV_8U));
cv::Mat mat = frame.mat(CV_8U)
...
frame.insertMat(CV_8U, mat)//if I need to save (like for sobel)
WRT the "Big Picture": I'm trying to a point where I can in QML, have filters,
which are OpenCV functions programmed to a dynamic filter pipeline. My
approach is working but the cost of all the conversions is very expensive.
We're talking 50msec per frame, which gets me down into 1 filter is 15pfs
territory, 2 filters is 5 fps, etc. My source is 25-29.97FPS. The way I've been
doing this is copying the QVideoFrame to QImage, then using that for a Mat.If I
can just pay the conversion penalty once, I think that would go a long way in
helping.
Maybe what I need to do is to make the cv::Map a QVariant and store it as
metadata and use QVideoFrame availableMetaData()?
From: Development on behalf of Jason H
Sent: Tuesday, January 8, 2019 6:33:14 PM
To: Jason H
Cc: Qt development mailing list
Subject: Re:
Re: [Development] Corrupted ML archive
QTBUG-35476 refers to http://lists.qt-project.org/pipermail/development/2013-December/014491.html which I was going to re-read but it has gone missing too. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
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. See the private section. But more important: as far as I can see it creates a QImage with QPainter, that it is finally converted to a scene graph node: see DeclarativeChart::renderScene. It's the first time I checked this code, but if I'm right I would say, that with Qt/Chart over QML the plot scene is never rendered hardware accelerated ! This is actually worse than any other pure widget based solution - including Qt/Chart widgets - that could at least take advantage of using hardware acceleration over X11 or OpenGL. Of course the performance of DeclarativeChart could easily be improved by adding the option of using QPainter on a FB0 ( or at least using a QPixmap, that would help for X11 ). But the fact that this has not been done so far makes me believe, that heavy and/or frequently updated plots are not considered as being relevant. Note that being able to create an Image/Pixmap/FBO with QPainter is something you find in every plot package - like you can also do this with any QGraphicsScene. Wrapping it into a QQuickItem, that converts the result into a texture is not much of a deal if you are familiar with the Qt/Quick C++ classes. So what has to be done for binding a plot widget to the scene graph and for building a declarative API on top, that can be exposed to QML, is more or less the same for any type of plot widget. It's a wrapper around the plot classes and therefore no strong argument for not using an existing solution. But anyone who knows better: please correct me if I'm wrong. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
> On 10 Jan 2019, at 13:24, Vlad Stelmahovsky > wrote: > > Qwt is nice but supports only QWidgets, right? > > so any mobile or Desktop/QML is not supported. Probably this is one of the > reasons > > and its not HW accelerated Last I checked (which was a couple years ago), Charts started out widget-oriented, and QtQuick support was added without changing how the rendering is done… so it’s not like how the rest of Qt Quick is implemented, more like use QPainter to render into an image, then make a texture out of that, and then oh yeah you can composite it into the scene as a final step. One exception is if you want to draw a simple line chart with GL_LINES, then the GPU can do it (but that way there is no built-in antialiasing). Writing highly efficient code (efficient even on low-end GPUs) for arbitrary 2D graphics _with_ AA is hard, unless you can afford multi-sampling (to do basic low-quality AA on anything that was jaggy), or can afford crazy fragment shaders (shadertoys.com approach). I got as close as I could to the “right way” a few years ago for line charts only: making a few extra vertices, and having the vertex shader calculate their positions and alphas, so that all the strokes have “feathered” edges and reasonably nice corners… it’s very efficient, but the shader is complex, and still imperfect, so quality of sharp corners especially is not as good as doing it with QPainter. (Writing it really tested my math skills. And debugging shaders is very hard too.) But maybe I’ll find a way eventually. It’s one of my back-burner research projects. QtQuick Shapes don’t have AA. (Unless you use multi-sampling, or NV_path_rendering) But if we had figured out a good generic solution for vertex AA for those (QTriangulator with AA), then the way I'd implement Lottie would be to allocate all the vertices for the whole shape at the beginning, then use two uniforms for each animated segment, to tell the vertex shader to collapse a range of the array (from a cut-off point to the end cap) and relocate the end cap. But it has to be possible for uniforms to be animated. The next problem is how to use custom shaders and adjustable uniforms without breaking batching in the scene graph; today, the number of draw calls goes up if you do that. This is the reason we don’t have GPU-calculated AA line charts, and it’s also the reason we don’t have the nice Ellipse that I wrote for Qt Quick. Every custom shader runs in a separate batch (that’s unavoidable). Shaders can’t have dynamically adjusted uniforms (for animation, or for limiting the scope of rendering of a vertex array), or even uniforms that vary between instances, without breaking batching, and that’s a terrible limitation that I would like to see solved somehow in a future scene graph implementation, if there’s any way. https://github.com/kbroulik/lottie-qml looks like a JS/canvas thing? I’m guessing that both of the Lottie implementations make QPainter work pretty hard? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
Uwe Rathmann wrote: > Don't you agree that supporting an existing project instead would have > lead to a better overall situation for everyone ? A similar situation is Phonon vs. QtMultimedia, where both projects are now missing some wanted features. If they had been working together, we would have one complete multimedia framework instead of two frameworks covering only some of the use cases. That case is particularly sad because Phonon was supposed to be the showcase of successful collaboration between Qt and KDE, but then got unilaterally kicked out of Qt in favor of reinventing the wheel with QtMultimedia. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QAbstractVideoFilter, the pipeline and QImage
Hi, thanks for explanation. Does it sound good to try to create a data storage, where converted data is located per real frame, (which will be created on first filter). Followed filters will use QVideoFrames with custom QAbstractVideoBuffer::UserHandle and id from the storage? From: Jason H Sent: Wednesday, January 9, 2019 4:28:01 PM To: Val Doroshchuk Cc: Qt development mailing list Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage >> I really want a QAbstractVideoBuffer *QVideoFrame::buffer() which I can then >> cast to my custom type. > Sorry, but just a note. > QAbstractVideoBuffer is an abstraction that was supposed to be an impl of > accessing to data, nothing more. >> I'm trying to implement a QAbstractVideo buffer that uses cv::Mat > Why you need to use cv::Mat there? > If needed, you could create QAbstractVideoBuffer::UserHandle and return an id > to access to cv's data without downloading/uploading within mapping. Because the video frame needs to be converted to a format that OpenCV understands. Various OpenCV functions need particular pixel representation types: grayscale 8 bit, floating point, float or int array if 3,4 color channels. I basically want to do this conversion once, then pass that on to later stages in the pipeline. In general the OpenCV functions don't modify the frame itself, but produce information about the frame. The filters I have emit the results of the computation in some cases (a list of line segments for houghLines) while others, like sobel, create a new image. Depending on the pipeline, I might want multiple OpenCV representations. I generally use QPainter though, to draw on the frame after having gotten the information. >> I think there should be class(es) that converts a QVideoFrame to a cv::Mat, >> and one that converts from cv::Mat to QVideoFrame: filters: [toMat, blur, >> sobel, houghLines, toVideoFrame] > Is it performance wise operation to convert QVideoFrame to cv::Mat and back > in this case? > (qt_imageFromVideoFrame(QVideoFrame) can convert to QImage, and should be > relatively fast) Well, I generally don't need to convert back, though this is possible. There are OpenCV functions that produce an image. I'm fine with using OpenCV to extract info and keep the drawing in Qt (QPainter). So there's no need for me to convert it back. Though I will say that the OpenCV functions are _very_ fast, supporting multiple acceleration methods (uses Eigen). I wrote my own implementations of some of them purely in Qt, and the OpenCV stuff puts them to shame. Image saving is the only thing where Qt is faster (IMHO, empirical evidence not yet collected). One other technique I use is to scale the image down (say by 50% or 25%) which quarters or 16ths the time respectively, if I don't need pixel perfect accuracy. I would expect some way to attach cv::Mats to a frame. That way I could look through what mats are available, and only pay a penalty when I have to. If a previous filter operation already produced a 8bit gray scale, I would just use that, and if it doesn't exist create it. Later filters could then use it, or create their own. if (!frame.containsMat(CV_8U)) frame.insertMat(CV_8U, frame.toMat(CV_8U)); cv::Mat mat = frame.mat(CV_8U) ... frame.insertMat(CV_8U, mat)//if I need to save (like for sobel) WRT the "Big Picture": I'm trying to a point where I can in QML, have filters, which are OpenCV functions programmed to a dynamic filter pipeline. My approach is working but the cost of all the conversions is very expensive. We're talking 50msec per frame, which gets me down into 1 filter is 15pfs territory, 2 filters is 5 fps, etc. My source is 25-29.97FPS. The way I've been doing this is copying the QVideoFrame to QImage, then using that for a Mat.If I can just pay the conversion penalty once, I think that would go a long way in helping. Maybe what I need to do is to make the cv::Map a QVariant and store it as metadata and use QVideoFrame availableMetaData()? From: Development on behalf of Jason H Sent: Tuesday, January 8, 2019 6:33:14 PM To: Jason H Cc: Qt development mailing list Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage I'm still plugging away at this. My life is being made difficult by not being able to get a pointer to the buffer. For OpenCV, some routines want a color image, others want an 8 bit gray scale. It would be really great if I could use both of these at the same time. For example, take the color video frame, make it gray scale, then run houghLlines on it, using that information to highlight the lines in the color frame. I tried to do this with a simple QMap but there's no way I can access it, because there's no QAbstractBuffer *QVideoFrame::buffer(). I might be able to hack it in using QAbstractPlanarVideoBuffer, but that feels very
Re: [Development] Requesting a repository for Lottie-Qt implementation
On 10.1.2019 15.22, Uwe Rathmann wrote: > 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. > Not quite: https://doc.qt.io/qt-5/qtcharts-qmlchart-example.html -- Kari ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
What about this set of QML types? [1] [1] https://doc.qt.io/qt-5/qtcharts-qmlmodule.html > On 10 Jan 2019, at 16:22, Uwe Rathmann wrote: > > 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/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
nope, there is QML interface On 1/10/19 2:22 PM, Uwe Rathmann wrote: 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/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
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/development
[Development] Qwt and Qt Charts
Renamed discussion topic. :) Agree with Uwe. I was using Qwt for many years and was surprised when Qt Charts appeared. Thought it has some advantages or interesting effects. If not, it is also not clear to me why not to contribute to Qwt which is feature rich, extremely fast and make it candy, modern look and feel and standard de facto for Qt? Existing chart solutions for Qt are too poor comparing with D3.js features for example - good to improve! -- Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich 10.01.2019, 14:22, "Uwe Rathmann" : > 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 > > I leave it up to you to google for more ... > > You might have noticed, that questions on the Qt mailing lists regarding > Qt/Charts mostly end up in not being answered, but at least you find this > statement from the maintainer: > > https://lists.qt-project.org/pipermail/development/2016-November/ > 055337.html > > If you prefer "simple charting" or "not be the be-all-end-all charting > solution" over "limited" - I don't care, we can agree on Miikkas wording. > > But it doesn't affect my conclusion, that Qt users ( including your > customers ) would have a better solution, if you would have contributed > to an existing 3rd party library instead of reinventing the wheel. > >> Discussion about Qt Charts is of course welcome, but perhaps not that >> relevant for discussion about creating a new repository for Lottie-Qt. > > True, but Qt/Chart is a good example of what happens, when ignoring > existing 3rd party software without technical reasons. > > And on a more general note: if LGPLv2+ makes code not being appropriate > for the Qt project, then don't be surprised that you are not attractive > for developers without having a business case in mind. > > My 2 cents, > Uwe > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
Qwt is nice but supports only QWidgets, right? so any mobile or Desktop/QML is not supported. Probably this is one of the reasons and its not HW accelerated On 1/10/19 1:00 PM, Uwe Rathmann wrote: 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 I leave it up to you to google for more ... You might have noticed, that questions on the Qt mailing lists regarding Qt/Charts mostly end up in not being answered, but at least you find this statement from the maintainer: https://lists.qt-project.org/pipermail/development/2016-November/ 055337.html If you prefer "simple charting" or "not be the be-all-end-all charting solution" over "limited" - I don't care, we can agree on Miikkas wording. But it doesn't affect my conclusion, that Qt users ( including your customers ) would have a better solution, if you would have contributed to an existing 3rd party library instead of reinventing the wheel. Discussion about Qt Charts is of course welcome, but perhaps not that relevant for discussion about creating a new repository for Lottie-Qt. True, but Qt/Chart is a good example of what happens, when ignoring existing 3rd party software without technical reasons. And on a more general note: if LGPLv2+ makes code not being appropriate for the Qt project, then don't be surprised that you are not attractive for developers without having a business case in mind. My 2 cents, Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Coding style for lambdas with empty parameter list
I vote for shorter form as well.
But the documentation should be extended with the Philippe's second
example. Trailing return type is rarely required, but we cannot omit
parameters list in this case, because it leads to compilation error.
On 1/9/19 8:31 PM, Philippe wrote:
> I like the shorter form, but keep in mind that when the return type
> needs to be specified,
>
> [] ->foo { // lambda content }
>
> is not possible, and following is needed:
>
> []() -> foo { // lambda content }
>
> Philippe
>
> On Wed, 9 Jan 2019 19:08:46 +0100
> "André Hartmann" wrote:
>
>> Hi all,
>>
>> I recently found an inconsistency regarding empty lambda parameter lists
>> between [1] and [2]. While the first states, that parentheses have to be
>> written always, the latter is missing this section.
>>
>> My request to syncronize both [3] lead to the conclusion, to change the rule,
>> so that empty parameter lists should be written as
>>
>> [] { // lambda content }
>>
>> instead
>>
>> []() { // lambda content }
>>
>> If anyone has objections against this change, please vote at [3].
>> I'll keep this commit open a while and adopt the Wiki [1] once the change
>> is approved without objections.
>>
>> Thanks and regards,
>> André
>>
>> [1] https://wiki.qt.io/Coding_Conventions#Lambdas
>> [2] https://code.woboq.org/qt5/qt-creator/doc/api/coding-style.qdoc.html#772
>> [3] https://codereview.qt-project.org/249192
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
--
Best Regards,
Fanaskov Vitaly
Senior Software Engineer
The Qt Company / Qt Quick and Widgets Team
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
Hi Uwe, On torsdag 10. januar 2019 10:24:22 CET Uwe Rathmann wrote: > 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 > libraries available. For some reason "Qt" decided to come up with the Qt/ > Charts module many years later - AFAIK without even trying to contact any > existing project. > > As being author of a competing package I never checked the code of the Qt/ > Chart module and can't ( and don't want to ) judge if it is good or bad. > But my impression is, that it started with a limited set of features and > immediately changed into maintenance mode without seeing much active > development since then. > > Don't you agree that supporting an existing project instead would have > lead to a better overall situation for everyone ? Absolutely, but The Qt Company is a company. It provides many services to the community, but it also needs to function as business. That is why we have the CLA for the Qt project, being able to monetize on the product makes it possible to invest into the development of the same. > > Considering that you hardly get the existing modules maintained - why > don't you start with thinking in a more community oriented way ? I'd like to see more community focus from TQtC as well. At the same time, we are considering the community pretty much always. Sometimes we make unfortunate decisions (it's a company, neither good or bad, nobody's perfect). I do not see how we could have avoided this in this instance - the module was internally written for a customer and we want to make it available for others to use. I was not aware that there is a KDE framework that does serve a similar purpose. Let's get the code out, then implementations can be compared by those interested. I agree that duplicating effort is a bad idea, sometimes is sadly hard to avoid. Cheers, Frederik > > Uwe > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
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 I leave it up to you to google for more ... You might have noticed, that questions on the Qt mailing lists regarding Qt/Charts mostly end up in not being answered, but at least you find this statement from the maintainer: https://lists.qt-project.org/pipermail/development/2016-November/ 055337.html If you prefer "simple charting" or "not be the be-all-end-all charting solution" over "limited" - I don't care, we can agree on Miikkas wording. But it doesn't affect my conclusion, that Qt users ( including your customers ) would have a better solution, if you would have contributed to an existing 3rd party library instead of reinventing the wheel. > Discussion about Qt Charts is of course welcome, but perhaps not that > relevant for discussion about creating a new repository for Lottie-Qt. True, but Qt/Chart is a good example of what happens, when ignoring existing 3rd party software without technical reasons. And on a more general note: if LGPLv2+ makes code not being appropriate for the Qt project, then don't be surprised that you are not attractive for developers without having a business case in mind. My 2 cents, Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
Hi, Sometimes parallel work happens - especially if things are done outside of the Qt Project repositories. Sometimes there is real duplication of effort, sometimes approach is different even though aiming towards the same goal, performance may differ, 3rd party dependencies are different etc. So not everything that at first look seems duplicate actually is. Related to your comment about the Qt Charts being limited I would tend to disagree. While there of course are always thing that can be added, it does support a wide variety of different chart types and functionality. Discussion about Qt Charts is of course welcome, but perhaps not that relevant for discussion about creating a new repository for Lottie-Qt. Yours, Tuukka On 10/01/2019, 11.58, "Development on behalf of Uwe Rathmann" wrote: 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 libraries available. For some reason "Qt" decided to come up with the Qt/ Charts module many years later - AFAIK without even trying to contact any existing project. As being author of a competing package I never checked the code of the Qt/ Chart module and can't ( and don't want to ) judge if it is good or bad. But my impression is, that it started with a limited set of features and immediately changed into maintenance mode without seeing much active development since then. Don't you agree that supporting an existing project instead would have lead to a better overall situation for everyone ? Considering that you hardly get the existing modules maintained - why don't you start with thinking in a more community oriented way ? Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
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 libraries available. For some reason "Qt" decided to come up with the Qt/ Charts module many years later - AFAIK without even trying to contact any existing project. As being author of a competing package I never checked the code of the Qt/ Chart module and can't ( and don't want to ) judge if it is good or bad. But my impression is, that it started with a limited set of features and immediately changed into maintenance mode without seeing much active development since then. Don't you agree that supporting an existing project instead would have lead to a better overall situation for everyone ? Considering that you hardly get the existing modules maintained - why don't you start with thinking in a more community oriented way ? Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Coding style for lambdas with empty parameter list
On Wed, Jan 9, 2019 at 8:44 PM "André Hartmann" wrote:
> My request to syncronize both [3] lead to the conclusion, to change the
> rule,
> so that empty parameter lists should be written as
>
> [] { // lambda content }
>
If I were to vote, which I won't, I'd vote instead to make the expression
as explicit as possible, thus requiring even the return type to be
specified. Which is also in line with my view on the auto keyword. C++ is
implicit enough to pile yet more "if this is not specified, then it means
something else" on top. And I personally believe that the whole syntax
shouldn't have been put in the standard allowing for any choice to begin
with. If you look before C99 the following kind of definitions were a real
blast:
functionX(parameter1, parameter2)
int parameter1;
float parameter2;
{
return 200;
}
Beautiful, right? The best part is, there's no need to specify the return
type as well ...
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Maintainers, your action needed: Qt 5.12.1 changes files
Hi! Initial ones here: https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.12.1%22,n,z Maintainers, please finalize ones immediately and get changes approved. br, Jani ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Lottie-Qt implementation
On onsdag 9. januar 2019 17:26:06 CET Thiago Macieira wrote: > On Wednesday, 9 January 2019 06:23:02 PST Tuukka Turunen wrote: > > Description: Lottie-Qt, a renderer for Bodymovin animations > > What's "Lottie" ? Is that an acronym? Or is it a trademark of something? If > it's the latter, please find another name. At least the page by airbnb doesn't claim any trademark. https://airbnb.design/lottie/ They also provide libraries for Android, iOS and react-native as far as I can see licensed with Apache 2.0. From what I can tell, we would follow their spirit and add another implementation of their image/animation file format, I don't see lottie mentioned as trademarked anywhere on their pages. I'd propose we create the repo. Side note: We had a discussion internally yesterday among the gerrit administrators (yes, we are four people now that actively handle your requests). We'll try to move this kind of request to JIRA, so that we can track it, since email tends to break down. That doesn't mean things should not be announced here (quite the opposite), but creating a task in QTQAINFRA with Gerrit as component will probably be the way to get any repository created/changed in the future. To test that I created https://bugreports.qt.io/browse/QTQAINFRA-2536 Cheers, Frederik ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
