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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
