Re: [Libreoffice] [GSoC 2011][svgexport] I need some help on exporting "all selected slides" task

On Fri, 10 Jun 2011 08:28:04 +0200, Thorsten Behrens  
<thb@documentfoundation.org> wrote:

> Ariel Constenla-Haile wrote:
> > I guess the export filter will get a reference to the document model,  
> > so he
> > will need to get the "SubController" [1]
> > Model -> Controller -> SubController
> Hi Ariel,
>
> neat! I'm always amazed about the depth of your API knowledge! :)
>
> Marco - were you able to make anything of that?

Hi Thorsten,
this is my report on the state of the task:

(1) I succeed in getting the selected slides but only if they are
selected in the center Slide Sorter Pane (that is through the
"Slide Sorter" tab), not if they are selected in the Left Side Pane.

(2) I see that the Export Dialog has a "Selection" check box.
I guess that its role is to let the user choose if he/she wants
to export the whole presentation or only the selected slides.
However I don't know yet, if/how the state of such check box is
passed to the svg export filter, and in case it isn't, how to get
that state.

(3) The present svg export filter class is designed to export one
or all slides. So adapting it to export a generic subset of slides
will require a not so small effort as I thought (but surely doable :)).

(4) In the present implementation I see that in the "single slide
to export" case, once the slide/page to export has been retrieved,
instead of taking a reference to that page as a data member, what is
performed is to get the page number property, then to append it to
the descriptor object as a "PagePos" property. This information is
retrieved later by the implExport method and then forwarded to
the other export methods as needed. What is the rationale for such
a solution ? I am asking/pointing out that, because the selection
object I get is of type Sequence< Reference < XInterface > >, but
the actual type is Sequence< Reference < presentation::XDrawPage > >,
so imo the simple solution would be to have a data member with such
a type. Is this sensible ? Or, on the contrary, should I add an
array data member containing the page numbers of all selected slides
and then access a given slide through the rxDrawPages->getByIndex
method ?



A side issue, while I was making some test I noticed that the
following code produced some unexpected result:

OUString s1 = xObj1->getName();
OUString s2 = xObj2->getName();

const char* ps1
        = OUStringToOString( s1, RTL_TEXTENCODING_UTF8 ).getStr();
const char* ps2
        = OUStringToOString( s2, RTL_TEXTENCODING_UTF8 ).getStr();

OSL_TRACE( "s1= '%s'", ps1);
OSL_TRACE( "s2= '%s'", ps2);


From some code similar to the fragment above, and put inside
a for loop, come out that the char const* pointer doesn't point
to what it should. Is it normal that creating some new instance of
a OUString invalidate the exported pointers to the internal
data ? I am used to std container where an iterator is invalidated
in some circumstances but only if you modify the container.

Cheers,
   Marco


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/