User:Jstaniek/Calligra Sprint 2011.2 presentation: Difference between revisions

From KDE Community Wiki
Line 20: Line 20:
===Why Kexi? - introduction for Calligra Developers===
===Why Kexi? - introduction for Calligra Developers===


Why db apps:
*Databases vs Spreadsheets [http://userbase.kde.org/Kexi/Handbook/Introduction_to_Databases/Database_and_Spreadsheet]
Why Kexi instead of server db + apache
*offline mode by default and for free
**utilizing lightweight industry-standard SQLite 3[http://sqlite.org/] 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 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[http://glom.org] is PostgreSQL-only
Kexi Mobile
*N900 loaned to Adam Pigg in October 2010 (Thanks Suresh!)[http://www.piggz.co.uk/index.php?page=blogentry&id=56]
*After two months of development: usable proof of concept - mobile database viewer with forms and reports (KEXI_MOBILE build option)[http://www.piggz.co.uk/index.php?page=blogentry&id=61]
*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
What's new in 2011

Revision as of 00:33, 5 November 2011

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 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


Kexi Mobile

  • N900 loaned to Adam Pigg in October 2010 (Thanks Suresh!)[4]
  • After two months of development: usable proof of concept - mobile database viewer with forms and reports (KEXI_MOBILE build option)[5]
  • 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)[6] and map elements (Marble-based)[7]
    • 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![8]
    • 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"