Calligra Words mission statement and roadmap (1st draft)

[Jaroslaw Staniek]

On 14 November 2011 21:30, Sebastian Sauer <mail at dipe.org> wrote:
> On 11/14/2011 01:51 PM, Pierre Stirnweiss wrote:
>
> 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.
>
> Do you mean that the only difference between a 2.5 and 2.6 release
> announcement would be the release number????
>
> No, that was an example. Think of a document where you list
> all changes done between the 2.x versions. Then you can just
> add a new chapter for a new version that includes the changes
> done in e.g. 2.6, change the version-uservariables from 2.5 to
> 2.6 and have text like "The last version of Calligra is [2.6]" or
> "Last release on [2011-12-24]" auto-updated.
> Other examples could be a reference-number in an
> invoice or a postal code, city-name, etc. pp.

Looks like a task for ODT report generator out of database with simple
GROUP BY and SORT and/or WHERE clauses. All in the background of
course, user only clicks ~twice ;)

With QtScript API for some CalligraLibs (in my TODO) features like
this would be even made available independently of Calligra releases!

-- 
regards / pozdrawiam, Jaroslaw Staniek
 http://www.linkedin.com/in/jstaniek
 Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
 KDE Software Development Platform on MS Windows (windows.kde.org)