(General Session)
Line 9: Line 9:
 
** UI for enabling/disabling plugin, shapes should probably allways be available for loading a document, but might be hidden in the UI
 
** UI for enabling/disabling plugin, shapes should probably allways be available for loading a document, but might be hidden in the UI
 
* release cycle: keep a 6 month schedule ? go for a three features release cycle per year + 1 long-term-support ? allways summer in trunk ? IE define a new workflow. (Cyrille)
 
* release cycle: keep a 6 month schedule ? go for a three features release cycle per year + 1 long-term-support ? allways summer in trunk ? IE define a new workflow. (Cyrille)
 +
*Scripting (piggz)
 +
**Id like to see each application provide a scripting API, that is callable from all other applications
 +
***E.g At the click of a button on a form in Kexi, i'd like to use the Tables API to parse, or write out to a spreadsheet, or the Words API to write out a document
 +
***Or, in tables, run a script that gathers data from various sources, including a kexi database
 +
****This would probably be possible by sharing the KexiAdapter Kross class? 
 +
**Perhaps..each application could provide a plugin, that exports a single Kross::Object containing the app API/objects??
 +
**All ideas open for discussion!
  
 
== BoF ==
 
== BoF ==
 
* plans for plugins could be discussed in more details by a smaller group of people (Cyrille)
 
* plans for plugins could be discussed in more details by a smaller group of people (Cyrille)

Revision as of 22:11, 4 January 2011

Tell here about things you want to discuss, so that we can prepare an agenda.

Please add yourself as an 'owner' of an idea and prepare something if applicable to make optimal use of our time. Indicates what you want to be developed in a general session (on Saturday), or in a BoF (on Sunday)

General Session

  • plugins: there are several issues or lacking aspect in Calligra's plugins. (Cyrille)
    • First of all right now loading an applications tends to drag a lot of other applications stuff, for instance "the spread sheet shape" which is loaded by many application also load kspread. A solution would be to load shape-on-demand, this trigger a problem with shapes that share the same tag in an ODF file and need some way to know which shape to use (solution could be two c++ plugin, one with a factory one with the shape/tool, or if we can define which shape to use using a text description (like it is done by mimetype definitions) or a small js)
    • UI for enabling/disabling plugin, shapes should probably allways be available for loading a document, but might be hidden in the UI
  • release cycle: keep a 6 month schedule ? go for a three features release cycle per year + 1 long-term-support ? allways summer in trunk ? IE define a new workflow. (Cyrille)
  • Scripting (piggz)
    • Id like to see each application provide a scripting API, that is callable from all other applications
      • E.g At the click of a button on a form in Kexi, i'd like to use the Tables API to parse, or write out to a spreadsheet, or the Words API to write out a document
      • Or, in tables, run a script that gathers data from various sources, including a kexi database
        • This would probably be possible by sharing the KexiAdapter Kross class?
    • Perhaps..each application could provide a plugin, that exports a single Kross::Object containing the app API/objects??
    • All ideas open for discussion!

BoF

  • plans for plugins could be discussed in more details by a smaller group of people (Cyrille)

Content is available under Creative Commons License SA 4.0 unless otherwise noted.