Krita/Flake
Yesterday night I had a stimulating session with Thomas on the way forward for Krita and flake integration. Let's try to summarize...
Application responsibility
Applications offer a user interface that is specialized for a type of document: think having pages or not and page structure are things defined by the application. The Flake library does not know the concept of pages.
We don't provide the complete user interface for the applications that are responsible for creating a flake shape, but just those parts that are most appropriate to be shared. That means, apps get basic selections, painting tools and layers tools for a krita shape, but not, for instance, the transform tools. Same with Karbon: an application that embeds a path shape can do basic manipulation on it, but for complicated work, Karbon needs to be opened.
That needs to happen in the same process of the original application, but in a different window, while sharing the tool manager. (Or could we use dbus to share the date among two processes?)
There are two ways to tackle this issue. If we want to keep the auto update we can either just use the same shape, or we can use the concepts of collaboration and send diffs between two processes. The second would be a better long term strategy, but is a long way out. (TZ)
We will need to determine along the way which tool belongs with flake (and thus is loaded for every koffice application) and which tool belongs to the specific application. We will also need to determine which bits of the menu associated with the native application for a flake shape to activate when that shape is selected. For instance, Krita's filters are a must-have for an embedded krita image, but the scripting not.
Shape creation
What I forgot to discuss with Thomas is that I would prefer the shape creation tool to be invisible... Just select shapes from the toolbar (for text, table, sheet, formula, image, rect, ecclipse, line and a few more) or from the shape selector (for shapes that look complex to the user, like star, predefined polygon shapes, kivio templates, clipart etc.) (We did discuss the difference between simple and complex shapes, though. Not sure if we reached a conclusion.)
The difference between simple and complex shapes was a bit strange as we had different definitions of what simple and what was complex. For clarity here is what is happening in the PathShape. We have a) Path shapes with all nodes visible and editable. b) special shapes like a star and a rounded-rect. c) Templated shapes. A collection of path-based shapes that can be inserted from a library like kivio's panel. (TZ)
What is complex and what is not complex depends on the app, too, a little: Kivio will need arrow connectors immediately available, while that's not important for Krita.
Krita's guided paint tools (rect, line, star etc) will appear only in Krita, not when a krita-based image shape is embedded in another application.
Three main sections in the toolbox, the second section is subdivided to classify the tools that belong to a shape:
+-------------------+ + manip | create? + +-------------------+ + + + sections for + + current shape + +-------------------+ + buttons for + particular + shapes + + callout or something + for complex shapes +
Look at how [Gobe Productive] solved our problem:
Toolbox, tool loading, tool selection
Krita will ship with two types of tools: tools loaded only with Krita and tools loaded by flake to enable working on the contents of a krita image shape. The difference is in the desktop file's service type. When a krita image shape is activated, the krita tools are shown (all tools if the application is krita, else a subset). We cannot currently subgroup tools that are activated for a shape: that is a TODO. (Proposed format for the tooltype: "shape/subgroup". Tools and shapes are linked through a common ID string.
Tool cursor
I need to emit a signal indicating which cursor I want whenever a tool needs to change its cursor. I'm still not sure how to do the brush outline in brave new Qt land.
Krita document structure
There are three possibilities of which two are compatible:
- Krita has a single dummy shape in its main shape manager. An image can have specialized shape layers, that contain their own shape manager and contain shapes. These shapes are rendered through the shape's QPainter based paint method on a QImage, the QImage is converted to the current colorspace and composited.
- Krita has a single shape manager. The shape manager contains a hierarchy of Krita layers (which then should be shapes, too) and flake shapes. Krita already has the concept of group layers, which would then become a special implementation of KoShapeContainer. Each flake shape that is not a native Krita layer is rendered to a QImage, which is converted to the current colorspace and composited in the stack. Note that Krita will NOT start to use the flake way of painting for native krita layers.
See this image for the proposed structure: File:Kritaflake.png
- Same as above, but for certain flake shapes (especially interesting for the path shape) we write an extension that makes it possible to render the data in the shape model using Krita paintops. (With a decorator class or something -- we need a cool technical solution for this, but it should be doable and interesting to do. (Thrain, are you interested in doing a decorator for path shapes that renders them using paintops?)
I want the last option implemented in Krita. This will give maximum flexibility and make life easier for users.
(Note: This model differs a lot, it seems, from Photoshop's model where vector shapes are not really in the layer hierarchy. I don't care about that: see my upcoming blog post on pleasing photoshop apologists. It would be cool though, if we could render a path shape more than once with different parameters in the layer stack. But that's something we also want to make possible with raster layers, for additional compatibility with OpenRaster and Pippin.)
Krita image as a flake shape embedded in other applications
A Krita image is a shape group with at least one layer shape child. (Krita layers also need to be shapes, but you cannot add a single krita layer as a shape outside a krita image shape. Do we already have a way to enforce such a constraint?)
Composition
Inside krita, we need to composite using our own projection rendering code since QPainter offers only 8 bit RGBA composition with only a few porter-duff operations. This is enough (for now) for the other applications like KWord it would be useful to, for instance, composite a text with an image using the screen composite op (which Qt doesn't support yet, only source, destination, over, in, out, atop, clear and xor)
Proposal for all of KOffice
Add a common foreground/background/pattern/gradient/opacity button to the bottom of KoToolBox and extend KoCanvasResourceProvider with convience methods to get at those settings for the tools.