Calligra/Meetings/Begin 2011 meeting/Ideas

From KDE Community Wiki

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

Release Cycle

(Cyrille)

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.

Marketing Message and Strategy

(ingwa)

I would like to give a short introduction to what our current marketing message is and how I have reasoned when I came up with it. This would not take a long time, and would be preparation for the Marketing BoF.

Going more Qt-only way

(jstaniek)

i.e. going the smart way, take advantage of our core strengths

  • Intended audience: all devs
  • I propose to go with Qt-only libs a bit more, to make our offerings more independent each-other and drive potential contributions of new kind (Qt-only devs, non-KDE devs...).
  • Filters are good candidates for this group, and especially the lower-level libraries like mso Smart Art, Diagrams.
  • KoReports are nearly Qt-only already (as a fork of OpenRPT it has never used kdelibs in fact). The same for KoProperty lib.
  • I am investing into Qt-only Predicate a lot too ([1]), as you know it'll be dependency of Kexi, hopefully 2.4.
  • Moreover I also believe that every app has some nontrivial bit of code that can be provided on the outside with a simple API, say, using the Facade pattern. For such APIs, KDE dependencies are not needed.
  • Is this for encouraging people not to use KDE(libs)? Definitely not. At a conceptual level the idea may evolve into slightly different model of composing our building blocks: develop core functionality as Qt-only (but with cmake) and then extend for KDE, to get the integration level and look&feel we all want. A bit like it is in WebKit/QtWebKit tandem.

Extending calligra

Plugins

(Cyrille)

There are several issues or lacking aspect in Calligra's plugins.

  • 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
  • a possibility is to have the plugin's desktop indicate for which applications it should be enabled by default, and for which applications it should not be possible to enable it

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 QObject, that gives access to the application API/objects? (see facade pattern)
  • All ideas open for discussion!

Documents

Embedded Documents

(ingwa)

There is no good way to embed a document into another document right now. This needs to be fixed. Perhaps the idea of using shapes for embedded documents is not the best idea? Maybe it's time to resurrect the KParts that we used in KOffice 1.x? In any case, we need a way to handle this.

(Perhaps this item belongs in the BoF section below.)

ODF compatibility

(yue)

  • What should be the strategy when there is a nice idea but the implementation have to break odf spec (For example the blur-shadow patch I made: to save blur information in drop-shadow you have to add undefined tags which other apps like libreOffice cannot recognize.)

(jaham)

  • Another related problem is the diverging feature set supported by ODF and SVG. How do we want to handle saving these features without losing data?
    • SVG filters
    • SVG shape clipping
    • ODF connectors
    • etc.

User Interfaces Session

The User Interface

(ingwa)

I have now tried to use Calligra for production work a number of times. The sad fact is that our user interface simply doesn't work.

The tools themselves work pretty well even if there are some that could use improvements. But the overall workflow where you have to switch between dockers is just not good:

  • Finding the right docker for certain tasks is hard and slow. This will become worse when the number of dockers increase.
  • There are no clear guidelines on how our tools, the toolbox, inspectors, dialogs, etc should be implemented -- and which way to implement them in different cases.

We need a discussion on the overall design of our user interface components, and which types of components to use where. The focus should be on making using Calligra efficient. Right now things are both slow and hard to find, and it's time to fix this.

Abstraction and custom UIs topics

(jstaniek)

  • Intended audience: library devs and Words, Tables, Stage devs
  • I'll quickly present what's done, mention the presentation conducted by Mani.
  • I'll present possible extensions (recognized as low-hanging fruits) for the koabstraction
  • Next steps for the abstraction can be discussed, ans also hopefully with 3rd-party users of the Calligra frameworks
  • Think about examples, demo(s) providing reference code for 3rd-parties (e.g. add calligra-extras repository)

App UI and web page design topics

this includes not just look & feel but: un-clutter, end-user-orientation, power-user-orientation-as-an-option

Q: Why thinking both about quality of web page communication and the app? Isn't good app enough?

A: Both build the image.

Notes:

  • Decide if it's better to have common knowledge within the Calligra Team about the product design (apps UX and web page UX), and agree on some most fundamental values
    • e.g. see [2]:
      • For web pages and announcements and UI messages: "Don't talk to users in geek language"
      • For web pages and UI messages: "Don't write long texts"
      • For most of the UI: "Forget documentation, users do not read it" (does not apply to power-user features like scripting of course)
      • For UI: "Don't overwhelm users with a multitude of elements" (our dockers is the best example)
      • For UI: "Focus a screen on one task" (again, our dockers is the best example)
      • For UI: "Have a clear and intuitive interface model" (pick the most appropriate as a good start: [3])
      • For UI: "Minimize clicks per action" (a plan at least for Kexi is to minimize number of dialogs, especially modal, or remove all)

Calligra has still something to do regarding messages for end users. Proposal to improve quality of communication:

  • always define the target audience of an announcement, changelog or other news
    • if both specialists and users are the audience, split the content to two separate parts
    • if it's hard to split with simple copy/paste, consider rewriting/recomposing and next time write the text with the above note in mind
  • to identify parts not for end users, ask your wife/girfriend/grandma to read some of the text

Demonstrate initial implementation on the Startup view

Separation of UIs and Engine

(ingwa)

Currently the desktop UI is the defacto UI, since it is mixed with every application engine. All the other UIs are add-ons that have to carry much of the weight of the desktop UI with them. This is esp. true for all the shapes that have tools with tool option widgets, which makes it impossible to link without QWidget even if the rest of the UI only uses QGraphics*.

I think it's time to separate the engine for the applications from the desktop UI and to make all different UIs equal. I will present a proposal for how to do that and would like to have a discussion on pros and cons of this and other approaches.

BoFs

Text Layout and Words

(Casper)

I'll give an introduction to the new text layout library. How everything has changed and what the philosophy is.

I will not have time to prepare material for this introduction, but I hope some kind souls will take notes which we can publish afterwards.

We will also look into how to proceed with the Words redesign that needs to follow from this, and to tackle the other current text frame problems in Words.

Finally we will look into what is needed to have truly first class review tool and references tool.

Marketing Strategy

(ingwa)

If there is enough interest, I think it would be a good idea to discuss our marketing strategy and which material we would need to drive it. Especially the website would be a biggish topic here. Other subtopics would be Branding and Visual identity. For inspiration, see [4].

QML and QGraphicsView: our two canvases

(boud>

Last sprint, we decided to make Calligra less QWidget-based. August 2010 we took an important step by supporting QGraphicsWidget-based canvas objects. This bof will discuss how to use one of those canvases in QML, hopefully resulting in a demo application we can include in Calligra (which is sorely missing). And we might want to discuss the next step in api design here, and perhaps even more flexibility.

Other things

  • plans for plugins could be discussed in more details by a smaller group of people (Cyrille)
Retrieved from "https://community.kde.org/index.php?title=Calligra/Meetings/Begin_2011_meeting/Ideas&oldid=11421"