View source for Calligra/Meetings/Mid 2010 meeting/Minutes

= Community discussions =

The following topics were discussed by the whole group.  Decisions made are considered to be the opinion of the KOffice community.

== Microsoft / KOffice meetings ==

Marijn and Jos are going to meet microsoft people to discuss binary msoffice filters next week.  

'''Decisions''':<br/>
* They were asked to inquiry about MS interest in sponsoring export filters.

== Success / Failures ==

Success and Failure was discussed, and in particular which criteria would be used to evaluate if KOffice has succeeded or failed.  The following criteria were agreed on.

Success Criteria

=== lots of users ===
Users are important to make something useful.

* Make it possible for users to use it
* a clear vision
** user interface, lack of important features (such as table support) and bug fixing
** good user documentation
** get the help from a usability expert
** what is the typical user profile?
* how many users do we have and how many can we get through different channels?
** We get hundreds of thousands of users from the mobile version!
** a good windows installer?
** Do we gain much from the kdelibs dependency? Would a Qt-only version make sense? (QOffice ?)
* advertise KOffice more or better
** lack of awareness, articles in magazine (e.g. Linux Magazine Issue #116 / Jul 2010 "We show you the semantic web technology in KOffice")
** push KOffice to users in university (that could then work on fixing bugs they found)
** a clear list of features
** why a user should use koffice ?
** a good website (that would inform on feature in development, more blogging, "last week on KOffice", a feature plan more visible and user oriented)

'''Decisions''':<br/>
From the above we decided that:
* the mobile variants of KOffice are important for the success of KOffice, and that we shall put effort into them.
* to try to find a usability expert to work with.

=== lots of contributors (healthy community with a mix of volunteers and paid developers) ===

Note that contributors are not only developers, but also documentation writers, templates designer, bug triagers, icons artists, etc, etc.

More users will get us more developers and also our main difficulty right now might be to keep the developers we already have.

* friendly community
** Just saying that something bad without pointing to a better direction is killing the fun
** Can we create a more open development process? (Is the reviewboard process unnecessarily cumbersome? Possibly, but real issues are fixed by reviewboard.)
** a better behaved community (less flameware)
** Krita is successful in attracting and retaining developers: it has an open process (mistakes and imperfect code are acceptable), admit your own mistakes and limit (give a chance to people to help), makes a lot of noise (blogblogblog, it worked for Kivio to attract a lot of people, but we are having trouble to retain them)
** give a chance to people to try their own idea, people that stay are people that comes with an itch to scratch
** try to find a balance between inkscape-style project where anything can go and gimp-style project where only what is in the plan goes
** university projects (koffice is interesting because the student project is still alive after the student project is finished)
** We should try to find a balance between creativity and stability.
* How can we get better tools and process? Here are some suggestions:
** a website that is attractive for developers
** lack of documentation of the code structure
** bugzilla, slow, missing features
** Simplifying.  Some parts of the code are complex with functions with hundreds or even thousands of lines.
** stable API
** finished feature in the API
** contact points for libraries / file
** documentation is poorly organized
** Reviewboard
*** make reviewboard easier to use
*** better definition on when to use reviewboard
** make components more reusable
* Lowering the barrier for new developers.  Some suggestions:
** some way to help new developers to get started
** contributes howto, step-by-step
** a SDK? (look at Cornelius livecd for KDE development)
** good list of junior jobs, mentoring for new arrival
** don't move from svn to git (or make git easy to use)
** training package (ie teaching students)
** show the value for students project to push their contribution back

'''Decisions''':<br/>
* Mistakes are allowed!
* We shall try to create a friendlier and more open community.  This means that we will be more open in allowing mistakes and be less finicky in comments and reviews.
* We shall try to make the reviewboard process simpler and less blocking.  Inge got the task to create a set of rules that were discussed during sunday and posted here: [[Calligra/Policies/Review board rules|Review board rules]].

=== compatibility / interoperability (ODF Support) ===

It was discussed what ODF means to KOffice.

* Should we support 100% of the specification?
* users want to be able to round trip, but what about displaying all the possible options ?
* there is a difference between using ODF as native file format and using ODF as a guideline to develop KOffice
* but when writing a feature it is important to think about how it will be saved in ODF
* ODF interoperability is important to KOffice, but not at all cost (object linking, embedded document for instance)
* a contribution for unimportant aspect are acceptable if they are good enough, but they are not points of success/failures
* interoperability needs test
* what about forms ?

'''Decisions''':<br/>
* '''Interoperability is a key feature of KOffice'''
** ODF is the way to go, i.e. priority 1. Some ODF features are border lines and are not considered to be essential, but if someone is willing to write an implementation, it will be accepted by KOffice if it is good enough (code quality, maintainability and UI). It is advised to discuss the project prior to start the implementation, this would increase the chance of the patch to be accepted.
** Missing features are bugs (with some notable exceptions like OLE embedding and java applets in frames). We shall try to support as much of the ODF specification as possible.
** Interoperability can also be achieved by import/export, this is priority 2. Contributions are more than welcome.

=== portability to different kind of environments ===

Because of the decision above to make the mobile version a priority, it was discussed how KOffice makes it easy or difficult for the developer to create alternative user interfaces.

Some observations:
* until one year and half it was only the desktop version
* support more user interface
* is koffice only for the desktop ?
* flexibility is future proof
* API to build the UI on top of it
* appoint a couple of people to investigate the issue
* less KDE dependency for kofficelibs (but not hiding Qt from the API): links against kdelibs mobile !

'''Decisions''':<br/>
* We shall actively work to simplify creating new user interfaces to KOffice.  Nokia will provide detailed feedback on the challenges encountered during their current efforts (f-office and the next generation).
* Boudewijn will, based on this feedback, create a suggestion on how to refactor some classes in libs/main/ and maybe also other places and post this to koffice-devel.

=== roadmap ===
=== vision ===
Neither roadmap nor vision were discussed.  To do that in a good way, we need a vision writer expert.

== Features still missing ==

We still miss a number of features to make KOffice a big success. The missing features were discussed and put into the categories below:

=== Need to have ===

* text on shapes
** A patch exists, created by Thomas, for the basic functionality
** missing loading/saving implemented by Boudewijn using Thorstens suggestion
** but in ODF not all shapes can have it, like charts
** double click show a text tool instead of showing the path tool (not easily fixed), but tool priority is application specific (kword/kpresenter/kivio get the text tool, but krita/karbon should get path tool)
* captions
** could be implemented using the same technique as text on shape
* arrows, line endings
* table editing/creating
** we can create a new table, but we cannot choose border, add rows/cols
* table of content
** Can be read, but you cannot style it
* fit to frame
** load/save but no UI
* better performance for loading of a document (and performance in general)
** not really a feature
** Inge suggested that a mini-sprint for this purpose could be held.  Boudewijn offered to host it for 5 days for a small number of developers to work on it. Nokia tentatively offered to sponsor it.
* sections
* numbering
** of notes, images, captions...
* animation on a page
** being worked on as part of GSoC by Benjamin
* missing variables
** date format, fields like 'email'/'doc-title' etc

(Ed. note: Should really all of these be in the "must have" category?  I don't remember that we decided that)

=== Nice to have ===

* 3D shapes
* style for graphic object (like themes)
* fontwork
* embedded documents as a shape
** perhaps show the replacement picture (but it is in svm, starview metafile, format)
* KSPread: pivot tables
* KPresenter: slide sorter view
* XForms

=== Fun things to implement ===

* different line size on a curve (think comic character outline)
* save the calligraphy support curve

=== Impossible to have ===

* load the first page before the rest of the document

(Ed. note: What do you mean "impossible to have"?)

== Mobile ==

Presentation by Suresh Chande from Nokia. A lot of interest at CeBIT. Many identified bugs, many already closed bugs, bugs also on KDE's bugzilla. Main issue is loading time. Student in Bangalore working on KOffice: FreOffice editor, collaborative editing, opengl transition, gesture control, online integration, presentation companion (use the device with the laptop), web office proof of concept, faxing office document, DICOM file filter.

What about the Meego platform ?

== Website ==

The current design has some flaws.  We lack a webmaster since Alexandra left.

Some suggestions: 
* Only display one news column in the center, and have a side bar with forum link, identi.ca, blog headlines
* download button? We don't need that right now, maybe when the windows/mac version are better
* developer blog on koffice.org (but only titles on the front page)
* Cyrille can take care of putting content on the website
* Boudewijn will write some content:
** Last Week In KOffice
** collecting biography/picture for who is who
* Thorsten will blog about kpresenter

'''Decisions''':<br/>
* Boudewijn will write a weekly feature "This week in KOffice" to increase interest. This will be modeled after "This week in Krita" on krita.org.
* Boudewijn will create a "Who is who" page.
* Cyrille will change the website to have one column with news and a sidebar with buzz updates.

= Technical issues =

The following discussions were made in smaller groups.  Only the people interested in each subject were involved.

== Filter architecture ==

The current filter architecture has some misfeatures (FIXME: link to the wiki page that already exists).

The following was discussed (among other things)
* [[Calligra/File filters]]
* Chaining?
* code reuse
* Suggested optimization: pass the dom tree to kword ? 
** or perhaps instead of KoStore pass the style, content xml, etc

'''Decisions''':<br/>
* Cyrille will investigate how to improve the filters and write a suggestion to koffice-devel.

== Font rendering ==

We have many, many user complaints about font rendering, mainly in KWord.  We realized that we need to fix this.

Some links and insights:
*http://forum.kde.org/viewtopic.php?f=96&t=51044&start=15
*https://bugs.kde.org/show_bug.cgi?id=186513
*http://bugsfiles.kde.org/attachment.cgi?id=34534
*http://slangkamp.wordpress.com/2009/09/29/kword-font-rendering/
**The Cairo backend produces much higher quality output in most cases — especially with regards to text and line art. 
*'''[http://freddie.witherden.org/pages/font-rasterisation/ A Treatise on Font Rasterisation With an Emphasis on Free Software], see 'Obtaining freely scalable text' '''
*http://labs.trolltech.com/blogs/2008/09/01/subpixel-antialiasing-on-x11/ - contact this guy
*http://bugreports.qt.nokia.com/browse/QTBUG-205
*http://www.freetype.org/david/unix-font-rendering.html#what-hinting

Jaroslaw investigated the issue later and found some possible solutions.  He will contact Thomas Zander who will then point to the best person within Qt Development Frameworks to discuss this issue.

== kdchart / kdgantt ==

Soon there should be official open source releases of kdgantt/kdchart which would become external dependencies of KOffice (main reason here is that they can be used in other projects such as kmymoney). Which also mean that the chart plugin of koreport will be able to use it, but it still should be moved from kofficelibs to plugins/.

== Different UIs for different devices ==

(See also above.)
* KoView / KoCanvas are too much intermixed: we should make it possible to paint onto a different canvas and create user interfaces that do not use KoView-derived views.
* Make it possible to render to QGraphicsView (not replace flake with QGraphicsView!)
* Original idea for different UI was to write new dockers /Tools. Right now, tools are intertwined with the shapes so it's hard to replace the interaction model -- tools should be plugins to shapes?
* QML: use it to move away from the docker system?
* Looking at the work from Bangalore student did for FreOffice editing
* separate the widget (input handling) from the code that paint
* API for moving to a different page
* Get more input from Nokia people

== Text layout ==

This was discussed, but no real conclusions were made.