[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: KOffice 2.2, usability and the Q4 sprint
From: Cyrille Berger <cberger () cberger ! net>
Date: 2009-09-02 12:05:00
Message-ID: 200909021405.00821.cberger () cberger ! net
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
There is something that wasn't mentioned, API freeze, means also fixing the
behaviour of a function, while fixing a compilation error when the name of a
function/class change is quiet easy, the behaviour (of order of function call)
is a bit more sneaky. With the API stability, the behaviour is also supposed
to become more stable. I would expect that it will also make us quit the state
of mind that we had during the 2.0 development cycle, where breaking
everything to make it better was acceptable. Now we need stability in our
library, stability that (I hope) will put a stop to the flow of regressions we
are experiencing with 2.1. Regressions that makes us lose our time, and will
have a big impact on wether KOffice become user ready.
Personnaly, I find more annoying a crash, than having to double click to
activate a tool in kpresenter...
> Just to pick a trivial example, I become irritated every time I have to
> double click on a shape to get its config dialog to open. Somebody said it
> was dependent on applications, but as I said: it's just an example.
Which should raise the question of why it wasn't fixed in the given application
(is there even a bug report for that somewhere ?). And not of how to change
the interraction... since everybody agrees that the double click behaviour is
wrong. but obviously, we have a lack of developer resources.
On Wednesday 02 September 2009, Inge Wallin wrote:
> 1. Design our API's and freeze them to make it easier to get outside help.
+ "and to stabilize our library".
> 2. Take care of the remaining UI issues and make the already correct
> working apps more shiny.
>
> or:
>
> 1. Design a natural and well functioning UI
> 2. Freeze our API's now that we really know what we need.
>
> The main risk with the first approach is: what if we find out that we need
> to change our API's to achieve what we want in step 2? I.e. what if our,
> now frozen, API's don't support what we need in order to achieve the well
> working UI? Then we are, as they say, screwed.
The main risk with the second approach is that we get to redevelop a lot of
things because the foundation of the software wasn't good. And therefor lose
something that is a rare ressource in the KOffice project: developer time.
It's also worth to note that the API freeze/design is likely to mostly concern
libflake, libkodf (maybe pigment, but that's mostly a Krita issue, and a few
helper library such as kostore, but whose API hasn't changes in years). And I
surely hope that at the end of that process we will be able to build on top of
those libraries any kind of UI interraction we want, or otherwise I am going
to revisit my opinion of the people (aka the Trolls) that are going to help us
to do that ;)
--
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;">There is something that wasn't mentioned, API \
freeze, means also fixing the behaviour of a function, while fixing a compilation \
error when the name of a function/class change is quiet easy, the behaviour (of order \
of function call) is a bit more sneaky. With the API stability, the behaviour is also \
supposed to become more stable. I would expect that it will also make us quit the \
state of mind that we had during the 2.0 development cycle, where breaking everything \
to make it better was acceptable. Now we need stability in our library, stability \
that (I hope) will put a stop to the flow of regressions we are experiencing with \
2.1. Regressions that makes us lose our time, and will have a big impact on wether \
KOffice become user ready.<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>Personnaly, I find more annoying a crash, \
than having to double click to activate a tool in kpresenter...<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>> Just to pick a trivial example, I become irritated \
every time I have to <br> > double click on a shape to get its config dialog to \
open. Somebody said it <br> > was dependent on applications, but as I said: it's \
just an example.<br> Which should raise the question of why it wasn't fixed in the \
given application (is there even a bug report for that somewhere ?). And not of how \
to change the interraction... since everybody agrees that the double click behaviour \
is wrong. but obviously, we have a lack of developer resources.<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>On \
Wednesday 02 September 2009, Inge Wallin wrote:<br> > 1. Design our API's and \
freeze them to make it easier to get outside help.<br> + "and to stabilize our \
library".<br> > 2. Take care of the remaining UI issues and make the already \
correct<br> > working apps more shiny.<br>
><br>
> or:<br>
><br>
> 1. Design a natural and well functioning UI<br>
> 2. Freeze our API's now that we really know what we need.<br>
><br>
> The main risk with the first approach is: what if we find out that we need<br>
> to change our API's to achieve what we want in step 2? I.e. what if our,<br>
> now frozen, API's don't support what we need in order to achieve the well<br>
> working UI? Then we are, as they say, screwed.<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>The main risk with the second approach is that we get to \
redevelop a lot of things because the foundation of the software wasn't good. And \
therefor lose something that is a rare ressource in the KOffice project: developer \
time.<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>It's also worth to note that the API freeze/design is \
likely to mostly concern libflake, libkodf (maybe pigment, but that's mostly a Krita \
issue, and a few helper library such as kostore, but whose API hasn't changes in \
years). And I surely hope that at the end of that process we will be able to build on \
top of those libraries any kind of UI interraction we want, or otherwise I am going \
to revisit my opinion of the people (aka the Trolls) that are going to help us to do \
that ;)<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