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

List:       koffice-devel
Subject:    Re: Last day before rc1
From:       Inge Wallin <inge () lysator ! liu ! se>
Date:       2006-02-24 12:48:08
Message-ID: 200602241348.08946.inge () lysator ! liu ! se
[Download RAW message or body]

On Friday 24 February 2006 11.54, Raphael Langerhorst wrote:> Am Donnerstag, 23. \
Februar 2006 20:51 schrieb Jarosław Staniek:> > Robert Knight said the following, On \
2006-02-23 20:27:> > > KSpread still has some critical problems left, notably:> >> > \
[..]> >> > Hmm. Such news show me that considering separate releases can be> > \
reasonable, i.e. separate kolibs, separate apps or pairs of apps (all> > depends on \
devs will)...> >> > Can we switch to this one day?> > Comments?>> Hi,>> actually I \
would appreciate splitting kolibs from the apps at some point.> KOffice has many many \
components (it's after all the most complete office> suite), so I think it would be \
acceptable and even desired by packagers, to> release koffice libs seperately from \
the applications (and each application> seperately as well). I think this is a bad \
idea.  The interaction between the libs and the apps is not unidirectional, i.e. it's \
not that the apps uses the libs.  It is also the case that features that first appear \
in one application is moved into the libs so that all the other applications can use \
it. Examples of such features just during the 1.5 development are the guide lines, \
autoscroll, dockers, gradients and lots more.  This process would be severely \
hampered, if not completely stopped, if we split up the releases of the libs and the \
applications.
> There are a couple of obvious benefits (you can think of them yourself)>> The \
> DRAWBACKS I see with this:>> If the libs are separated from the apps and the apps \
> themselves are> distributed independently, then:> * it is more difficult to predict \
> which components (and in which versions)> other people have installed (think of \
> COMBINED DOCUMENTS)
This reason alone is almost enough to disqualify the idea.
> * more frustrations for packagers (and users) after all, because they have> to deal \
>                 with many more tar balls and packages, which also leads to:
> * translations? handbooks? (a language pack for each app for each> language???) * \
> Versioning of apps? The need to release "soon" after a> kolibs release.>> I think \
> we can avoid the last issue by providing "full" translation> packages for all of \
> KOffice, like it's done for KDE itself.
How would you do this if you have separate releases?  
> Despite the drawbacks, I would actually prefer splitting things up. KOffice> has \
> quite some momentum right now, each component (almost?) has people> working on \
> them, and so on.
True, but the momentum is because it's so well integrated, and that is because they \
are released together.  As far as I know, most developers on the KOffice team have \
contributed to more than one application, many to 3, 4 or more.  This will also be \
lessened if the applications and the libs were split up. That would lead to less \
integration and less speedy development.  This does not support your suggestion.
> Another benefit that will come up later is that 3rd party applications can> be more \
> easily provided, after all, since they are in the same boat> (separated from \
> kolibs) as the actual applications themselves. Another> thing is scaled-down \
> versions of KOffice for embedded devices - which will> work better with splitting.
I don't see any reason for this at all. On the contrary, if everything is released at \
once, it is easier to use the kolibs for a certain version of koffice as basis for a \
3rd party application and then know that this version will be stable in the API for \
quite some time.
> At least I see that this split is _required_ at SOME point in time. As I> said, \
> KOffice is already big. Finally I think though that this move would> make kolibs be \
> regarded as a development framework for office applications> with a good \
> integration, where many 3rd parties can participate.
What I DO think is that some applications, most obviously Krita and Kexi and maybe \
also Karbon could have separate released separately between the main KOffice \
releases.  Why these applications?  Mostly because they are not integrated to the \
same degree as the others - It is not likely that you will embedd a word document \
into a Krita image, even though it's possible, and Kexi is not document oriented at \
                all.
	-Inge
-- Inge Wallin               | Thus spake the master programmer:               |      \
|      "After three days without programming,     |inge@lysator.liu.se       |       \
life becomes meaningless."                |                          | Geoffrey \
James: The Tao of Programming.         \
|_______________________________________________koffice-devel mailing \
listkoffice-devel@kde.orghttps://mail.kde.org/mailman/listinfo/koffice-devel


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