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

List:       koffice-devel
Subject:    Re: flake/canvasController
From:       Inge Wallin <inge () lysator ! liu ! se>
Date:       2010-09-17 14:10:59
Message-ID: 201009171610.59954.inge () lysator ! liu ! se
[Download RAW message or body]

On Thursday, September 16, 2010 22:39:44 Thomas Zander wrote:
> On Wednesday 15. September 2010 08.11.24 Cyrille Berger wrote:

> > * an other possibility is to skip the discussion step alltogether and go
> > for review
> > * lastly, you can post design suggestion on this list
> > 
> > All the three alternatives are what we are using on daily basis, I don't
> > see why it would not work for this case.
> 
> Ok, did you really miss the part where the vast majority of the new feature
> is not actually in KOffice svn? Not publicly available for review and
> there is no way to post-commit review if the design makes sense?
> Its not open development if
> a) the design
> b) the functional usecases
> c) the code
> are not available for joe-random to look at and to criticize.

This is simply a price we have to pay if we want our designs to be used as a 
platform as well and not just finished applications.  And this was discussed 
at length at the last sprint in Essen.

It was decided that we want to encourage use of KOffice in mobile applications 
as much as possible, since this is a niche that is still wide open for free 
office packages, and has no other contenders at this time. To do this, we 
acknowledged that some refactorings would have to be done, both in the 
libraries and at the application level.

The patch by boud was a direct application of this: A need to use 
QGraphicsView as a base for the canvas controller was identified, a design and 
implementation was proposed that satisfied that need, it was discussed, Ok'ed 
and committed.

It is true that not all of the feature is open source yet and therefore not 
visible.  In this case I am fairly certain that it will be, but that is a 
little beside the point. The point is that we are letting our package be used 
as a platform, and we have decided to not only allow that but actively 
encourage it.

Now, if there is something wrong with the current technical design, then 
anybody is welcome to reiterate the design-develop-review-commit cycle. It's 
not unlikely that the current design can be improved. But in doing this, keep 
in mind that what the design of the code in the KOffice SVN is about is the 
API itself, not the code that uses the API. 

> > And yes, on that problem, we are
> > working in the dark, but the point of LGPL is to accept to work with
> > proprietary solution (even temporary proprietary), as long as we don't
> > work for them.
> 
> You are wrong; the point of LGPL is that it can be *used* by proprietary
> products.
> Not become entangled with and have code in our lib thats useless without
> the external product.

That is correct.  So is there anything in the current API that you would want 
to change?
_______________________________________________
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]