Purpose and scope of libs/odf

[Sebastian Sauer]

First thanks for the mail Inge, great one :)

On 05/17/2013 10:34 AM, 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

Here we may have identified root of the problem from my pov.

How I see it (and that's not limited to libs/odf but applies to all of 
libs/*) is that:
* prefer smaller libs over bigger libs.
* if there is an opportunity (and reason and not to high coast) to split 
parts of any of the libs off into an own library we should do it.
* Having multiple libs is cheap. When done right (static libs eg) there 
is no high price to pay but much to gain in terms of maintainable 
(lesser code per lib, logical grouped together, with ideally clear 
purpose), of understanding/getting into and, the for me atm probably 
most important aspect, it makes it easier to define and solve 
dependencies between libs / parts of libs.
* Modularization, think Qt5/kdeframeworks-like tiers/modules to allow to 
link/reuse only parts without dragging all in. We like to have that for 
Calligra-libs too, we need that.
* Something like libs/main should imho act as template, as show-case how 
not to do. I think that's something we even agree on from looking at the 
great (initial) work done lately with libs/widgetutils and from 
remembering our mail-exchange about that topic in the past. No 
monster-libraries with all kind of very difficult use-cases (some would 
name it a dumping ground) please.

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

Interesting. My point isn't about libs / filters at all. I am fine with 
having it in libs if it makes sense somehow. My target is more that I 
would like to see central pieces like odf, flake, main, shrinking or, 
where it makes sense, even new/own libraries (like for KoTemplate*) created.

Think here of e.g. a static compiled Words that not ships filters, not 
uses QWidgets. Think of a commandline-program like calligraconverter 
that not needs this and that. Think of libs as "calligra-frameworks" 
with very different building blocks.

We should and never had the idea to add everything related to ODF into 
one library. It just makes no sense. We have the textlayout-library and 
other rather ODF-related libraries not in ODF cause we gain a lot of 
that during development (compile-times), during adaption 
(calligraconverter not need to links against textlayout, actually 
nothing but textshape needs to), during maintaining (I not need to know 
about KoStore when I deal with textlayout or the other way around), etc.

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

I think we shouldn't drift away from the topic on hand which is not the 
mess we have in libs/main or things we can (and maybe should) improve 
here and there. Its about a rather concrete case and any argument like 
"but its still not as bad as xyz" is imho irrelevant. Just because 
things are not ideal shouldn't mean we should stop trying to improve 
them. And yes, *maybe* an own odfstyles-library makes sense (do we have 
a use-case where ODF is used but not styles? I doubt so) to get things 
simpler, smaller, improve dependency-situation, etc. Anyhow, I don't see 
how that's related atm.

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

+2