summaryrefslogtreecommitdiffstats
path: root/krita/doc/palettedesign.txt
blob: 549264a73994f50ff3cdaf50a38a0a0c678ff86c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Requirements

* Flexible: plugins should be able to add palettes or palette tabs
* Connected: palette tabs should be able to connect to the main application
  using signals and slots
* Configurable: palette widgets should be drag & droppable from palette
  to palette, and from palette to void to create a new palette.
* Persistent: the palette configuration of a view should be persisted
  on application end and reconfigured on application start.
* Pretty: the palettes should be small, but perfectly formed. There
  should be the possibility to use either tabbars or toolboxes for
  a palette.
* introspective: the application and plugins should be able to
  query for existing palettes and tabs and retrieve a list and
  pertinent data on existing palettes and tabs (so a plugin can
  decide to place itself initially in a palette with other color
  tabs, for instance.

Classes:

PaletteManager, Palette, PaletteContainer PaletteWidget

The palettemanager keeps track of palettes and saves & restores sessions.

Palettes can shade and unshade themselves with a double-click on the
titlebar or using the shade button

Palettes contain a container, either tab-type or toolbox type. 
The containers accept drops, in which case a widget is plugged into
the container. The tabs or separators accept drag events, in which
case a widget is unplugged and a drag operation is started.

The drag operation can end in the void, or above another palette.
If above a palette, see above. Into the void: create a new palette