User:Jstaniek/Calligra Sprint 2011.2 presentation

My Plans

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

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

Why Kexi? - introduction for Calligra Developers

Why db apps:

• Databases vs Spreadsheets [1]

Why Kexi instead of server db + 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!
• Cannot edit databases that it did not create
  • this may be removed in 3.x to some extent

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 enable Qt/KDE/C++ development
• prepared for good built-in scripting features
  • (still experimental due to unstable API, not technology problems)

Making Calligra Unique

• Kexi is really competitive compared to FOSS alternatives
  • LibreOffice Base is plagued by bad tech decissions of SUN (dependency on Java, 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 (only plans)
  • If there is such version it would be as lightweight as Harmattan Office

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

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

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!
    • 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"