View source for User:Jstaniek/Calligra Sprint 2011.2 presentation

==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 [http://userbase.kde.org/Kexi/Handbook/Introduction_to_Databases/Database_and_Spreadsheet]

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[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! (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[http://glom.org] is PostgreSQL-only
*Zero alternatives in FOSS Qt/KDE world
**KNoda no longer maintained[http://www.knoda.org]
**Rekall is abandoned

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
**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)[http://community.kde.org/Kexi/Junior_Jobs/Web_Browser_Form_Widget] and map elements (Marble-based)[http://community.kde.org/Kexi/Junior_Jobs/Map_Browser_Form_Widget]
**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![http://userbase.kde.org/Kexi/Handbook]
**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)[http://community.kde.org/Kexi/Links#Kexi-based_bugzilla_client]
****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===
*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:
**[http://www.word-2010.com/microsoft-word-2010-themes/ Themes in MSO 2010]
**[http://www.homeandlearn.co.uk/word2007_2010/s2p6.html Theme fonts in fonts combo (MSW 2010)]
**Theme creator - [http://www.word-2010.com/microsoft-word-2010-creating-theme-colours-and-fonts/#ixzz1f2Rzm22I example for MSO 2010]

===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 [http://www.swierkowski-online.de/inve21_1.jpg 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."[http://miksovsky.blogs.com/flowstate/2011/04/start-with-a-stripped-down-visual-design-and-slowly-add-elements-back-in.html]

 "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 ==
#[done] Branding
#[done] Introduction to Kexi
#[done] [[#Eating_our_dog_food|Eating our dog food]]
#[done] Integration idea: [http://community.kde.org/User:Jstaniek/Calligra_Sprint_2011.2_presentation#Integration_idea:_Shared_Calligra_Themes Shared Calligra Themes]
#[done] Integration idea: [http://community.kde.org/User:Jstaniek/Calligra_Sprint_2011.2_presentation#Integration_idea:_Kexi_Forms_for_Calligra_apps Reusing Kexi's Forms in office apps]
#Integration plan: Add flake based reports to KoReports for mail merge, reuse it in other apps [http://community.kde.org/Calligra/Meetings/Fall_2011_meeting/Minutes#KoReports_and.2For_mail_merge.3F]
#Integration idea: [http://community.kde.org/User:Jstaniek/Calligra_Sprint_2011.2_presentation#Reusing_Kexi.27s_Modern_GUI_in_other_Calligra_apps Reusing Kexi's Modern GUI in other Calligra apps]
#Integration plan: [http://community.kde.org/User:Jstaniek/Calligra_Sprint_2011.2_presentation#Integration_idea:_Sharing_Kexi.27s_CSV_import.2Fexport_engine_within_Calligra Sharing Kexi's CSV import/export engine within Calligra apps]
#Integration idea: OwnCloud/Google Cloud integration for Kexi storage
#Plan: [[Calligra/Meetings/Fall_2011_meeting/Minutes#Idea:_User_feedback_module|User Feedback Module]]
#Initiating tasks for (QtScript-based) user scripting API in Kexi (mission, object model, guidelines)