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

From KDE Community Wiki
m (Bcooksley moved page User:Jarosław/Calligra Sprint 2011.2 presentation to User:Jstaniek/Calligra Sprint 2011.2 presentation without leaving a redirect: Automatically moved page while renaming the user "Jarosław" to "[[User:...)
 
(59 intermediate revisions by 2 users not shown)
Line 2: Line 2:
*Why Kexi? - introduction for Calligra Developers
*Why Kexi? - introduction for Calligra Developers
*Sharing Kexi's CSV import/export engine within Calligra
*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
*Eating our dog food: use Kexi, Tables, Plan, etc. in our work
*Optional topic: Better separation between engine and UI


==Other Plans==
==Other Plans==
Line 18: Line 19:


==Outline==
==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 Kexi? - introduction for Calligra Developers===
===Sharing Kexi's CSV import/export engine within Calligra===
 
===Better separation between engine and UI===
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===
===Eating our dog food===
*Why?
*Eat Why?
**Sends clear message: this software is useful
**Sends clear message: this software is useful
**Testing by fellow contributors is valuable
**Testing by fellow contributors is valuable
Line 41: Line 151:
***Target: Any Calligra contributors and advocates
***Target: Any Calligra contributors and advocates


*Use What?
*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
**Use Kexi for relational data
***Already good for storing and simple queries
***Already good for storing and simple queries
Line 47: Line 163:
***Only simple relational features
***Only simple relational features
***Status: not used, let's start!
***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
***Action point: provide usage scenarios
****Example: CSV import/export
****Example: CSV import/export
***Action point: provide server infrastructure for shared databases
***Action point: provide server infrastructure for shared databases
****some of that public, some of that for contributors only
****some of that public, some of that for contributors only
**Use Tables for tabular data
 
***Status: used for some ods files
*Eat How?
***Action point: identify problems like usability
**Provide "Best practices for own dog food consumers":
**Use Plan for project management
***"Keep separate setup of stable version of used Calligra apps: How and why?"
***Status: some contributors use it
****Separation between development (broken) version and stable (used) version
***Action point: get best practices from them
****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:
**[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)

Latest revision as of 08:39, 13 October 2017

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)