Re: [Development] Requesting a repository for Lottie-Qt implementation

[Tuukka Turunen]

Thanks!


Yours,

Tuukka


Lähettäjä: Development  käyttäjän Paul 
Wicking  puolesta
Lähetetty: perjantaina, tammikuuta 11, 2019 4:48 ip.
Vastaanottaja: development@qt-project.org
Aihe: Re: [Development] Requesting a repository for Lottie-Qt implementation

On 1/9/19 3:23 PM, Tuukka Turunen wrote:
>
> Hi,
>
> I would like to request for a new repository:
>
> Name of the repository: qt/qtlottie.git
> Description: Lottie-Qt, a renderer for Bodymovin animations
> Responsible person: Eirik Aavitsland
> Gerrit user/email: eirik.aavitsl...@qt.io<mailto:eirik.aavitsl...@qt.io>
>
> Lottie is a family of player software for a certain json-based file format 
> for describing 2d vector graphics animations. These files are 
> created/exported directly from After Effects by a plugin called Bodymovin.
>
> About Lottie: https://airbnb.design/lottie/
>
> Intention is to create a Qt based player for these animations and license it 
> under GLPv3 and commercial licenses.
>
> Yours,
>
> Tuukka
>
>
>

Hi,

the repository has been created and can be found here:
https://codereview.qt-project.org/#/admin/projects/qt/qtlottie

It's ready for use.

Paul
___
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

[Shawn Rutledge]

> On 11 Jan 2019, at 10:02, Simon Hausmann  wrote:
> The approach of using the JS implementation and wrappers is clever and I got 
> the same impression that this is what KDE is using. It has upsides (easy to 
> follow changes) and downsides (overhead, but cannot quite say if that’s 
> noticeable).

I downloaded https://github.com/kbroulik/lottie-qml and tried a few animations 
from lottiefiles.com.  They take a lot of CPU, as expected; 100% of one core 
for some of them.

Nevertheless this is a cool idea; I’m wondering why I haven’t heard of it until 
now, although I think I’ve seen some of those animations around the web, just 
didn’t know what they were.  I think a good browser-performance-beating 
implementation would be a good addition to Qt, but I hope we will have GPU 
acceleration of these eventually.

I suppose eventually there will also be a free software method of creating 
these without having to buy AE.  Here’s a plugin for Sketch: 
https://github.com/buba447/Lottie-Sketch-Export which is also written in JS.  
Maybe synfig (which I also hadn’t heard of before) or opentoonz could end up 
with a Lottie export feature for example (just ideas).  Does KDE have anything 
in the works for that?

The JSON isn’t very readable: all the keys are abbreviated.  Looks like the 
schemas are here: https://github.com/airbnb/lottie-web/tree/master/docs/json

This interview with Salih (the designer) was a bit interesting (explains the 
name and other aspects of the history): 
https://blog.thenounproject.com/icons-in-motion-d925e15ef319
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Christoph Keller]

Looking forward to your implementation!

I have one more implementation to throw in but hope the TQtC one is far 
more superior.


A few months ago I refactored the lottie-ios code to Qt and used a 
modified version of QtQuick.Shapes since the JavaScript way was about 
0.5 fps on a Android/iOS phone. The code was never finished, so I did 
not publish it until now: https://github.com/Conntac/lottie-qt.
It lacks features such as Masks and other, so it's not really usable for 
all use cases - but it runs with 60fps even on a low-end Android phone.


Greetings,
Christoph

On 11.01.19 10:49, Lars Knoll wrote:

On 11 Jan 2019, at 10:02, Simon Hausmann  wrote:


The approach of using the JS implementation and wrappers is clever and I got 
the same impression that this is what KDE is using. It has upsides (easy to 
follow changes) and downsides (overhead, but cannot quite say if that’s 
noticeable).

Eirik, what’s the approach of your implementation?

The implementation done inside the Qt Company is native and should have a much 
lower overhead than a wrapper around the JS implementation.

It’s unfortunate that those happened in parallel, but I don’t think anybody can 
be blamed in this case. I’d say let’s get the repository, so that TQtC can 
publish it's sources.

Cheers,
Lars


Simon


On 11. Jan 2019, at 06:52, Kevin Kofler  wrote:

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

___
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

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Lars Knoll]

> On 11 Jan 2019, at 10:02, Simon Hausmann  wrote:
> 
> 
> The approach of using the JS implementation and wrappers is clever and I got 
> the same impression that this is what KDE is using. It has upsides (easy to 
> follow changes) and downsides (overhead, but cannot quite say if that’s 
> noticeable).
> 
> Eirik, what’s the approach of your implementation?

The implementation done inside the Qt Company is native and should have a much 
lower overhead than a wrapper around the JS implementation.

It’s unfortunate that those happened in parallel, but I don’t think anybody can 
be blamed in this case. I’d say let’s get the repository, so that TQtC can 
publish it's sources.

Cheers,
Lars

> 
> Simon
> 
>> On 11. Jan 2019, at 06:52, Kevin Kofler  wrote:
>> 
>> 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
> ___
> 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

[Uwe Rathmann]

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 the QML wrapper.

> However my guess is that most users expect something as simple as this:
> BarChart { model: myData } and they don't care about how it works as
> long as it works.

Bar charts, pie charts and other type of business charts usually fall 
into this category. And for this type of use cases Qt/Charts is probably 
o.k.

But when you are looking for technical plots you need a framework like 
QGraphicsView and friends. Trying to cover this type of use cases with a 
declarative API ( setter/getter ) only, is simply a bad idea.

Uwe


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Simon Hausmann]

The approach of using the JS implementation and wrappers is clever and I got 
the same impression that this is what KDE is using. It has upsides (easy to 
follow changes) and downsides (overhead, but cannot quite say if that’s 
noticeable).

Eirik, what’s the approach of your implementation?

Simon

> On 11. Jan 2019, at 06:52, Kevin Kofler  wrote:
> 
> 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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Samuel Stirtzel via Development]

Am Do., 10. Jan. 2019 um 18:07 Uhr schrieb Uwe Rathmann
:
>
> 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
>
> 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.

There is a property that enables OpenGL rendering for _some_ plots and
it has some side effects:
https://doc.qt.io/qt-5.11/qabstractseries.html#useOpenGL-prop

> 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.

Basically yes, a Qwt QML wrapper is a solution that works with
acceptable performance and it can be customized to blend in with the
rest of the application (e.g.
https://user-images.githubusercontent.com/2573046/40121913-ea4b6c34-5922-11e8-9f2e-a825fc1a2b1c.png
).
However my guess is that most users expect something as simple as
this: BarChart { model: myData } and they don't care about how it
works as long as it works.
But I don't see the Qt Company write wrappers for LGPL libraries when
they OTOH try to convince their customers to not use LGPL and instead
buy a commercial license.


-- 
Regards
Samuel
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Kevin Kofler]

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

[Sean Harmer]

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

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Uwe Rathmann]

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

[Shawn Rutledge]

> 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

[Kevin Kofler]

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] Requesting a repository for Lottie-Qt implementation

[Kari Oikarinen]

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

[Dmitry Volosnykh]

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

[Vlad Stelmahovsky]

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

[Uwe Rathmann]

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

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Vlad Stelmahovsky]

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] Requesting a repository for Lottie-Qt implementation

[Frederik Gladhorn]

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

[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

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Tuukka Turunen]

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

[Uwe Rathmann]

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] Requesting a repository for Lottie-Qt implementation

[Frederik Gladhorn]

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

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Frederik Gladhorn]

Hi,

Thanks for pointing out that this alternative implementation exists.

On onsdag 9. januar 2019 17:18:50 CET Eike Hein wrote:
> Hi,
> 
> we've written one of those at KDE recently:
> 
> https://github.com/kbroulik/lottie-qml
> 
> We also submitted some patches to both Qt and Lottie to make it work
> better.
> 
> Ours is LGPLv2+ as usual, FWIW.

Which sadly makes it unsuitable for inclusion in Qt.

Our code is already written as well, so I guess we should publish it asap to 
avoid further duplication, maybe Kai wants to contribute some of his work that 
applies. I haven't seen the code that The Qt Company wrote and didn't know Kai 
did something similar.

Considering KDE also is interested in this kind of component, I'm for creating 
the repository now, so that we can compare implementations.

Now we should just clarify if the name lottie can be used, as Thiago pointed 
out.

Cheers,
Frederik


> 
> 
> 
> Cheers,
> Eike
> 
> On 1/9/19 11:23 PM, Tuukka Turunen wrote:
> >  
> > 
> > Hi,
> > 
> >  
> > 
> > I would like to request for a new repository:
> > 
> >  
> > 
> > Name of the repository: qt/qtlottie.git
> > 
> > Description: Lottie-Qt, a renderer for Bodymovin animations
> > 
> > Responsible person: Eirik Aavitsland
> > 
> > Gerrit user/email: eirik.aavitsl...@qt.io 
> > 
> >  
> > 
> > Lottie is a family of player software for a certain json-based  file
> > format for describing 2d vector graphics animations. These files are
> > created/exported directly from After Effects by a plugin called Bodymovin.
> > 
> >  
> > 
> > About Lottie: https://airbnb.design/lottie/
> > 
> >  
> > 
> > Intention is to create a Qt based player for these animations and
> > license it under GLPv3 and commercial licenses.
> > 
> >  
> > 
> > Yours,
> > 
> >  
> > 
> > Tuukka
> > 
> > 
> > ___
> > 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




___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Tuukka Turunen]

Hi Eike,

Great, the more the merrier. After we have the repo in place, I hope you can 
also take a look into what we have in mind as approach for the player. 

Maybe one day these can be compared, perhaps combined or otherwise unified. 

Yours,

Tuukka

On 09/01/2019, 19.31, "Development on behalf of Eike Hein" 
 wrote:

Hi,

we've written one of those at KDE recently:

https://github.com/kbroulik/lottie-qml

We also submitted some patches to both Qt and Lottie to make it work
better.

Ours is LGPLv2+ as usual, FWIW.



Cheers,
Eike

On 1/9/19 11:23 PM, Tuukka Turunen wrote:
>  
> 
> Hi,
> 
>  
> 
> I would like to request for a new repository:
> 
>  
> 
> Name of the repository: qt/qtlottie.git
> 
> Description: Lottie-Qt, a renderer for Bodymovin animations
> 
> Responsible person: Eirik Aavitsland
> 
> Gerrit user/email: eirik.aavitsl...@qt.io 
> 
>  
> 
> Lottie is a family of player software for a certain json-based  file
> format for describing 2d vector graphics animations. These files are
> created/exported directly from After Effects by a plugin called Bodymovin.
> 
>  
> 
> About Lottie: https://airbnb.design/lottie/
> 
>  
> 
> Intention is to create a Qt based player for these animations and
> license it under GLPv3 and commercial licenses.
> 
>  
> 
> Yours,
> 
>  
> 
> Tuukka
> 
> 
> ___
> 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


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Tuukka Turunen]

Hi Thiago,

Lottie is the established term for a player of animations created with Adobe 
After Effects and exported with a plugin tool called Bodymovin.

Lottie is a registered trademark for many things (like nail polish, children's 
toys and food), but it is not registered as a trademark for the player of 
Bodymovin animations (or anything close to it).

See https://airbnb.io/lottie/: "Lottie is named after a German film director 
and the foremost pioneer of silhouette animation." and "Lottie is a mobile 
library for Android and iOS that parses Adobe After Effects animations exported 
as json with Bodymovin and renders them natively on mobile and on the web!"

Therefore we believe the right name for this little thing is Lottie-Qt.

Yours,

Tuukka

On 09/01/2019, 19.52, "Development on behalf of 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.

-- 
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


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Thiago Macieira]

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.

-- 
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] Requesting a repository for Lottie-Qt implementation

[Eike Hein]

Hi,

we've written one of those at KDE recently:

https://github.com/kbroulik/lottie-qml

We also submitted some patches to both Qt and Lottie to make it work
better.

Ours is LGPLv2+ as usual, FWIW.



Cheers,
Eike

On 1/9/19 11:23 PM, Tuukka Turunen wrote:
>  
> 
> Hi,
> 
>  
> 
> I would like to request for a new repository:
> 
>  
> 
> Name of the repository: qt/qtlottie.git
> 
> Description: Lottie-Qt, a renderer for Bodymovin animations
> 
> Responsible person: Eirik Aavitsland
> 
> Gerrit user/email: eirik.aavitsl...@qt.io 
> 
>  
> 
> Lottie is a family of player software for a certain json-based  file
> format for describing 2d vector graphics animations. These files are
> created/exported directly from After Effects by a plugin called Bodymovin.
> 
>  
> 
> About Lottie: https://airbnb.design/lottie/
> 
>  
> 
> Intention is to create a Qt based player for these animations and
> license it under GLPv3 and commercial licenses.
> 
>  
> 
> Yours,
> 
>  
> 
>     Tuukka
> 
> 
> ___
> 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