Re: Continuing converting ScMyTables in feature/gsoc-calc-perf

On 06/04/2012 01:04 PM, Daniel Bankston wrote:

> On 06/01/2012 02:56 AM, Daniel Bankston wrote:
> > I think most of the other methods will follow fine from there except
> > for GetCurrentXDrawPage() and GetCurrentXShapes() which are separate
> > from the merge method concern. These methods get into things like
> > xmloff's XMLShapeImportHelper. Do we want to go here?
> >
> > And of course we have already discussed trying to reexamine
> > ScMyTables::SetTableStyle() at some point.
> I was looking at the XShape and DrawPage methods again and it would
> require some untangling, but I don't think they would be as confusing as
> SetTableStyle().

Yeah, I hope so.  Although from my own experience dealing with the shape 
import, this code is also shared across apps, and there is a potential 
of it being almost as convoluted as the styles import.

Also, the shapes may be handled entirely outside the sc (note: I'm 
speaking from memory here).  The only exception being the chart object, 
which sc handles some parts of it to register listeners etc.  So, it may 
or may not make sense to de-UNO-ize the shape import just for Calc alone.

Anyway, let's dig deeper and find out for sure what the situation is on 
the shape import front.

> In an IRC conversation, Markus and I discussed that I work on
> ScXMLTableRowCellContext::EndElement() in xmlcelli.cxx next. I will work
> on EndElement() now and come back later to XShape, DrawPage, and Styles
> in ScMyTables unless you guys think I should do differently.

Sounds good to me.  Thanks for the update!

Kohei

--
Kohei Yoshida, LibreOffice hacker, Calc