[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Proposal for splitting koffice/plugins/ dir
From:       Thomas Zander <zander () kde ! org>
Date:       2009-06-24 17:10:44
Message-ID: 200906242010.45563.zander () kde ! org
[Download RAW message or body]

On Wednesday 24. June 2009 00.32.12 Cyrille Berger wrote:
> On Tuesday 23 June 2009, Jaroslaw Staniek wrote:
> > I propose to split koffice/plugins into:
> > 1. koffice/plugins/app/ that depends also on private libraries
> > 2. koffice/plugins/generic that depends only on libraries from libs/
> >
> > Is that division the right one for you?
> > Maybe more fine-grained division is needed? (perhaps for filters/?)
> >
> > The main goal here is to make pacakgers perfectly sure we do NOT want
> > certain plugins packaged within apps :)
> >
> > e.g. kexi-kspread plugin would go to the 1st category, as we
> > definitely wouldnt want kspread dependency in kexi or the other way
> > around.
>
> I don't like that idea at all. I don't think we should have plugins
> depending on two applications internal libraries, this is calling for
> problems, both on the packaging side, and also on the maintenance side,
> during the 1.x time we did the integration with a mix of both approach,
> cross-linking and interfaces in a library, and if history tell us
> something, the first solution didn't work and led us to a not so well
> modular office suite, with also many issues due to the cross-linking. For
> 2.0 we decided to get ride of all cross-linking (even kspread doesn't
> link to kchart for inserting charts in a spreadsheet), lets not start to
> reintroduce some.

I completely agree.

> Here is what I favor:
> 1) koffice/plugins koffice/filters only goes there plugins that depends
> on koffice/libs
> 2) plugins can dependent on one internal application

And (I'm sure we agree) those that depend on an application need to then be 
placed inside the application subdir.
Apps can have filters that depend on the internals too and those then go in 
the appdir/filters/ for example.

> 3) koffice/libs koffice/interfaces are our central point of integration,
> if applications wants to collaborate in some way they use our integration
> tools, if our integration tools don't allow something, then we fix our
> integration tools

Using the interfaces is one suggestion thats good, another is to just use 
the libs. Typically you can get what you want via flake or libodf.
In the case of the recently committed migration plugin; I'm thinking that 
having an ods reader that writes to a kexidb database would be a much more 
maintainable as it cuts the kspread dependency and only depends on kexi.

-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]