Architecture Refactor Suggestion: App-irrelevent Format Filters

[Inge Wallin]

On Sunday, October 21, 2012 06:56:49 Thorsten Zachmann wrote:
> Hello,
> 
> > Note: this is a problem for some Karbon filters, since they used
> > KarbonPart to access shapes for shape painting. We can modify
> > KoDocument::paintContent(painter, rect) to do that instead.
> 
> it is not for painting but for creating the structure to read so it is not
> easily possible to change these filters as they depend on karbon and can't
> be used by e.g. flow.

Yes, it's not for painting.

But the fact that the filter uses parts of Karbon to store internal structures 
before writing new data out shouldn't make it impossible to use by Flow. There 
are actually three problems here:

1. What Yue points out: That the filters are application specific rather than 
a generic converter between two formats.

2. That the filter uses Karbon internals in a way that it cannot be used by 
Flow. This should be more a link issue than anything else, or am I wrong?

3. That the Karbon filter uses KarbonPart instead of the document since the 
KPart is actually a UI component. This may be the problem that leads to 2 as 
well so they are perhaps the same.

As a side note, I think that Mek once mentioned that the XLS import filter for 
Sheets uses the Sheets document and then hands the document directly to the 
Sheets application without creating an intermediate ODS file. If the filter is 
used in calligraconverter and actually needs to create an ODS then the 
standard saveOdf() code of the document is used. If I understood that 
correctly then it seems to be the most efficient way, and the way that the 
Karbon filters should also use.


> Thorsten
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel