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

List:       koffice-devel
Subject:    Re: Bugfixes and Features
From:       Cyrille Berger <cberger () cberger ! net>
Date:       2009-10-27 12:23:45
Message-ID: 200910271323.45771.cberger () cberger ! net
[Download RAW message or body]

It's rather easy, actually. Data loss are obvious bug fixes, and fixing the 
round trip fix a data loss. While displaying on screen increase the 
functionnalities of KOffice, hence is a new feature.

In any case, unless the patch is a two liners (and branch/2.1 isn't frozen), 
bug fix for data loss are ok in the branch. Otherwise, post the patch for 
review here, and then we can decide if it is safe to apply or not.

On Tuesday 27 October 2009, Inge Wallin wrote:
> 1.  I make the msword filter read a new property that wasn't covered before
> and write the appropriate odf.  Not handling the property wasn't bug
>  reported on b.k.o.
> 
> 2. Same as 1 but a user has bugreported it and insists that not handling
>  this property is a bug and destroys his ability to use the application.
I don't see a difference between 1 and 2. You can give the user a patch to use 
at his own risk that solve the problem.

> 3. I implement reading a new ODF attribute for a tag, and save it back. 
>  This means that roundtripping is improved (i.e. data loss is lessened). 
>  The attribute isn't visible in the UI at all.
bug fix

> 4. Same as 3, but now the attribute is shown in the document View.  By
>  doing this, the layout is improved but there is no way for the user to
>  edit it (that would be an obvious new feature).  An example of this could
>  be that kword currently reads the margin attributes, but not the padding
>  ones. This leads to errors in how large the text area is on a page
>  compared to OOo and, I suppose, to how the spec was intended.
User visible => new feature

> 5. Same as 3, but now it's a new visible feature that wasn't visible
>  before. An example of this could be page borders.  Still no way for the
>  user to edit, of course.
User visible => new feature

> 6. I implement reading, storing and showing a new ODF element (here I
>  suppose there still are unimplemented XML elements in the standard). It
>  shows something visible on the screen that is a larger change than just a
>  somewhat different formatting or so. Still no editing for the user.
User visible => new feature

-- 
Cyrille Berger
_______________________________________________
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]