User:Jstaniek/Calligra Sprint 2011.2 presentation

From KDE Community Wiki

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]

The Kexi Project

  • Started in 2002
    • with KOffice/Calligra from the day one
  • Maintained with one consistent vision since 2003
    • Not a MS Access clone but acknowledges advantages of desktop databases
  • Had full-time contributor in 2003-2007
  • First nontrivial KDE app on Windows
    • Driving force of the KDE on Windows project

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
  • Kexi is not document-driven
    • Even when file db is used, data is saved automatically at record (row) level, not whole database level
  • Best known for its ease of use, (partial) MS Access support and good CSV support
  • The GUI has always been specific compared to document-driven apps
    • 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
    • Modern GUI initiated in 2011 (not 1980s) pushes the differences further, addresses specific needs not met by KDE3 GUIs
    • Still, 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

Making Calligra Unique

  • Idea: develop mail merge within Kexi as a service for use in other apps (especially Calligra apps)
  • Idea: the same for forms support
  • Idea: the same for data import/export support

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

Better separation between engine and UI

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"
Retrieved from "https://community.kde.org/index.php?title=User:Jstaniek/Calligra_Sprint_2011.2_presentation&oldid=15792"