This page is to collect idea on how you think the toolbox for each application should look depending on different situation.

General

Current goal/concept

The current (April 2009) design has a goal and a concept behind it. Ever comment written here is based on this so its good to write that down here too. Any problems we have likely means we have to revise this concept.

The ToolBox is separated into 'sections'. The sections are totally dynamic and defined by the tool-plugins. A new tool can 'start' a new section and so escape being together with other sections. There is one special section which is the section that is on top. This one holds several 'create' tools that are able to create a new shape instead of operate on an existing shape. At [Libs/Flake/2006_Meeting_Minutes] The line tool itself was voted to be a Tool. One effect of the behavior of the tools in this section is that its permanent. They are always on screen whereas all the other tools disappear when their shape is not selected. Note that Krita changed this for itself; it adds all of the krita tools to also be permanent. Next to the permanent section there is a dynamic section that is for all the single tools. Select a text shape and all the text tools will be added to the dynamic section. We invite tool writers to use this section only. For shapes that have a lot of tools we offer the option to use its own section so all the tools for this type are grouped together.

Boud

There should be two toolboxes, or at least, two clearly separated areas in the toolbox. One with common tools, the other with app-specific tools. It should be possible to select a toolbar-style toolbox, a horizontal two-row toolbox, or a vertical two-column toolbox, but this setting should be per-user, not per-app, to improve consistency and user recognition.

There should be an area in the toolbox, at the bottom, where the user can add certain small, non-tool controls, as in Karbon 1.x. Maybe we should integrate a shape selector as another component of the toolbox.

The toolbox must always be visible.

KWord

Experience

Having a toolbox in KWord has been seen by various people as odd. The impression ranged from "this is a paint app" to "how do I get rid of this thing?" and our usability student noted that she wanted the toolbox on the same side as the tool-options docker to minimise mouse distance travelled.

Usecases

Anna uses KWord for writing her blog. She uses one of the default templates and never uses anything but the text tool and menus.

Beatrice uses KWord for different things, apart from writing her blogs, like Anna, she also likes to add images to it in a playful manner. So she uses the text tool she inserts images and she uses the default tool to rotate and move these images around.

Cathy is more a DTP users than a word processor user. She edits both text and other (vector) content in KWord and switches tools more often. When the Krita shape + tools become available it is likely she will use those too.

Krita

Cyrille

While painting:

While editing a vector layer:

Sven

This design tries to keep the toolbar similar in both situations. Shape tools will create flake shapes where possible. The default tool is needed in both cases (manipulates vector selections in paint layers)

A small problem are the gradient and patter/fill tools that are available in both and work slightly different.

Karbon

I would like to have support for having a toolbox with only one column of toolbuttons to save horizontal space.

Sven

Like editing shape layers in Krita, but in one column.

Kexi

Kexi needs to display toolbox at least in Form Designer and Report Designer. In both cases tools and objects are merged within one toolbar, e.g. Widget box, like in Krita. In other contexts than design mode for forms/reports, the toolbox is not available.