KoAbstraction is a library utilizing facade design pattern in order to simplify implementation of custom graphical interfaces for various applications.

Status: experimental, in development for 2.4.

Strategically, it's a showcase of #1 KOffice's advantage: portability and flexibility of the core, unmatched independence of the GUI. So far in my opinion we have not encouraged 3rd-parties to use this strength very consequently. It's much easier to expose this strength than first competing in area of features with mature competitors. --jstaniek

This is follow up of KOffice core re-usability request raised for the first time at Akademy 2005, and just recently discussed in Essen 2010 Sprint.

Implementation provided for review at


Most important possible applications of this tool are:

  • Proof of concept koffice app in "100 lines of code or so", for Techbase
    • Status: planning
  • Standalone KOffice viewer widget (can be used in Designer!)
    • Status: planning
  • Proof of concept koffice app for QML (hot topic!) when the APIs support non-QWidget mode
    • Status: planning
  • Proof of concept even higher-level Qt-only API abstracting KOffice core
  • Avoiding creating general-purpose code directly in any current and future use of KOffice core by third parties, assuming that there is a will to collaborate
    • Status: Validated, currently it's avoiding creation of general-purpose code directly in FreOffice, what is part of [1] patch
    • Rationale: previous it was hard not to keep the 3rd-party UI implementation outside of koffice/ source code tree because implementation of the UI may depend on KOffice internals or unstable API; maintaining that within the facade API simplifies a number of tasks
    • Other possible ports: port of the Kids Office
  • Refreshed KPart, to make it behave in a more modern way
    • Status: planning, let's note down our future needs for integration with Okular
  • Integration with plasma (non-QWidget target)
    • Status: planning

All the above is not limited to mobile technologies, and heavily validates quality of the code base and design.

See Also

Technologies utilizing similar concepts: WebKit, Plasma, KDE libs, and Qt itself


Started Jstaniek 20:47, 5 February 2011 (UTC)

Background: The KoAbstraction API version 1 (Calligra master from early 2011) requires include .moc file generated in the library by outside code (e.g. in the f-office app) and using typedef to workaround impossibility of multiple inheritance from QObject-based classes. This is considered as a hack if not fragile and unclear. Also it was requested by the FreOffice developers to fix problems with their custom builds on maemo.

The Goal: refactor the KoAbstraction lib so the API is more natural and has more OOD.


  • KoAbstractApplication:
    • KoAbstractApplication is now a thin interface to inherit by the main application window, e.g. main window of FreOffice. KoAbstractApplication no longer inherits QObject.
  • KoAbstractAppliactionController:
    • KoAbstractAppliactionController is now separate controller inheriting QObject, owned by the KoAbstractApplication-derived class. It contains signals and slots, and should be inherited to customize behaviour and implement abstract interfaces.
    • currentPageChanged() renamed to handleCurrentPageChanged() since it's a placeholder for implementing reaction on page changing
    • documentPageSetupChanged renamed to handleDocumentPageSetupChanged()
    • controller() renamed to canvasController() to avoid silly controller()->controller() expressions
    • controllerWidget() renamed to canvasControllerWidget()
    • doOpenDocument() renamed to openScheduledDocument()
    • removeSheet() renamed to removeCurrentSheet()
    • more setter methods changed to slots


  • A lot of functionality that stays in f-office for now, including code for formatting. It's is planned for the KoAbstraction.
  • Identify methods that would have better not be pure virtual. But note: providing empty methods instead of pure virtuals makes the usage more error prone for developers. The solution could be to group the API into several aspects: viewer/editor and kword/kpresenter/kspread. Then developers can pick their "taste" for their implementation.
  • Document selector with live document preview with kinetic scrolling; like on iWork for iPad but more universal
  • Document zoom for touch devices
    • Optimized multi-touch zoom for documents
    • Single-tap zoom feature for documents, for devices lacking multi-touch (which N900 also is)
  • Shape scaling and rotationg for touch devices
    • Multi-touch scaling and rotation for shapes
    • Single-tap scaling and rotation for shapes

This page was last edited on 23 March 2011, at 08:05. Content is available under Creative Commons License SA 4.0 unless otherwise noted.