Re: Re: fdo#61135 New feature in Calc: Stepped Lines graphs - first part of code submitted

Hey Eric,

> On Wednesday 06 March 2013 17:00:56 Markus Mohrhard wrote:
>
> > First we need to move the new values in CurveStyle.idl to the end and
>
> > remove all the GNM_* values. Moving the values to the end ensures that
>
> > the old values stay unchanged which causes as little trouble for
>
> > extension developers using the API as possible.
>
>
>
> OK. I wasn't aware that the last value there was not a sentinel but needed
> to remain the same.

It is always better to leave existing values to make it easier for
potential external users of the API.

> > The import for files written by gnumeric should map the values to the
>
> > corresponding ODF values and during export we only want to export them
>
> > as ODF and never into the gnumeric namespace. This also means to
>
>
>
> OK. I thought that it would be nice for somebody that wrote the file with
> Gnumeric not to silently convert it to something that might not be read back
> the same in Gnumeric. That's why I added all these GNM_* values. But I can
> understand your POV.
>
>
>
> > remove all the references to the GNM_* values in the other source
>
> > files. For that to correctly work we need to register the gnumeric
>
> > namespace and map the elements in the chart namespace and the elements
>
> > in the gnumeric namesapce to the same UNO attributes.
>
>
>
> Could you explain this a bit more. Are we talking about the XML namespace or
> the C++ namespace ? I see some references in the code related to Gnumeric
> and a link with orcus.

We are talking about XML namespaces. The gnumeric elements with gnm
prefix are in an gnumeric namespace. The other links you see to
gnumeric code is in calc and orcus for the gnumeric import which is
only a proof of concept right now.

So the right way is to register the namespace. An exmaple for such a
change is 
(http://cgit.freedesktop.org/libreoffice/core/commit/?id=f18a242966d3fd25ec0832c09ce7164bdae7ba2d
) where I added a namespace for calc ODF1.2 extended elements. You
need to do something similar for gnumeric with the
http://www.gnumeric.org/odf-extension/1.0 URL. It makes sense to use
GNM or something like that as namespace alias in our code as this is
more or less the official gnumeric namespace prefix.

> > into the gnumeric namespace. Additionally we need to take care of the
>
> > ODF version during export and make sure we only export it into ODF1.2
>
> > extended. I think Thorsten was fine with exporting the elements into
>
> > the chart namespace but only for ODF 1.2 extended.
>
>
>
> First a general question. I found the option for selecting the ODF type. But
> how does that work when somebody requires, e.g., strict ODF1.2 or lower
> compliance. Is there a warning given when the file is written ? Do we hide
> the option for stepped lines then ?

We warn the user that choosing anything except ODF 1.2 extended may
loose data but we don't hide anything in the UI. We just drop the
elements during export.


> Secondly, can you point to an example where the above is done ? Then I can
> implement something similar.

Sadly this one is a bit tricky. Normally the magic happens in how we
specify the attribute values in the map but for this one I need to
explore it a bit more.
> > Additionally it would be nice if you would provide at least one of
>
> > your test documents from gnumeric and one of your test documents for
>
> > normal ODF as MPL/LGPL licensed test documents that we can add to our
>
> > test file repository. If you are interested it would also be nice if
>
> > you could add a test case for it to our new chart2 import test at
>
> > chart2/qa/extras/chart2import.cxx.
>
>
>
> There is a Gnumeric file attached to the bugzilla. I hereby place it under
> MPL/LGPL. Once I'm further, I will also add a similar file created fully in
> LO.

Thanks I'll add it to the test file repository at
http://cgit.freedesktop.org/libreoffice/contrib/test-files/


> I'll have a look at the test cases and what is done there.

Basically what we do there is just import a document and check through
the UNO API that the feature we are interested in is correctly
imported. So in your case it just means that we need to have a test
document with all the stepped line featiures that you want to test.
The easiest way is to have just one chart per sheet and then use the
existing code to get the chart and the data series and just test for
your property. However if you have problems with it I can add the
test.


> > For the UI part of the task it
>
> > might make sense to first convert the relevant dialog to the new UI
>
> > format and then add the new elements into it.
>
>
>
> As indicated in the UI ML, I will use a seperate dialog. As for getting up
> to speed with Glade, I was thinking about converting the existing dialog for
> the spline option first. Then, I know better how to create a new one.

Great. Thanks.


> But first I'll amend the existing patch with the code changes you requested
> above. Once those are accepted I'll tackle the UI.
Regards,
Markus