On 14 November 2011 21:30, Sebastian Sauer <m...@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) _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
