[Kexi-devel] Kreport charts plugin

[Jaroslaw Staniek]

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

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


-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kexi-devel/attachments/20160120/51334df6/attachment.html>