Purpose and scope of libs/odf

[Thorsten Zachmann]

Hello


> emphasized:
> > In libs odf we
> > should only have that what we are need for the apps and is very useful to
> > them.
> 
> Ok, this is a valid scope.  The reason I started the work I'm currently
> doing (aside from the docx filter) is because there are several sets of
> named styles that are not retained. Graphic styles are the most significant
> of those. Do you agree that they belong in libs/odf when I'm done because
> they will be used in all applications?

I agree that these stuff belongs to libs/odf or maybe to any higher level of 
api. E.g. like the text styles are part of the kotext. Not sure if in the end 
libs/odf will work as it might need stuff from kotext styles (which are part of 
the graphic style).

> > 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'd be interested to know what this work would be. A style is inherently
> just a container with some well defined data. The style classes in
> libs/kotext has some nice caching which for example lets you access a
> QColor or QFont instead of having to parse all the attributes again and
> again.  Naturally I want to add this functionality to the style classesI'm
> working on too.

e.g. for the graphic styles the stuff gets parsed into classes that show it 
also e.g. the background color/pattern of a shape. Also kotext styles have 
quite a lot of knowledge on interdependencies between the different elements of 
the style

> As the end goal, I want *one* set of style classes that are useful in both
> filters and the applications. I think libs/odf is the place to have them.

That we will know once there is a patch that implements the styles handling 
for the applications. With the review of that patch we can decide as then we 
have something to look at.

> All of this said, though, I agree to move my own classes and the ones that
> are now in libs/odf until I have a proposed patch that will actually unify
> them.

Good.

> > - 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.
> 
> I question this.  Our many many libraries and plugins was the biggest
> problem when Mek first attempted to port to Android.

This is a shortcomming of one platform and should not be the base of our 
discussion. There are solutions to that and Mek managed to make it work even 
with the different libs we have now.

> > 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.
> 
> I think you digressed a bit from the main question, namely the scope of
> libs/odf.  But yes, I think it explains your thinking. I hope we can get to
> a common viewpoint soon.

I think we move to libs if the apps use it and not only the filters. 

> One thing that I heard on IRC was that it is good to keep libraries small. 
> I have never really understood why this is a good thing in itself. Every
> library that is loaded has a fixed cost and a cost in proportion to its
> size. The smaller and more numerous the libraries are the more it costs to
> load them all.  This only applies if most of the classes of the libraries
> are used, of course. If there are big parts that are not needed then that
> is wasteful. But how important is it?

Did anybody do any testing on the loading times and all that to see how big a 
problem the loading times are. At least on the desktop and also on e.g. 
harmattan this was not a problem at all.
However having only the stuff in the lib that is realy needed
- makes it much simpler to port it to new platforms
- have less code to load for all apps not needing it

Thorsten