|
KViewShell is renamed Ligature. Okular gets support for Text and Line annotations. KSame and Konquest start their conversion to SVG graphics. Marble gets enhanced support for presenting and displaying geographical data interactively, and showing national flags. Mailody, the alternative email client, continues to develop at a rapid pace. Telepathy support in Kopete starts to emerge from experiment towards a usable implementation. Kile gets scripting support, with improvements to scripting across KOffice. KPresenter receives export to text document (OpenDocument) functionality. Improvements in the Magnatune music store facility in Amarok.
|
This weekend saw the hosting of a KOffice Interaction Meeting at Boudewijn Rempt's place in the Netherlands. Four local KDE developers were in attendance: Boudewijn Rempt, Thorsten Zachmann, Thomas Zander and Sander Koning, with Jan Hambrecht infiltrating from Berlin to make five. Boudewijn introduces the activities:
|
|
we're going to do some interaction design, decide on a common UI vision (hopefully) and do a lot of high-bandwidth code design. I want to get as much of this done, and not so much actual coding.
|
|
Sander Koning took copious technical notes on the meeting outcomes:
|
The main concept in Flake is shapes. A shape is connected to tools that know about the shape. For specialisations - e.g. a path tool that has different implementations (to edit nodes without having to know it's a star being edited) - there is a method that can be called to determine the parameters.
The Tool Manager in the GUI can create toolbox dockers, which contains all tools available for the specific shape and lets you select amongst them.
There is one Tool Manager per application, which means that there is one tool active in an application at any one time. Since some applications could benefit from a different approach, Thomas will look at this and see if it can modified.
Shapes create themselves according to their own specification. Thomas suggests a model/view separation to make it possible that two different shapes can point at the same data structure.
During the last meeting, templates were discussed. The shape factory can be extended to create any tool possible. Stencils in Kivio can be done with templates (name, value pairs). The factory needs to know about that, and the path shape factory needs to recognise the vector shape.
Loading and saving: using which file format should shapes load and save to? We use OpenDocument as native format, and so will use file filters for the rest.
For example, loading an old Kivio file: should we use the path/shape to load/save to old file formats? or should we convert using file filters? With the latter method, it is impossible to save without loss.
The Flake Plugin Loader should load both the shape and tool registries. Colourspaces are already loaded in this fashion.
The KoShapeSelector is a Flake canvas (which then can have children), containing sets of templates and where one can add custom templates that can create custom shapes.
Properties (in the templates) are just name-value pairs, reading/loading from XML - creating a new shape is done by filling in those pairs. It should be possible to create a new folder to function as a pastebin, so that the user can paste elements of documents into it, and then reuse them as new shapes. In the user interface, we want to have a unification of clipart, shape stencils and the clipboard.
It should be possible to have duplicating and linking of objects (e.g. KWord headers, which are 2 frames looking at the same document data offset, or Karbon linked objects, or Krita linked layers).
Which strategy to use for placing stuff on the canvas? We have drag-and-drop, dragging a stamp, multiple clicks, and freehand movement. In the latter case, the mouse path is important, so these cannot be created from the shape selector. Paths, freehand movement, and lines will be put in the toolbar, rectangles, stars and other shapes in the shape selector.
It has been decided to give the KoCanvasResourceProvider extra methods for colours, line styles, etc. instead of having to keep to generic methods.
About shape managers: one per page or one per document? A shape manager is per view. For at least KPresenter, we want a "selectable" flag so that e.g. master slide objects are unable to be selected from the normal page view. Shapes can link back to their parent "page" (as in Karbon), so that removing a shape and then undo'ing the removal will put the shape back at its original location. We can't put this in the userdata field, since this field is shape specific and some shapes already use it. We could have a page/group layer be a KoShapeContainer as well. Krita needs image data access, the text tool needs document information access.
Page numbering is perceived differently in different applications: KWord and KPresenter have separate pages while Karbon has 1 infinite page. If an application is requested to remove a shape from the document data, the shape itself does not get deleted. Creating a container KOShape is neater though, since it's a shape in itself as well.
Why are Karbon layers not in the shape manager? Because we wanted them to be selectable. This is solved by the selectable flag. A KOffice-wide library for layer manipulation (a common layer) box will be evaluated, and such a mechanism will go in the GUI, and not in Flake itself. ODF requires layers with global properties - we support shape containers.
How to attach animation to a shape? We cannot use userdata (see above). Since KPresenter is the only application needing this right now, it will use a decorator pattern and if needed, we will extend this later.
Copy-and-pasting is an implementation detail of drag-and-drop: create an invisible drop tool that figures out where to drop. Dropping onto an empty page should pass the dropped object to the application, pasting a URL into a textbox could perhaps resolve the URL and paste its referred contents. This would be done by the tool itself.
Text within shapes should be plastic within the containing shape boundary. Thomas expects this not to be too much work since wrap-around is likely to already work.
Bounding rectangles and shadows: should the bounding rectangle of an object include its shadow or not? We know that aligning should not take it into account. Repainting could be an issue, but we could fix KoShape to draw the shadow and be aware of it. Having the bounding rectangle to include the shadow and rotation, but then checking if the object is really at the specified location, looks to be a good solution.
Autoselection of tools - which tool, if any, should be selected by default when selecting a shape? This is something to experiment with. Users and usability people should definitely be consulted here as well.
Certain settings, for example default font sizes, the preferred colour chooser, the colour for outlines and grid behaviour, should be KOffice-wide. Hence a mechanism to share configuration files and settings is needed, next to a single panel where users can set those options.
Tools are categorised in four groups:- the pointer
- line, text and other tools
- basic application-specific tools
- and advanced application-specific tools
The last category could be hidden from view when editing within another application to prevent the toolbox from overflowing.
|
|
This week also saw an impressive continuation of work in the kdepim-3.5.5+ branch, with a large push towards closing the oldest bug I have ever encountered:It is over 7 years old! - Of course, although referenced as a bug, it should be noted that it is a wishlist item, and as such it is not directly having a negative impact or causing harm for users. But it is still greatly satisfying when such ancient gremlins are finally slain.
Many other important bugs have also been rapidly crushed over the past few weeks: work such as this is going on throughout KDE, and will ensure that the KDE 3.5 series continues to impress us with its vitality long into the dawn of the KDE 4 era.
|
|
![[*]](/images/standard/bugfixes)
![[*]](/images/standard/features)
![[*]](/images/standard/other)
![[*]](/images/standard/optimise)