User:Jstaniek/Calligra Sprint 2011.2 presentation

My Plans

• Why Kexi? - introduction for Calligra Developers
• Sharing Kexi's CSV import/export engine within Calligra
• Eating our dog food: use Kexi, Tables, Plan, etc. in our work

• Optional topic: Better separation between engine and UI

Other Plans

(from https://sprints.kde.org/sprint/43)

• Shreya: Improving UI and features of Kexi Web Element,fixing bugs, Multimedia in Kexi
• Dimitrios:
  • Need for Interoperability between Calligra apps
  • UI perspective from a non developer
  • Promoting Calligra
  • Plug-ins K.I.S.S. proposal
  • Calligra and DTP (ideas)
  • Kexi Documentation / Making documentation roadmaps
• Radek: bug hunting in kexi, futher maps plugin expand

Outline

Calligra Branding

• Since the day one Calligra is THE new quality!
• Contributors want recognition for THEIR work
• Contributors take responsibility for THEIR work
• Contributors don't block derivative works
  • but not at cost of their REPUTATION

So we have

• Logo vs Icon
• Copyright vs Trademark
  • Trademark registration: KDE e.V. as Calligra is informal group
  • Copyright to be discussed (CC-BY-SA or LGPL)
  • Idea: Dual logos (one free, one protected) as Debian
• Avoiding Logo misuse: Clear Guidelines
  • Usage in context of Calligra Suite: without permission
  • Usage as source for derivatives: MUST BE out of context of Calligra Suite
  • It's up to Calligra contributors to react on logo misuses and suggest right solution

Why Kexi? - introduction for Calligra Developers

Why db apps:

• Databases vs Spreadsheets [1]

The Kexi Project

• Started in 2002
  • with KOffice/Calligra from the day one
• Had full-time contributor in 2003-2007
• First nontrivial KDE app on Windows
  • Driving force of the KDE on Windows project
• Maintained with one consistent vision since 2003
• Not a MS Access clone
  • less tied to the file db specifics than MS Access
  • GUI does not mimick MS Access
• but acknowledges advantages of desktop databases
  • aimed at casual users and power users
  • almost no database knowledge needed
    • user discovers features while using Kexi
  • not much aimed at developers
    • default GUI not cluttered with developer-oriented features
    • lower priorities for these features

Why Kexi instead of server db + php + apache?

• offline mode by default and for free
  • utilizing lightweight industry-standard SQLite 3[2] file db engine
  • empty database is 9KB!
  • More popular/standard than LibreOffice base format (because there is no ODF for databases)
• point-and-click technology
• good for education
• good for prototyping
• good for preparing quick & dirty "office tools"
• really smooth transition from file db to server db

Kexi specifics

• Constant time startup! (no matter how big database is)
• Cannot edit databases that it did not create
  • this may be removed in 3.x to some extent
• Best known for its ease of use, (partial) MS Access support and good CSV support
• Kexi is not document-driven
  • The GUI has always been specific compared to document-driven apps
  • Even when file db is used, data is saved automatically at record (row) level, not whole database level
  • Kexi GUI is consisted of largely separated views (aspects) much like in current KDevelop or Qt Creator
  • Large emphasis on concept of data model, data and views
  • Customizable GUI
    • also serves as building block for fully-featured user applications
    • Document-driven apps' user content is the central frame
    • Kexi's user content is the whole application main window, with menus, toolbars
    • [picture]
  • Modern GUI initiated in 2011 (not 1980s) pushes the differences further, addresses specific needs not met by KDE3 GUIs
    • TODO: show app, search
  • Still, Qt Style awarness is kept

Why Kexi and not Qt Designer + Qt/C++ development

• no need for tons of glue code
• no need for knowledge of database internals/specifics
• zero compilation: timesaver, architecture-independent
• still, extension APIs blends well with Qt/KDE/C++ development
• prepared for good built-in scripting features
  • (still experimental due to unstable API, not technology problems)

Competition

• Kexi is really competitive compared to FOSS alternatives
  • LibreOffice Base is plagued by bad tech decissions of SUN (dependency on Java, tried to be MS Access clone, GUI based on poor framework => usability problems), lack of contributors
  • GNOME's Glom[3] is PostgreSQL-only
• Zero alternatives in FOSS Qt/KDE world
  • KNoda no longer maintained[4]
  • Rekall is abandoned

Kexi Mobile

• N900 loaned to Adam Pigg in October 2010 (Thanks Suresh!)[5]
• After two months of development: usable proof of concept - mobile database viewer with forms and reports (KEXI_MOBILE build option)[6]
• No development of Qt Quick-based UI for now
  • Such UI would be lightweight and very similar to Harmattan Office
  • There are plans to start with Kexi Mobile Forms in Qt Quick
  • Experience in this technology: Kexi developer Adam Pigg

What's new in 2011

• Successfull two GSoC projects: web elements (QtWebKit-based)[7] and map elements (Marble-based)[8]
  • Both are good example of code reuse
  • Both students (Radek, Shreya) becoming regular contributors!
  • This is second Sprint for Radek
• Finally: actual and maintained documentation![9]
  • Done by Dimitrios, with huge attention to details and knowledge
  • Dimitrios becoming Kexi developer too!
  • Status: three new developers in 2011!
    • willing to take part in Calligra Academy

Kexi-Calligra integration

• Plan: develop mail merge within Kexi as a service for use in other apps (especially Calligra apps)
• Plan: the same for data entry/import/export support
• Idea: the same for forms support
• Idea: experiment with reusing Kexi GUI in other Calligra app(s)

Eating our dog food

• Eat Why?
  • Sends clear message: this software is useful
  • Testing by fellow contributors is valuable
  • Generates usage scenarios and then requirements
  • Brings ideas for improvements in terms of integration with other apps
    • Helps avoid feature duplication
  • If right tool picked, development process improves
  • Team building
  • Easier to understand and acknowledge differences between apps
  • Helps identify specific competences among contributors

• Use Where? 3 aspects
  • Reusing our features of one app in other apps (instead of reinventing)
    • Target: Calligra developers/designers
  • Using our apps in the development process
    • Target: Any Calligra contributors
  • Using our apps elsewhere, in activities not related to Calligra
    • Target: Any Calligra contributors and advocates

• Eat What?
  • Use Tables for tabular data
    • Status: used for some ods files
    • Action point: identify problems like usability
  • Use Plan for project management
    • Status: some contributors use it
    • Action point: get best practices from them
  • Use Kexi for relational data
    • Already good for storing and simple queries
    • Not yet good for analyzing
    • Only simple relational features
    • Status: not used, let's start!
    • Idea: Make Kexi useful as GUI for KDE Bugzilla.
      • Use bugzilla's webservices for this. Probably separate plugin could be developed. Online/offline operations with synchronization. (discussed with Inge who likes the idea)[10]
      • Use Kexi to maintain data for automatic changelogs (with server db)
    • Action point: provide usage scenarios
      • Example: CSV import/export
    • Action point: provide server infrastructure for shared databases
      • some of that public, some of that for contributors only

• Eat How?
  • Provide "Best practices for own dog food consumers":
    • "Keep separate setup of stable version of used Calligra apps: How and why?"
      • Separation between development (broken) version and stable (used) version
      • Minimal compilations for development (e.g. Krita-only) can be still used while having access to all needed Calligra apps
      • Already practiced by contributors anyway: they tend to keep multiple build directories with stable/broken versions; now it can be extended
    • "App user: Provide feedback to app developers in context of your use cases"
    • "App developer: Provide updates to users in context of your new possible use cases"

BoF Topics

Integration idea: Shared Calligra Themes

• Theme is a set of styles defining every visual aspect of document
• Goal: enabling users to work with styles via themes
  • Default theme could be selectable globally in Calligra
  • When working on multiple documents in various formats (ODF, Kexi...) having common theme could contribute to more professional effect
  • In some aspects theme can define GUI elements that are not well defined by QStyle/KStyle
    • spreadsheet grid and cell styles (Calligra Tables) and database tables grid (Kexi) can have common look defined by a theme; TODO: [mockup]
• Current state
  • MSOOXML format has notion of themes (default and user defined)
    • references them instead of embedding styles but
  • ODF does not define themes, these can be built on top of ODF
• Global support for themes can be used:
  • in documents (odt, ods, odp)
  • in reports of any types, especially KoReports
  • in Kexi views, currently forms and tables
• TODO: [mockup of Kexi report and Words document]
• Examples:
  • Themes in MSO 2010
  • Theme fonts in fonts combo (MSW 2010)
  • Theme creator - example for MSO 2010

Integration idea: Sharing Kexi's CSV import/export engine within Calligra

• History of CSV import/export features in Calligra
  • Originally developed for in Tables
  • Re-used by Kexi 0.x, planned for re-integration into Tables, never happened
    • So two copies do exists, Kexi's one is far more advanced
    • Excuse: Kexi's fork still in development, many TODOs

• Specifics:
  • Import of tabular data
    • so main target applications are Tabes and Kexi
    • secondary use cases: Words and Stage
  • CSV export allows to use CSV as exchange format between apps when there is no better option
  • In Kexi also used for clipboard handling of tabular data

• Integration issues
  • Size of codebase: relatively small but quite complicated
  • Database-awarness vs Spreadsheet awarness
    • needs smart abstraction some layers to keep maximal efficiency
    • needs abstraction for different GUIs
  • Common code can dramatically improve clipboard support for tabular data
    • Type detection
      • TODO: EXAMPLE
    • (Semi-)autodetection detection of structure
      • TODO: EXAMPLE

Integration idea: Kexi Forms for Calligra apps

• Scripted functionality in LibreOffice tend to be added via forms with buttons embedded in document exampe invoice form
• this is example of bad design, escaping from document paradigm to application paradigm
• instead creating flake tool-compatible side-panes could be enabled with a few mouse clicks
• GUI for them may be delivered with help of Kexi Form designer
• The effect: so the document is not cluttered, stays just document
  • the scriped functinality is injected in application(s) instead of injecting into document
• Rationale: it is out of scope for Calligra to support VB/StarBasic and forms
  • any partial support defined by ODF is not worth effort: compatibility with LibreOffice would have to be high

<piggz> would be very awesome to have a sidebar in words as a plugin that allows
        ad-hoc buttons to be placed that have access to qtscript + the document
        internals
<piggz> qtscript/kross backends
<piggz> would make words almost as good as reports :)
<piggz> maybe implement in tables first, as spreadsheets have more structure :)
<piggz> and probably more useful there
<piggz> that is likely something i could get my teeth into :)

Integration idea: KoReports-based mail merge

• Two types of reports: the currently used by Kexi and ODF templates/generation

Reusing Kexi's Modern GUI in other Calligra apps

• On demand API can be provided and extended
• Only proof-of-concept for now
• The Design Maxim: "Start with a stripped-down visual design and slowly add elements back in."[11]

"La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter,
  mais lorsqu'il n'y a plus rien à retirer.
 Perfection is attained, not when no more can be added, but when no more
  can be removed."
                        —Antoine de Saint-Exupéry

Blogs

1. [done] Branding
2. [done] Introduction to Kexi
3. [done] Eating our dog food
4. [done] Integration idea: Shared Calligra Themes
5. Integration plan: Add flake based reports to KoReports for mail merge, reuse it in other apps [12]
6. Integration idea: Reusing Kexi's Modern GUI in other Calligra apps
7. Integration plan: Sharing Kexi's CSV import/export engine within Calligra apps
8. Integration idea: Reusing Kexi's Forms in office apps
9. Integration idea: OwnCloud/Google Cloud integration for Kexi storage
10. Plan: User Feedback Module
11. Initiating tasks for (QtScript-based) user scripting API in Kexi (mission, object model, guidelines)