GSoC/2018/StatusReports/MichaelZhou

A New Palette Docker for Krita

Status report for a Google Summer of Code project.

Task: D8646

The proposal is on the task page.

Brief Introduction

The new palette docker is designed and written to improve artists' experience of color management when using Krita.

The original palette docker enable users to create new palettes that are shared with all works and maintain those palettes as a list of colors, though they are shown as matrices of colors.

Compared to the original palette docker, the new one is better mainly in these 3 ways:

1. The colors are now not only shown, but also actually managed in matrices. Users can move them around freely in those matrices. They can leave empty slots or let the colors from some pattern if they want.
2. The palettes are associated with the `.kra` painting documents. Artists can create temporary palettes for a single file but don't need to worry about polluting the environment when editing other paintings. If they want to reuse palettes, they can also set the palettes to be 'global'.
3. The docker now comes with a more intuitive GUI. Artists can now better edit the palettes and easily export and import them.

Merged and not Merged

In the early phase of GSoC, I noticed that some base classes of the palettes can be reused in other places. Therefore, I did some refactoring to reuse them. The code reviews are here:

 D13750
 D13208

These 2 code reviews got merged, however, most of my work are in this code review, not yet merged.

That is because merging parts of the change will break some functions. This project involves several widgets that cooperate with each other. If only some of the widgets got merged, master will have widgets that done work with each other well. Therefore, we decided to merge after everything is done.

Details of usage

Each palette have the following attributes:

Column number

 Number of columns.

Name

 Name of the palette.

Filename

 Path to where the palette is stored. For non-global palettes it is just a file name. 

Is global

 A palette is global if it isn't stored inside a `.kra` file, and can be accessed by all documents.

Is read only

 Whether a palette is read only. Palettes that ship with Krita are usually read only.

Also, each palette can have more than one groups. Each group has the same column number as the palette itself, and they each have a column number.

Every palette always has a main group that has no name. This group cannot be renamed or removed. One can set the row number of it to 0, though.

By clicking the `Edit this palette` button on the palette docker, one can open a dialog. In the dialog, one can set the attributes of the palette and the groups

Each swatch in the palette docker also have more attributes than position and color. They each can have a name and string id. I actually don't know what the id is for... By double clicking a swatch, a dialog will pop up and let users edit it. One can also call the dialog by clicking the `modify this spot` button on the docker.

The docker also supports drag and drop. By dragging and dropping one can move a swatch to a new position or switch it with another swatch.

On the bottom left corner of the docker, there is a pop up button. After clicking it, the palette list widget will pop up.

At the bottom of the palette list widget, there are 4 buttons. From left to right, they are respectively `Add a new palette`, `Export current palette to file`, `Import a new palette from file`, and `Remove current palette`. By default, `Add` and `Import` create non-global palettes. `Remove` can remove all palettes, global or non-global, except for those read only ones.

Done and To Do

All the features that are in the proposal are done. This involves the palette docker itself, the base classes in the underlying libraries relating to it, and other classes using these base classes. There are probably still some bugs, so I will need to work on locating and solving them.

While working on the palette docker, I got some new ideas, and also found some problems in the code base that I want to solve. Those include:

1. Making it possible to select multiple swatches in the palette so that they can be drag/dropped or removed.
2. Making it possible to drag the group names rows in the palette docker to reorder them.
3. Use a list view (instead of a combo box) to show the groups in the dialog used to edit them, and making it easier to rename, delete and reorder groups. It should be like the layers docker.
4. Use KisDlgInternalColorSelector to replace KoColorSetWidget. This way, the dependency that holds palette classes in kritawidgets will be resolved and it can be moved up into kritaui, and have some better tools to use.
5. Improve KisDlgInternalColorSelector, making the triangular selector more smooth and the spin boxes show color values normally.

Details of what has been done

KoColorSet and KisPaletteModel have been heavily modified. Along with the new classes KisSwatch and KisSwatchGroup, they form the underlying data structure of palettes, which are grouped color matrices.

The API of KoColorSet and KisPaletteModel have been modified. What I want is to let all the data handling be done in KisPaletteModel. This is not done yet.

Surely, KisPaletteView and KisPaletteDelegate are modified to show the new matrices of colors.

The above group form the MVC system of palettes.

For making the modification of the palette tell krita that the document has changed, KisChangePaletteCommand inheriting from KUndo2Command is created.

For managing the list of palettes, KisPaletteListWidget is created to replace KisColorsetChooser.

For the search box in the palette docker and the internal color selector, KisPaletteComboBox is created. It syncs with a KisPaletteView assigned to it.

Due the change in API and usage of classes, other classes that use the palettes are also affected. Those classes include KoColorSetWidget, KisDlgInternalColorSelector, KoEditColorSetDialog, KisToolLazyBrushOptionsWidget, and LayerSplit.

KoEditColorSetDialog is removed because its functions can totally be replaced by the palette docker. KoColorSetWidget is planned to be replaced by KisDlgInternalColorSelector. LayerSplit and KisToolLazyBrushOptionsWidget are modified to adapt to the new API and tools.

In order to make it possible to store palettes in `.kra`, KisDocument is modified. It have a new member called paletteList, a list of pointers to palettes that belong to it. In KoColorSet, toByteArray and fromByteArray are implemented so that it can save itself into a buffer and then be transferred and stored into `.kra`.

Inside the docker, the setCanvas and unsetCanvas callbacks manipulates the resources server following the paletteList of the document being opened and closed.