User:Jstaniek/Calligra Sprint 2011.2 presentation

From KDE Community Wiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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

  • Blog: http://blogs.kde.org/node/4515
  • 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:

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. [done] Integration idea: Reusing Kexi's Forms in office apps
  6. Integration plan: Add flake based reports to KoReports for mail merge, reuse it in other apps [12]
  7. Integration idea: Reusing Kexi's Modern GUI in other Calligra apps
  8. Integration plan: Sharing Kexi's CSV import/export engine within Calligra 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)