Purpose and scope of libs/odf

[Thorsten Zachmann]

On Thursday 16 May 2013 18:51:52 Inge Wallin wrote:

>  * Objects that represent parts of an ODF document that are used only in
> filters. Applications have more sophisticated implementations that allow
> editing and with more efficient memory management: KoCell, KoColumn, ...

This classes also don't belong to libs/odf. They should be moved out of 
libs/odf too. I can help move them out once you put your classes out of 
libs/odf
> 
> Notably absent are style objects that are used in applications.  The classes
> for text styles are in libs/kotext and some others are in libs/flake (e.g.
> KoMarker).
> 
> Proposed scope
> ----------------------
> 
> I think that the ODF library should be for people who need to read, write or
> handle ODF contents.  This means that all of the above is actually good
> examples of what should be in it.

I do not agree. The classes used by filters are quite generic and while they 
might be useful to others they don't belong to libs/odf. In libs odf we should 
only have that what we are need for the apps and is very useful to them. Up to 
now I'm not confident that the classes used for filters have a use for the 
applications. The style classes there just can read the data and give it back 
in a different way. However the styles classes we use in the apps also do the 
actual work that needs to be done.

> I think that libs/odf should contain more objects of the type KoBorder, etc,
> i.e. objects that are part of the typical content of an ODF file. I also
> think that we need to have remove the lack of style handling in libs/odf
> (see below [1]).  The style classes that are in there already are either
> for import filters meaning that they have setters and support for
> KoGenStyle or the ones by me which don't have full support for everything
> yet. It should not be too difficult to add loading to them and make them
> more generic.
> 
> I want to work to make the odf library ready for external consumption.  I
> know what needs to be done here, but before I start on it in a structured
> way the final scope needs to be defined.

I think all this styles data makes sense to put into a lib in filters. When it 
is like that it is also easy for others to use them if needed.

Why I think putting them to libs is bad:

- putting them to libs/odf makes every application have the code even if they 
don't need too. E.g. for krita, stage, flow, sheets, words(without filters)....  
and the user gets it installed even when not used.
- having libs small makes it easier to port to other platforms.
- it gives a wrong expression to new developers, as for them it is hard to see 
the differenece if all is in libs.
- It is yet only be used by filters so it should move to filters. 
- It should be in its own lib (inside filters) as then others(external users) 
can also use it.

Hope that explains why I prefer putting it into filters. You also get the 
possibilty of external users, keep the core smaller and therfore more 
manageable.

Have a nice day,

Thorsten