Purpose and scope of libs/odf

[Inge Wallin]

On Friday, May 17, 2013 05:34:45 Thorsten Zachmann wrote:
> 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

No problem.  After this discussion is over I can move them all to a library as 
part of the work I'm doing now - if the consensus is to move them.

> > 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.

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?

> 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.

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.

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.

> > 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.

I question this.  Our many many libraries and plugins was the biggest problem 
when Mek first attempted to port to Android.

> - 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.

With "it", I suppose you mean some style classes?  Yes, currently most of them 
are only used by filters But very soon a few will also be used by the 
applications.

> - 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.

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.

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?

> Have a nice day,
> 
> Thorsten