Calligra/Words: Difference between revisions

From KDE Community Wiki
No edit summary
No edit summary
 
(15 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Calligra/Category:KWord]]
[[Category:Words]]
'''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.


KWord is an application that uses the text (flake) shape to show text-based documents with arbitairy page sizes and it can do a lot of DTP-like functionality due to the featureset that Flake brings to the table.
Here are some pages with more details and design documents (most is leftover from KWord though);
Since the main text layout and rendering core is moved into a flake plugin this can be used by any KOffice application and thus most of the KWord functionality is available across all apps. How this is done is to use the KoText library to contain the text loading code and various interfaces (APIs) for using text in an application.  Most of the functionality is kept out of the KoText library to keep it small to link to and the real code all lives in the text shape (which can be found in the koffice plugins dir).
KoText allows the placement of the text-lines to be reimplemented differently, so KoText has a powerful, but not very featurful version that is used everywhere except for KWord. KWord implements its own text layout class which has additional features that only a word processor needs.
 
After this 10km overview here are some pages with more details and design documents;


=Current Design Explanation=
=Current Design Explanation=
* [[Calligra/Words/Tutorials]] List of tutorials relating to ODF and KWord
* [[Calligra/Words/Tutorials]] List of tutorials relating to ODF and Words
* [[Calligra/Words/Tables]] The tables in KWord can be based on Qt tables, here is how Qt tables work at the low low level.
* [[Calligra/Words/Tables]] The tables in Words are based on Qt tables, here is how Qt tables work at the low low level.
* [[Calligra/Words/RequirementSpecifications/ChangeTracking]] Requirement specifications for Change tracking.
* [[Calligra/Words/RequirementSpecifications/ChangeTracking]] Requirement specifications for Change tracking.
* [[Calligra/Words/Outline]]
* [[Calligra/Text Layout]]


=Future Design"
=User interface Design=
* [[Calligra/Words/Text_Styles_UI_Mockup]]
* [[Calligra/End_2010_Text_Styles_UI_IRC_Meeting]] A  re-work of the text styles tree.


= Usecases for new tech or 'in-development' stuff =
= Usecases for new tech or 'in-development' stuff =
Line 22: Line 25:


=End User Ready=
=End User Ready=
In order to make KWord end user ready we have to know who the end user is. Turns out that there are different definitions which give different answers. The full details can be found at [[Calligra/Words/EndUserReady/Personas]]
In order to make Words end user ready we have to know who the end user is. Turns out that there are different definitions which give different answers. The full details can be found at [[Calligra/Words/EndUserReady/Personas]]


=Bug processing =
=Bug processing =


We had some emails that stated confusion about the KWord bugzilla usage. The best way to help out with bug triaging and reporting is a lot easy to find after the process used by the KWord maintainer become clear.
The Calligra Words bugs are first triaged and prioritized. Depending on interest from developers (often related to priority but not nessessarily so)
 
the fixing will start. This can be anywhere from immidiately to several years later
Bug processing is done in 3 steps;  first a priority is set, this includes a "release_blocker" tag.  Second a bug is marked to be reproducable by setting it to 'new' or closed as fixed.  Last, the bug is fixed and closed.
It is important to realize that the prioritizing is something that is a continues thing; all bugs should get looked at reasonably fast in order to find release blockers and know what the state of the product is and not release something with already reported but not yet noticed release blockers.
 
When the above paragraph talks about prioritizing bugs this means in practice two things;  release-blockers are marked as such (using the keyword) and one of the [[Calligra/Words/EndUserReady/Personas|personas]] is selected.
 
After prioritizing there will be an order; stuff marked as release blocker comes first, stuff marked for persona Susan next etc. The next two steps are done in that order.


All bugs that come in are in the 'unconfirmed' state. This typically means that the bug is not reproduced or has other issues that may still need to be proven in order for the bug to be marked as a real bug. Proof may be asked for things like a user attaching a docx and claiming there is a rendering issue in KWord. What needs to be determined is if the issue is really a missing feature (and should thus be marked as wishlist). What needs to be determined as well is if the importer (filter) may have an issue or if its a KWord core issue.  Ideally an odt is attached that is verified to have the feature. Last; a more detailed textual description of the actual issue should be given. A simple "document looks wrong" or similar is not useful. Ideally we get a document with a minimal example of the issue found.
Prioritization is based on being ready for a basic user like [[Calligra/Words/EndUserReady/Personas|Susan]] or for a more specilized user like A.D.Vance.


After something is confirmed as a bug and cleaned up the developers will typically attack the list of bugs based on priority.  Something marked with the lowest priority will likely not be fixed until all the issues with higher priority are fixed already. (so if you are a bug triager, feel free to ignore bugs that are prioritized with the Berna persona etc.)
Right now we have plenty to do to support Susan, so it's quite unlikely the advanced cases will have much interest, but this is open source, and everybody is free to do what they want, so you never know ;)


* A bug that is unclear and needs more info is closed using the 'needsinfo' resolution (NOT using resolved)
=See also=
* A bug that has not received any update or new information after 6 weeks will get closed.
*[[/DanskInterop/]]
*[[/Requirement Specifications//]]

Latest revision as of 00:36, 9 March 2012

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.

Here are some pages with more details and design documents (most is leftover from KWord though);

Current Design Explanation

User interface Design

Usecases for new tech or 'in-development' stuff

End User Ready

In order to make Words end user ready we have to know who the end user is. Turns out that there are different definitions which give different answers. The full details can be found at Calligra/Words/EndUserReady/Personas

Bug processing

The Calligra Words bugs are first triaged and prioritized. Depending on interest from developers (often related to priority but not nessessarily so) the fixing will start. This can be anywhere from immidiately to several years later

Prioritization is based on being ready for a basic user like Susan or for a more specilized user like A.D.Vance.

Right now we have plenty to do to support Susan, so it's quite unlikely the advanced cases will have much interest, but this is open source, and everybody is free to do what they want, so you never know ;)

See also

Retrieved from "https://community.kde.org/index.php?title=Calligra/Words&oldid=18562"