Calligra Words mission statement and roadmap (1st draft)

Sebastian Sauer mail at dipe.org
Mon Nov 14 04:54:55 GMT 2011


On 11/13/2011 12:39 PM, C. Boemann wrote:
> During todays meeting it became apparent that we all more or less agree on the
> mission statement and roadmap, so I was tasked to write something down on
> paper.
>
> Mission statement
> ------------------------
> Calligra Words is for creating word processing documents, and not for desktop
> publishing. Our focus is to provide a powerful and easy to use experience for
> everyone without being the specialized tool for any specific group of users.
> That said we try to have enough separation in our code that people (maybe even
> ourselves in the future) can create extra plugins or custom user interfaces.
>
> RoadMap
> ------------
> The goal is to be ready for 2.6 for regular usage without having all the more
> special features that are just nice-to-have.
>
> Qt 5 patches (boemann, pierreSt)
>
> general stabilization (sebsauer, leinir, pinaraf, boemann, boud, pierreSt,
> gopalK)
>
> viewer/layout features (sebsauer)
>
> ms filters improvements (uzak, mauro-nazardo)
>
> These are the features that we want done for 2.5 (4 months from now):
>   -Foot and endnotes, feature complete (erione)
>   -Bibliography,  feature complete (smitpatel)
>   -Captions and index (smitpatel, erione, gopalK)
>   -List ui, basic (gopalK)
>   -LtR review (moji, boemann)
>   -Stylemanager (moji, pinaraf, piereSt, boemann)
>   -Tables formatting ui (gopalK, pinaraf, boemann)
>   -Statistics docker (shreya)
>   -Spellchecking (sherya)
>   -Anchoring ui apply (leinir, sebsauer, boemann)
>   -Section columns, preparatory code restructure (leinir, boemann)

- User defined variables (sebsauer)

Background: I indeed think that is a rather important feature
cause it's the only way to get content into a document that
can be in a centralized way edited/updated. Means you for
example a document describing the features of Calligra as
released and then add a user-variable field for the
version-number (e.g. 2.5 in our case). Then in some months
if the document is updated to reflect what 2.6 is about
someone only need to change the content of the
calligra-version variable and voila. The alternate is to find+
replace for "2.5" manually which is error-prune.

The logic+code is mostly done and lives in an own branch.
What still needs to be done is;
1. refactor to make it as Zagge suggested (using the
LoaderContext and make it proper working in Stage and
Tables too).

It stays an open question if that feature is still allowed
to go in for 2.5 or has to wait for 2.6. Personally I
don't really care here as long as we have it in sooner
or later :-)

> These are the features that we want done for 2.6 (8 months from now):
>   -Section columns, actual columns (leinir, boemann)
>   -List ui, direct visualization and manipulation (gopalK, boemann)
>   -anything not finished for 2.5, but we naturally made it all ;)

- table templates (sebsauer)

I think it's a rather important feature. In that case not
really driven by user-request (well, at least me could be
fine without) but more by real ODF document out there
that are using those feature and are displaying
completely wrong if we don't too (compare here the
test-doc from the ODF sprint in Berlin which was using
table templates).

It stays an open question if we really like to support
table templates or if just solving the styles+etc during
loading only is the better way to go. Guess that could
need some discussion.

> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>




More information about the calligra-devel mailing list