Using Sheets as a library

[Philip Van Hoof]

On Mon, 2012-11-26 at 21:14 +0100, Boudewijn Rempt wrote:
> On Monday 26 November 2012 Nov, Philip Van Hoof wrote:
> > Hi guys,
> > 
> > For the purpose of a custom made and specialized Qt application will
> > need to adapt the CMakeFile.txt of Sheets in such a way that the
> > non-installed calligrasheetscommon_LIB gets installed and that its
> > header files will become available.
> 
> Sounds like a cool project! Is it something you can tell us about? I love hearing about people reusing Calligra libs.

I'll need to be vague about this for the moment. Apologizes for that.

[cut]

> > My question is whether the Calligra community would be interested in my
> > patches for CMakeFile.txt files of Calligra
> 
> Yes (we'd need to review them too, of course)

Of course

> > and whether Calligra in
> > general would be interested in transforming from a set of office suite
> > application to a set of libraries and components that can be used to
> > build office-like applications.

[cut]

> Yes, that's where we're going in many ways. After all, sheets, words
> and stage have already been re-used in FreOffice (using the QWidget
> canvas), Harmattan Documents (the QGraphicsItem canvas) and MeeGo
> Office (same, but this one was never released). Krita has been reused
> in Krita Sketch. We've seen calligra used to produce RTF documents,
> we've done a pilot producing layout information and there's a company
> re-using Words as the internal report editor, which was demoed last
> Calligra sprint.

When they got reused did people write patches for Calligra's
CMakeFile.txt already? Perhaps those patches are reusable?

You know where I can find the projects and the adapted build
environments for Calligra? If they are open source and have a suitable
license it would be silly of me if I'd reinvent their wheels .. :)

> Life isn't perfect, though, and there's too much close integration with qwidget-based code left.

That's ok. Right now for the purpose that I need it is CanvasItem
relatively ok when it comes to its API and dependencies on QWidget based
code.

Compared to other QGraphicsItems in the project is the sheets one rather
slow to draw, though. But perhaps that's because I have not optimized my
experiment much yet? So it's a bit early to tell.

[cut]


> > I also noticed that all the files under sheets/ are annotated at the top
> > for the LGPL copyright. I saw two copyrights in the Calligra main
> > directory, COPYING and COPYING.LIB, can I assume that what falls under
> > sheets is LGPL? This is important for my application and I think for
> > making it more easy to reuse sheets/ as a library too.
> 
> Yes -- if there's a file with a GPL header, it's probably an accident (unless a unittest).

Ok, but I need to stress that a GPL header, also a accidentally GPL
header, is a problem for any user who's project requires LGPL (like in
case of my customer's project).

> > These files have the GNU General Public License instead of the GNU
> > Library General Public License. 

[cut]

> > 
> > pvanhoof at lors:~/repos/kde4/calligra/sheets$ grep "GNU General" * -R |
> > cut -d ":" -f -1 | sort | uniq
> > dialogs/ConsolidateDetailsWidget.ui
> > dialogs/ConsolidateWidget.ui
> > dialogs/GoalSeekWidget.ui
> > dialogs/SortDetailsWidget.ui
> > dialogs/SortWidget.ui
> > dialogs/SpecialPasteWidget.ui
> > dialogs/SubtotalsDetailsWidget.ui
> 
> I think that ui files get the gpl header automatically, so that's
> probably an accident. Also, if you're using the graphicsitem canvas,
> you probably can disable the entire dialogs directory because you
> don't want the qwidget-based dialogs.

That's good to know because reducing code (and .ui files get quite a bit
of code generated) means reducing compilation time and object size.

Also again is even an accidentally added GPL header a problem for any
project that requires LGPL.

> > tests/BenchmarkRTree.cpp
> > tests/BenchmarkRTree.h
> 
> And these are tests, so not really relevant.

I agree that the unit tests in GPL is fine. We don't need to link with
that.

Kind regards,
 
Philip

-- 


Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be