Proposal: Promote svg support

[Thorsten Zachmann]

On Tuesday, June 28, 2011 18:56:51 jaham at gmx.net wrote:
> On Tuesday 28 June 2011 06:00:43 Thorsten Zachmann wrote:
> > On Monday, June 27, 2011 22:07:28 jaham at gmx.net wrote:
> > > On Monday 27 June 2011 17:25:37 Thorsten Zachmann wrote:
> > > > On Sunday, June 26, 2011 18:25:56 jaham at gmx.net wrote:
> > > > > I thought to have a separate lib similar to our odf lib containing
> > > > > the classes  used for loading/saving svg. One of these classes
> > > > > would be an interface which shapes can implement to save/load svg
> > > > > data, i.e. calling it SvgSerializable.
> > > > > 
> > > > > class SvgSerializable
> > > > > {
> > > > > 
> > > > > public:
> > > > >         virtual bool saveSvg(SvgSavingContext &context) = 0;
> > > > >         virtual bool loadSvg(SvgLoadingContext &context) = 0;
> > > > >         // some more required functions
> > > > > 
> > > > > };
> > > > 
> > > > Agreed that having a libs like the odf lib makes sense and that
> > > > contains the stuff like SvgLoadingContext .... However I'm not sure
> > > > if we need a class SvgSerializable. Why not just put that into
> > > > KoShape directly?
> > > 
> > > There is no reason other than I was a little hesistant to force svg
> > > loading/saving support on each shape. Instead I thought making it
> > > optionally. But if there is consent about putting it directly into
> > > KoShape, I have no problem with that.
> > 
> > Looks like I did not understand how you want to use the above. For me it
> > looked like KoShape would need to inherit SvgSerializable to be able to
> > implement the functions. Seems I was wrong. Maybe you can explain how
> > that is should be done.
> 
> The idea was that each shape which wants to load/save svg would inherit
> SvgSerializable. So it can be done on a shape by shape decision.

Then I have to say that I prefer to add it to KoShape already as this removes 
the need for multi inheritance and makes it work much easier.

Thorsten