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

  • Contributors want recognition THEIR work
  • Contributors don't block derivative works
    • but not at cost of their REPUTATION

want recognition their work

  • Logo vs Icon
  • Copyright vs Trademark
  • Avoiding Logo misuse: Clear Guidelines

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

Making Calligra Unique

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

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

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]

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 may be 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> qtscipt/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 :)

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