Jump to content

GSoC/2018/StatusReports/MichaelZhou: Difference between revisions

From KDE Community Wiki
← Older editNewer edit →
Simeir (talk | contribs)
18 edits
No edit summary
Simeir (talk | contribs)
18 edits
No edit summary
Line 1: Line 1:


== A New Palette Docker for Krita ==
== A New Palette Docker for Krita ==
Line 22: Line 23:
Compared to the original palette docker, the new one is better mainly in these 3 ways:
Compared to the original palette docker, the new one is better mainly in these 3 ways:
# 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.
# 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.
# The palettes are associated with the <code>.kra</code> 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'.
# 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'.
# The docker now comes with a more intuitive GUI. Artists can now better edit the palettes and easily export and import them.
# The docker now comes with a more intuitive GUI. Artists can now better edit the palettes and easily export and import them.


Line 58: Line 59:
|-
|-
! Is global
! Is global
| A palette is global if it isn't stored inside a <code>.kra</code> file, and can be accessed by all documents.
| A palette is global if it isn't stored inside a '.kra' file, and can be accessed by all documents.
|-
|-
! Is read only  
! Is read only  
Line 71: Line 72:
[[File:PaletteDockerAndList.jpg]]
[[File:PaletteDockerAndList.jpg]]


By clicking the <code>Edit this palette</code> button on the palette docker, one can open a dialog. In the dialog, one can set the attributes of the palette and the groups.
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.


[[File:PaletteEditorDialog.png]]
[[File:PaletteEditorDialog.png]]


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 <code>modify this spot</code> button on the docker.
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.
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.
Line 81: Line 82:
On the bottom left corner of the docker, there is a pop up button. After clicking it, the palette list widget will pop up.
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 <code>Add a new palette</code>, <code>Export current palette to file</code>, <code>Import a new palette from file</code>, and <code>Remove current palette</code>. By default, <code>Add</code> and <code>Import</code> create non-global palettes. <code>Remove</code> can remove all palettes, global or non-global, except for those read only ones.
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 ==
== Done and To Do ==
Line 91: Line 92:
# Making it possible to drag the group names rows in the palette docker to reorder them.
# Making it possible to drag the group names rows in the palette docker to reorder them.
# 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.
# 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.
# Use <code>KisDlgInternalColorSelector</code> to replace <code>KoColorSetWidget</code>. 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.
# 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.
# Improve <code>KisDlgInternalColorSelector</code>, making the triangular selector more smooth and the spin boxes show color values normally.
# Improve 'KisDlgInternalColorSelector', making the triangular selector more smooth and the spin boxes show color values normally.


== Details of what has been done ==
== Details of what has been done ==


<code>KoColorSet</code> and <code>KisPaletteModel</code> have been heavily modified. Along with the new classes <code>KisSwatch</code> and <code>KisSwatchGroup</code>, they form the underlying data structure of palettes, which are grouped color matrices.
'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 <code>KoColorSet</code> and <code>KisPaletteModel</code> have been modified. What I want is to let all the data handling be done in <code>KisPaletteModel</code>. This is not done yet.
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, <code>KisPaletteView</code> and <code>KisPaletteDelegate</code> are modified to show the new matrices of colors.
Surely, 'KisPaletteView' and 'KisPaletteDelegate' are modified to show the new matrices of colors.


The above group form the MVC system of palettes.
The above group form the MVC system of palettes.


For making the modification of the palette tell krita that the document has changed, <code>KisChangePaletteCommand</code> inheriting from KUndo2Command is created.
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, <code>KisPaletteListWidget</code> is created to replace <code>KisColorsetChooser</code>.
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, <code>KisPaletteComboBox</code> is created. It syncs with a <code>KisPaletteView</code> assigned to it.
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 <code>KoColorSetWidget</code>, <code>KisDlgInternalColorSelector</code>, <code>KoEditColorSetDialog</code>, <code>KisToolLazyBrushOptionsWidget</code>, and <code>LayerSplit</code>.
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'.


<code>KoEditColorSetDialog</code> is removed because its functions can totally be replaced by the palette docker. <code>KoColorSetWidget</code> is planned to be replaced by <code>KisDlgInternalColorSelector</code>. <code>LayerSplit</code> and <code>KisToolLazyBrushOptionsWidget</code> are modified to adapt to the new API and tools.
'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 <code>.kra</code>, <code>KisDocument</code> is modified. It have a new member called paletteList, a list of pointers to palettes that belong to it. In <code>KoColorSet</code>, toByteArray and fromByteArray are implemented so that it can save itself into a buffer and then be transferred and stored into <code>.kra</code>.
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.
Inside the docker, the setCanvas and unsetCanvas callbacks manipulates the resources server following the paletteList of the document being opened and closed.


.kpl
== '.kpl' ==


An example for the new <code>colorset.xml</code> in the <code>.kpl:</code>
An example for the new 'colorset.xml' in the '.kpl:'
{{Input|<syntaxhighlight lang="xml" line>
{{Input|<syntaxhighlight lang="xml" line>
<ColorSet columns="16" comment="" readonly="false" rows="3" version="1.0" name="PALETTE">
<ColorSet columns="16" comment="" readonly="false" rows="3" version="1.0" name="PALETTE">
Line 164: Line 165:
</syntaxhighlight>}}
</syntaxhighlight>}}


Following are the differences from the original <code>.kpl</code>:
Following are the differences from the original '.kpl':


The new rows and readonly attribute in the <code>ColorSet</code> tag. rows here means the row number of the main group. This attribute also exists and have the same meaning in the <code>Group</code> tags.
The new rows and readonly attribute in the 'ColorSet' tag. rows here means the row number of the main group. This attribute also exists and have the same meaning in the 'Group' tags.


A Position tag now exists for each <code>ColorSetEntry</code>. It decides the position of the swatch defined by the <code>ColorSetEntry</code> tag.
A Position tag now exists for each 'ColorSetEntry'. It decides the position of the swatch defined by the 'ColorSetEntry' tag.


== Other Related links ==
== Other Related links ==

Revision as of 03:14, 14 August 2018


A New Palette Docker for Krita

Status report for a Google Summer of Code project.

Task: https://phabricator.kde.org/T8646

Code reviews: 

 https://phabricator.kde.org/D14815
 https://phabricator.kde.org/D13750
 https://phabricator.kde.org/D13208

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 enables users to create new palettes that are shared with all works and to 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:

https://phabricator.kde.org/D13750

https://phabricator.kde.org/D13208

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

https://phabricator.kde.org/D14815

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 don't work with each other well. Therefore, we decided to merge after everything is done.

Details of usage

Each palette have the following attributes:

Attribute Meaning
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 row 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.

'.kpl'

An example for the new 'colorset.xml' in the '.kpl:' 

<ColorSet columns="16" comment="" readonly="false" rows="3" version="1.0" name="PALETTE">
 <ColorSetEntry bitdepth="U8" id="" spot="false" name="hair bright light">
  <RGB g="0.666666686534882" space="sRGB-elle-V2-srgbtrc.icc" r="0.898039221763611" b="0.549019634723663"/>
  <Position column="0" row="0"/>
 </ColorSetEntry>
 <ColorSetEntry bitdepth="U8" id="" spot="false" name="hair 1">
  <RGB g="0.313725501298904" space="sRGB-elle-V2-srgbtrc.icc" r="0.501960813999176" b="0.239215686917305"/>
  <Position column="1" row="0"/>
 </ColorSetEntry>
 <ColorSetEntry bitdepth="U8" id="" spot="false" name="hair mid">
  <RGB g="0.321568638086319" space="sRGB-elle-V2-srgbtrc.icc" r="0.533333361148834" b="0.250980406999588"/>
  <Position column="2" row="0"/>
 </ColorSetEntry>
 <ColorSetEntry bitdepth="U8" id="" spot="false" name="hair dark">
  <RGB g="0.129411771893501" space="sRGB-elle-V2-srgbtrc.icc" r="0.30588236451149" b="0.109803922474384"/>
  <Position column="3" row="0"/>
 </ColorSetEntry>
 <ColorSetEntry bitdepth="U8" id="" spot="false" name="hair 3">
  <RGB g="0.211764708161354" space="sRGB-elle-V2-srgbtrc.icc" r="0.380392163991928" b="0.18823529779911"/>
  <Position column="4" row="0"/>
 </ColorSetEntry>
 <Group rows="3" name="skin">
  <ColorSetEntry bitdepth="U8" id="" spot="false" name="skin 0">
   <RGB g="0.992156863212585" space="sRGB-elle-V2-srgbtrc.icc" r="1" b="0.925490200519562"/>
   <Position column="0" row="0"/>
  </ColorSetEntry>
  <ColorSetEntry bitdepth="U8" id="" spot="false" name="skin 1">
   <RGB g="0.949019610881805" space="sRGB-elle-V2-srgbtrc.icc" r="1" b="0.874509811401367"/>
   <Position column="1" row="0"/>
  </ColorSetEntry>
  <ColorSetEntry bitdepth="U8" id="" spot="false" name="skin 2">
   <RGB g="0.82745099067688" space="sRGB-elle-V2-srgbtrc.icc" r="0.941176474094391" b="0.796078443527222"/>
   <Position column="2" row="0"/>
  </ColorSetEntry>
  <ColorSetEntry bitdepth="U8" id="" spot="false" name="skin 4">
   <RGB g="0.65490198135376" space="sRGB-elle-V2-srgbtrc.icc" r="0.819607853889465" b="0.619607865810394"/>
   <Position column="3" row="0"/>
  </ColorSetEntry>
 </Group>
</ColorSet>

Following are the differences from the original '.kpl':

The new rows and readonly attribute in the 'ColorSet' tag. rows here means the row number of the main group. This attribute also exists and have the same meaning in the 'Group' tags.

A Position tag now exists for each 'ColorSetEntry'. It decides the position of the swatch defined by the 'ColorSetEntry' tag.

Other Related links

Blog posts: 

 https://simeir.github.io/kde/2018/05/13/First-Post.html
 https://simeir.github.io/kde/2018/06/22/Second-Post.html
 https://simeir.github.io/kde/2018/06/29/Third-Post.html
 https://simeir.github.io/kde/2018/07/13/Fifth-Post.html
Retrieved from "https://community.kde.org/index.php?title=GSoC/2018/StatusReports/MichaelZhou&oldid=81199"