General Session

Release cycle

when 2.4 ? User-end ready features ? -> first beta in September
snapshots Boudewijn, Inge and Cyrille will makes a plan
- Inge has talked to Riddell about kubuntu packaging
- Inge has talked to Rex Dieter for Fedora packaging
- Inge will talk to Will Stephenson for OpenSUSE
- Ana says she will package Calligra for Debian in experimental as soon as we have something that doesn't scare away users :)
  - http://git.debian.org/?p=pkg-kde/kde-std/calligra.git;a=summary
Keep a 6 monthes schedule ?
- 3.0 big feature release
  - 3.0.1...
  - 3.1.0 Intermediary
- Practical release concerns

           Suggestions for procedure (to always be ready for release?):
               Developer commit -> master-dev -> master-tested
               http://nvie.com/posts/a-successful-git-branching-model/

Action points

Add "e-mail people who break test"-feature to cruncher

Marketing message

calligra is divided in a UI interface for desktop, a mobile interface and an Office Engine
the office engine is pretty good, lean, fast, it does not takes many resources
this is invisible in the interface
the website area should show the differrent UI on the front page (desktop + mobile)
maybe not show the office engine on the front page
more blog post, more news story

Going more Qt-only way

some dependencies are painfull, big
we don't take advantage of our strength: small office engine
sometimes using KDE that replace Qt (or vise-versa) is not a good idea
is kdelibs dependency a problem ? kdelibs mobile profile seems acceptable.
we can influence packagers, or kde to fix problem, such as look and feel inside gnome
document (or point to documentation) on how external developers can plug other platform system (for instance, mimetype, we use KDE's mimetype systems, but that can be replaced within KDElibs to call the platform mimetype system instead of the sycoca one)
this discussion is KDE-wide
custom files dialog in Qt, expand this idea to other area
a lot of place where we can improve our code structure, but kdelibs dependency has become much more saner
Now that we are not named "ksomething" people don't care about the dependency anymore... it is all about the Name !

Extending calligra

Plugins:

add to the desktop file information for which information the plugin should be enabled by default (Cyrille will do that)
Arjen and Boudwijn will look at the selection dialog
shapes-loaded-on-demand: find a way to describe in a text file on how, or use a shape factory to load the plugins (what is the fastest ?)
use the desktop file to rule out many plugins, and for heavy plugin, they would be splited in a KoShapeFactory plugin and in a KoShape plugin (who wants to do it ? if noone does want, boudewijn will do it)

Scripting:

the most powerfull things in MSO is its scripting capability
be able to pull data from kexi and use it in tables
API to write documents
use dbus ?
you can create and manipulate spreadsheets using krosstables
what is missing ? Can I in a script creates a new document
what needs more integration an application
documentation
an IDE
AND UNIT TESTS !

embedded documents

two differences: shapes can embedd other shapes, and they need to show more UI to be edited
but do we need ?
- it is a bad idea coming from the 90s
- we have to support it, in some way because it is in ODF
- should we have an option to create an embedd a document ?
- allow editing by clicking and starting a new application (the koffice 1.x way is suboptimal)
in odf, no difference between text table and spreadsheet table, in OOo/LO/MSO, you can add formula inside a text table (scarcely used feature)
create a shape to display the document ? a kpart or koview ?
- out of process ? Xembedded ? or use the other application to generate a pdf and just add a pdf shape ?

Solutions:

create a shape that show the document in some way, and clicking on it open a new application to create the document
create a shape-per-application that would display the document (like for instance the spreadsheet shape)

Usecases:

insert spreadsheets
after a meeting, embedd all the presentations, and add some notes, and send it as a summary

Action:

try the kpart-shape way (Inge will do it!)
fix kpart

Embedded documents

two differences: shapes can embedd other shapes, and they need to show more UI to be edited
but do we need ?
- it is a bad idea coming from the 90s
- we have to support it, in some way because it is in ODF
- should we have an option to create an embedd a document ?
- allow editing by clicking and starting a new application (the koffice 1.x way is suboptimal)
in odf, no difference between text table and spreadsheet table, in OOo/LO/MSO, you can add formula inside a text table (scarcely used feature)
create a shape to display the document ? a kpart or koview ?
- out of process ? Xembedded ? or use the other application to generate a pdf and just add a pdf shape ?

Action:

create a shape that show the document in some way, and clicking on it open a new application to create the document

ODF Compatibility

shadow on a group should be applied to the whole the group
if a shape is a proper shape (meaning if you click on it, it should be the group that is selected not the children)
does ODF support it ? apprently you can set a style on a group
blur shadow ?
- only show it in calligra, and add it to the ODF
- make a work around
our own namespace, be carefull not to use it for everything and anything
cooperate with LibreOffice for the missing features ? or go talk directly with the ODF TC ?
What to do with advanced SVG feature ?
- save the full graphic as SVG

Da User Interface

User interface tests results

http://community.kde.org/Calligra/Usability_and_UX/Words/Personas

The User Interface

switching between shapes leave dockers behind
different type of dockers, view,
what is specific to a context should go in the tool options, what can be used in all context should be in docker

Defaults:

no defaults, if no shape is selected, the "style" docker should set the defaults, for instance when inserting shapes
it should per shape, for instance not for the text shape, or if you have clipart
right click on a shape should add it to the shape docker
right-click on shape and have the ability to "set style as default"

Add shape docker:

add shape: have the ability to select the favorite shapes, and the last one of the visible should be the last one inserted
renamed to insert shape

Dockers switching:

dockers should not switch all the time, you should be able to do all your work without switching a docker
workspaces should be used to select a workfow, for instance select if you want to write a letter, or be in a DTP mode
use the tool options more

Tools:

reduce the nmbers of tools that are general to all the applications
group tools that have a similar purpose (like photoshop), for instance "freehand" tool and "path creation" tool
move stroke properties/styles to the tool options (simillarly to the "snapping" options): default, path creation and edition
this move a lot of docker in the tool option
but maybe the snaping options should be moved out of the docker, since it is a setting
merge edit tool and creation tool
however you need to click outside to deselect
first click deselct, second click create a path
right-click menu to show the snapping
show the snapping options near the "zoom" area in the status bar

Tool option on the canvas

have the tool option on the canvas ?
an idea could be to have some icons on the canvas that give use some quick access, for instance in the path editing tool, you could select a node, and get some icons to change curves
right-click on a piece of a text to set the style

App UI and web page design topics

http://community.kde.org/Calligra/Usability_and_UX/Common/Startup/Startup_view_integrated_with_the_File_menu
talk the dbus-menu people to make sure that it would be possible
in stage, should "zoom out/zoom in" be in the submenu "zoom", only "fit", "fit page" and "100%" should be there
no adaptative menu (ie no show more at the bottom of the menu)

Different User Interfaces

Three methods to embbedd documents:

kparts, still use to embedded Words, for instnace, used by a company to create reports in their applications
KoView, used for Calligra Mobile
CanvasItem
all this options should be kept, as they are usefull
split more between desktop applications it more between desktop applications / applications logic

Abstraction and custom UIs topics

When creating a new feature, put it in a separate action slot, and then call that action from the UI.

Seperation of the engine and the UI

we should held a week meeting, with a specific group of people to come up with a design and a plan

Misc

Marketing

Some observations that could be good for the blog entry

This is apparently the biggest KOffice/Calligra meeting so far, 31 people registered
The KDAB office is awesome environment, we owe a lot to KDABians!

KoAbstraction

Chatting with Mani and Suresh about future of KoAbstraction (Jstaniek 16:34, 1 April 2011 (UTC))
- We would proceed with simplifying the API even more, so eventually 200 lines of code is enough to have working application
- We would deliver QWidget-based box capable to be used in Qt Designer
- We would start to hide unused elements like dockers, use dumpObjectTree() on FreOffice (or similar app) the main window to see how many unnecessary widgets live in the background
- How to make it easier to share custom applications, examples, demos without cluttering the calligra git repository? Maybe by creating or calligra-extras repository