[Kexi-devel] Kreport charts plugin

[Treeve Jelbert]

On Wed, 20 Jan 2016 13:21:18 +0100, Jaroslaw Staniek wrote:
> On 18 January 2016 at 13:38, Adam Pigg <piggz1 at gmail.com> wrote:
>
>> The current charts plugin uses kdchart from Calligra. We can no 
>> longer use
>> that, so:
>> 1. Rely on released versions of kdchart
>> 2. Rewrite using Qt chart, which I think will be open sourced at 
>> some
>> point


http://code.qt.io/cgit/qt/qtcharts.git/

due for release with qt-5.6 in February

Regards

>> ?
>>
>
> Thanks Adam,
> ​Good time to ask these questions.
> (CC'd Friedrich)
>
> - Good thing is that we need less features from charts that some 
> other apps
> (no interactive editing for example, configuring via property editor 
> is
> enough).
>
> - It's hard to consider Kdchart or KChart, we failed to get 
> preferable
> license (LGPL).
>
> - Qt Charts, yes -- freed now, good news for use. They are not yet
> investigated. This task is open for volunteers.
>
> Extra question is about backward compatibility. Our first step would 
> be,
> like for other report elements, document what concepts and properties 
> we
> directly use/support in the public for Kexi 2.x. We may need to 
> understand
> our constraints. This task is also open for volunteers.
>
>
> Unfortunately we don't know how much Kexi charts are used in the wild 
> for
> serious cases. Maybe alternatively we could ignore this step and 
> declare a
> fresh start. In any case I would propose this time to have a 
> structural
> approach for further changes in the report (and form) format: 
> document
> features and the format in real time. And have test documents/data.
>
>
>> What are the pros/cons?
>>
>
> Technically switching from kdcharts to KCharts wouldn't be hard since 
> I
> don't think we're using too many API points. This applies switching 
> to
> anything, including Qt Charts.
>
> ​Cons of keeping kdcharts and using KCharts ​is introduction of 
> conflicting
> 'business models' potentially helping projects like Kexi: binary 
> 'polluted'
> with KChars can't link to incompatible plugins. This potentially 
> defeats
> _any_ ideas of plugin based architecture in entire Calligra/KDE, not 
> just
> in Kexi. So one overlook makes a lot of work basically unnecessary. 
> So
> here's the reason to be picky. (Competiton such as LibreOffice picks
> Mozilla or Apache license and the trouble is nonexisting from the day 
> 1)
>
> If someone isn't sure the pollution happens when GPL plugins are in 
> use,
> consider this scenario:
> - I have a GPL lib and would like to use it with with LGPL and want 
> the
> result to still be LGPL
> - I am taking all APIs I need from the lib and pretending this is an
> abstract plugin-level API
> This would potentially cause that any GPL code is translated to LGPL, 
> and
> though the main app, can be linked with to GPL-incompatible code. 
> It's not
> going to work or at least be fair, given what implied intentions of 
> the
> authors of GPL libs are.
> So instead we're trying to convince copyright holders to re-license, 
> as we
> did for kdchart. If that fails, that's life. We need to find 
> something else.
>
> PS: See
> 
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/chapter-licensing-advisory.html
> "The reason for demanding plugins be licensed under the LGPL, even 
> when
> using a GPL library, is that other developers might want to use the 
> plugin
> code as a template for plugins linking to non-GPL libraries." - this 
> is
> quite similar reasoning to what we propose in Kexi (maybe it's time 
> to note
> down that explicitly?)
>
>
>> _______________________________________________
>> Kexi-devel mailing list
>> Kexi-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/kexi-devel
>>
>>