Calligra/Meetings/Begin 2011 meeting/Minutes

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 a an office engine
• the office engine is pretty good, lean, fast, it does not takes many ressources
• 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

A 0 B 12 C 14 D 1 E 1 F 24 G 16 H 3 I 4 J 6 K 4

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 an action, 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