Calligra/Libs/KoAbstraction: Difference between revisions
Created page with '__TOC__ ==Introduction== '''KoAbstraction''' is a library utilizing facade design pattern in order to simplify implementation of custom graphical interfaces for various applica...' |
No edit summary |
||
Line 13: | Line 13: | ||
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. | 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 http:// | Implementation provided for review at http://git.reviewboard.kde.org/r/100304/ | ||
==Applications== | ==Applications== |
Revision as of 21:38, 7 January 2011
Introduction
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 http://git.reviewboard.kde.org/r/100304/
Applications
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
TODOs
- 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