Hi
The feature plan for K 2.0 on
seems a little pale. Lots of things are missing that are already taking place.
The wiki pointed to from that page is a bit more explicit but we need lots
more so lets try to add some.
But I also would like us to compile a list of release goals. That is things
that would delay the release if we are not done. I seriously would not like
us to bump to version 2.0 without having fixed some of the most important
problems we have. the other hand we also need to be realistic because we
want to release if not at the same time as kde4 then very shortly after.
So the list should not have more than say 5 items per application. Maybe less
maybe more depending on manpower and how difficult the items are.
The list contains goals not features. Goals should look beyond just checking a
list of features. Still it should be somewhat measurable, so that when
release draws nearer we can check if we are done in each area.
So here goes my first attempt at a list (many things collected via IRC, thanks
everyone):
General:
1) Where applicable make user interfaces look and work the same.
2) Use flake in every place possible
3) Use pigment (color management) in every place possible
Kross:
1) Performance (this includes a larger refactoring needed)
2) More compatibility with Korundum
KFormula:
1) Provide as a flake-shape
2) Ensure that every reasonable DF and MathML file is loadable
KChart:
1) Provide as a flake-shape
2) Ensure that every reasonable DF file is loadable
KWord:
1) More advanced page usage (pagespreads, numbering can start from !=1)
2) New text engine to print to fix wysiwyg
3) Fix embedding by using flake
4) Much cleaned up GUI by redoing several ugly features
5) Tables (by using a kspread table flake-shape)
6) Ensure that every reasonable DF file is loadable
KSpread:
1) Provide region of sheet as a flake-shape
2) Fix loading of big docs
3) Formula support if the standard is ready
4) Ensure that every reasonable DF file is loadable
KPresenter:
1) Big refactor and cleaning of code into using flake
2) Video and sound
3) Ensure that every reasonable DF file is loadable
Kivio:
1) Big refactor to use flake
2) Masterpages
3) More specialized tools/features to set it apart form karbon
Karbon:
1) Big refactor to use flake
Krita:
1) Testing, bug and usabillity review+fixing
2) Provide a flake shape (a layer)
3) Painterly infrastructure (programmable brush etc)
4) Raster if the standard is ready
Kexi:
1) Better integration into the rest of K (flake shapes?)
2) ways for other apps to tap directly into the DB (without scripting)

2006/7/14, Casper Boemann <cbr (AT) boemann (DOT) dk>:
Kivio:
1) Big refactor to use flake
2) Masterpages
3) More specialized tools/features to set it apart form karbon
I'd change that to:
1) Big refactor to use flake
2) Implement Doc support
3) Make sure old documents can be imported (export will be close to impossible)

14 Uztaila 2006 16:43(e)an, Casper Boemann(e)k idatzi zuen:
KFormula:
1) Provide as a flake-shape
2) Ensure that every reasonable DF and MathML file is loadable
3) Usability

MathML native support will require some UI changes I'm still thinking about,
but I expect to be ready for 1.6. It'll probably some kind of experiment,
since I'm not good at it, but I want something well designed for 2.0, with
help from outside (I'm thinking about openusability) if possible.

KChart:
1) Provide as a flake-shape
2) Ensure that every reasonable DF file is loadable

KWord:
1) More advanced page usage (pagespreads, numbering can start from !=1)
2) New text engine to print to fix wysiwyg
3) Fix embedding by using flake
4) Much cleaned up GUI by redoing several ugly features
5) Tables (by using a kspread table flake-shape)
6) Ensure that every reasonable DF file is loadable

KSpread:
1) Provide region of sheet as a flake-shape
2) Fix loading of big docs
3) Formula support if the standard is ready
4) Ensure that every reasonable DF file is loadable

KPresenter:
1) Big refactor and cleaning of code into using flake
2) Video and sound
3) Ensure that every reasonable DF file is loadable

Kivio:
1) Big refactor to use flake
2) Masterpages
3) More specialized tools/features to set it apart form karbon

Karbon:
1) Big refactor to use flake

Krita:
1) Testing, bug and usabillity review+fixing
2) Provide a flake shape (a layer)
3) Painterly infrastructure (programmable brush etc)
4) Raster if the standard is ready

Kexi:
1) Better integration into the rest of K (flake shapes?)
2) ways for other apps to tap directly into the DB (without
scripting)

Friday 14 July 2006 21:21, Tim Beaulen wrote:
4) Try to load and save svg files perfectly (which also means that
karbon supports everything that's needed to do so. This will require
for example lighting effects etc)

At least without animation, scripting and interactivity.
Unless all Karbon developers decide that these are usefull too, but I
guess they are better serverd in a different program ?

Well, this list was meant to be about goals we set for our apps:
So the list should not have more than say 5 items per application.
Maybe less maybe more depending on manpower and how difficult the
items are.

So, don't put things on your plate that you have to bump to a future
release anyway. (those go on the future list, not on the goals list :-)

Friday 14 July 2006 22:07, Casper Boemann wrote:
Yeah, Tim and other Karbon devs: I trust that when you say this, that you
really think it will be ready for a say newyear freeze date (if I'm to
believe Carsten then KDE will ship in Q1 2007 and so should K)

I tend to classify Carsten in the very optimistic list of people :) But that
said, it might be a good idea to consider a feature freeze around the end of
january, beginning of februar, and to define reachable goals by that time.

If the time get extend, you can then start working on long term goals :)

Friday 14 July 2006 21:56, Thomas Zander wrote:
Friday 14 July 2006 21:21, Tim Beaulen wrote:
4) Try to load and save svg files perfectly (which also means that
karbon supports everything that's needed to do so. This will require
for example lighting effects etc)

At least without animation, scripting and interactivity.
Unless all Karbon developers decide that these are usefull too, but I
guess they are better serverd in a different program ?

Well, this list was meant to be about goals we set for our apps:
Yeah, Tim and other Karbon devs: I trust that when you say this, that you
really think it will be ready for a say newyear freeze date (if I'm to
believe Carsten then KDE will ship in Q1 2007 and so should K)

I really would hate if we were to delay K because you got on too deep
water so to speak ;)

Don't get me wrong I think it's a nice goal - just be sure you have the
manpower to get done. and that includes that for every manhour working on
a feature that isn't a goal the more will the rest of your team have to work
on your goals.

, then forget my additions.
I was a little too fast.

7/14/06, Cyrille Berger <cberger (AT) cberger (DOT) netwrote:
Friday 14 July 2006 22:07, Casper Boemann wrote:
Yeah, Tim and other Karbon devs: I trust that when you say this, that you
really think it will be ready for a say newyear freeze date (if I'm to
believe Carsten then KDE will ship in Q1 2007 and so should K)

I tend to classify Carsten in the very optimistic list of people :) But that
said, it might be a good idea to consider a feature freeze around the end of
january, beginning of februar, and to define reachable goals by that time.

If the time get extend, you can then start working on long term goals :)

General:
1) Where applicable make user interfaces look and work the same.
2) Use flake in every place possible
3) Use pigment (color management) in every place possible
4) all widget are ui files