[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: Proposal for splitting koffice/plugins/ dir
From: Cyrille Berger <cberger () cberger ! net>
Date: 2009-06-23 21:32:12
Message-ID: 200906232332.13268.cberger () cberger ! net
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
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
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
--
Cyrille Berger
[Attachment #5 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" \
"http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" \
content="1" /><style type="text/css">p, li { white-space: pre-wrap; \
}</style></head><body style=" font-family:'DejaVu Sans'; font-size:9pt; \
font-weight:400; font-style:normal;">On Tuesday 23 June 2009, Jaroslaw Staniek \
wrote:<br> > I propose to split koffice/plugins into:<br>
> 1. koffice/plugins/app/ that depends also on private libraries<br>
> 2. koffice/plugins/generic that depends only on libraries from libs/<br>
><br>
> Is that division the right one for you?<br>
> Maybe more fine-grained division is needed? (perhaps for filters/?)<br>
><br>
> The main goal here is to make pacakgers perfectly sure we do NOT want<br>
> certain plugins packaged within apps :)<br>
><br>
> e.g. kexi-kspread plugin would go to the 1st category, as we<br>
> definitely wouldnt want kspread dependency in kexi or the other way<br>
> around.<br>
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.<br> <p \
style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;"><br></p>Here is what I favor:<br> 1) koffice/plugins \
koffice/filters only goes there plugins that depends on koffice/libs<br> 2) plugins \
can dependent on one internal application <br> 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<br> <p style="-qt-paragraph-type:empty; margin-top:0px; \
margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; \
text-indent:0px; -qt-user-state:0;"><br></p>-- <br> Cyrille Berger</p></body></html>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic