Change Details

Kickstarter goal: "Managing palettes and color swatches. We want to add tagging, searching, creating, saving and editing of palettes. Palettes are also limited to 8 bit sRGB colors, so we'll also create a new swatchbook format that allows for higher channel depth colors." Bugs on bugzilla: https://bugs.kde.org/show_bug.cgi?id=335200 https://bugs.kde.org/show_bug.cgi?id=333760 https://bugs.kde.org/show_bug.cgi?id=330329 https://bugs.kde.org/show_bug.cgi?id=369343 Implies: * Exposing tagging of palettes to the UI. * Better save and edit dialogues.(New palette UI is kinda... confusing) * Develop format for high bit depths and scene reffered colours. (Mail Create mailing list?) --------------- Palettes (from discussion during halloween) ================================ There’s 3 areas affected here: 1. The native file format and internal data model. 2. Import/Export of non-native formats. 3. UI The native file format and internal datamodel. --------------------------------------------------- To some extent, the native file-format is an expression of the data-model, but in Krita we try to avoid data-dumps, so not quite that extreme. * We chose for a zip file, with a colors.xml, and the referenced icc-profiles. [done] ** Outside of LCMS ‘built-in’ profiles all profiles should be stored and retrieved from the zip. ** The XML stores the name, version, columns and comment and then has a child element ‘ColorSetEntry’ which is then used to store the data from the KoColorSetEntry. These are: *** ID - string number unique to this color. - This is very common in palettes out in the wild, especially ones with spot colors where the ID is a unique code like 'OY348' and the name is some flowery nonsense like 'naive peachy pink' *** Name - String with human readable name *** Spot - bool for marking a color as spot, probably useful later, if not useful for python plugins. *** bitDepth - a string that can be parsed to a KoID *** Color - An XML which can be interpreted by KoColor::fromXML(); * This model should be extended: [done] ** We want to be able to have groups. These colorgroups CANNOT be nested. The idea is that users want to group certain colors to find them more easily. Such things exist in other formats as well as ‘pages’ or ‘groups’. *** Within the datamodel, we will have one QVector<KoColorSetEntry> colors for non-grouped colors, ALWAYS. And a QMap with an group-identifier of sorts and the QVector<KoColorSetEntry> colors for that identifier. [done] **** Make sure we can have a palette where the colors are ONLY grouped, or a palette file where none of the colors are grouped. [done] *** Within the format this becomes a hierarchy. [done] **** Figure out a method to error with group children in a group. * We want to allow saving a KPL file to a kra by default. This should have a special spot in the UI. Import/Export of non-native formats. ------------------------------------------- * Ideally, KoColorSet is refactored to have the import export seperated into plugins. * We also want to allow python import/export plugins. * Exporting to a file would be done via a seperate command. Krita should not be saving out to a non-native or non-gpl file while not prompted. * We will not be handling localised names internally for now. We have no method to do anything with a list of names and language locales. * When dealing with multiple definitions, we will go for the most precise one first and then go off the list. Usability of the Palette Docker: ------------------------------------ * We need a better new palette dialog. The current one is implemented a bit lazily :p * Add/Remove colors. * Rename Colors * Drag and Drop reorganisation of Colors. ** There’s also a QDnD action we can use here, maybe? (Though this would only be for QColors) * Groups - As pointed out above we want groups for... ** Linking a group-color view to a layer. (Ex: Layer Character1 should show the group ‘character_one_colors’ when selected) *** We need an ‘all colors’ view to default to. - Users will otherwise get confused. ** Layer Split - Using the groups instead of individual colors. ** Generate palette from image, using each layer to fill a separate group. * Select ‘closest’ color to the current foreground color when this is changed to give an idea which is the closest color to current. * Palette docker should default to the KRA internal palette. This palette is auto-generated with a Black and White patch. Templates will be able to save palettes internally. * Swatch size, multiple options: ** Fill out according to column size(current) ** Size defaulted according to Resolution. ** Large Swatch Size + Column-based outlines has the issue of swatches disappearing from view. * Allow python plug-ins for manipulating the palette. * We need a dialog for editing the palette meta-data (Name, Comment, Columns) * Probably allow the same for a swatch. Other: ---------- * Append other palette to current - necessary for quickly having a existing palette added to the file-palette. * Search and autogenerate palette IDs vs. Palette Names. * Functions for appending and inserting color. * Internal image palette - **Option** to automatically fill it with color history. * Filter and Search options for the IDs and Names. -> These also need things in the KoColorSet. * ICC ColorLists will also need to be handled internally. Todo: ------ * @woltherav will be fiddling with KoColorSet and adding append/insert and similar functions. ** She will keep overseeing @lsegovia 's parsing efforts. * @rempt will write python bindings for KoColor and KoColorSet so these can be manipulated, generated and read. * @rempt will write an initial palette docker based on the notes above. - It might be best to have something working before we do UI design to remove the more abstract elements from the conversation. * @rempt noted that the KisColorSetChooser.cpp (that is the little dropdown to choose the colorpalette) needs a serious make-over. Ask @scottpetrovic if he wants to look at this.

Kickstarter goal: "Managing palettes and color swatches. We want to add tagging, searching, creating, saving and editing of palettes. Palettes are also limited to 8 bit sRGB colors, so we'll also create a new swatchbook format that allows for higher channel depth colors." Bugs on bugzilla: https://bugs.kde.org/show_bug.cgi?id=335200 https://bugs.kde.org/show_bug.cgi?id=333760 https://bugs.kde.org/show_bug.cgi?id=330329 https://bugs.kde.org/show_bug.cgi?id=369343 Implies: * Exposing tagging of palettes to the UI. * Better save and edit dialogues.(New palette UI is kinda... confusing) * Develop format for high bit depths and scene reffered colours. (Mail Create mailing list?) Problems: The palette docker is shared, so we have to be mindful about what kind of changes we make to it. This again means we have limitations in terms of rearranging. I will write down the stuff that I already thought through in the next comment..--------------- Palettes (from discussion during halloween) ================================ There’s 3 areas affected here: 1. The native file format and internal data model. 2. Import/Export of non-native formats. 3. UI The native file format and internal datamodel. --------------------------------------------------- To some extent, the native file-format is an expression of the data-model, but in Krita we try to avoid data-dumps, so not quite that extreme. * We chose for a zip file, with a colors.xml, and the referenced icc-profiles. [done] ** Outside of LCMS ‘built-in’ profiles all profiles should be stored and retrieved from the zip. ** The XML stores the name, version, columns and comment and then has a child element ‘ColorSetEntry’ which is then used to store the data from the KoColorSetEntry. These are: *** ID - string number unique to this color. - This is very common in palettes out in the wild, especially ones with spot colors where the ID is a unique code like 'OY348' and the name is some flowery nonsense like 'naive peachy pink' *** Name - String with human readable name *** Spot - bool for marking a color as spot, probably useful later, if not useful for python plugins. *** bitDepth - a string that can be parsed to a KoID *** Color - An XML which can be interpreted by KoColor::fromXML(); * This model should be extended: [done] ** We want to be able to have groups. These colorgroups CANNOT be nested. The idea is that users want to group certain colors to find them more easily. Such things exist in other formats as well as ‘pages’ or ‘groups’. *** Within the datamodel, we will have one QVector<KoColorSetEntry> colors for non-grouped colors, ALWAYS. And a QMap with an group-identifier of sorts and the QVector<KoColorSetEntry> colors for that identifier. [done] **** Make sure we can have a palette where the colors are ONLY grouped, or a palette file where none of the colors are grouped. [done] *** Within the format this becomes a hierarchy. [done] **** Figure out a method to error with group children in a group. * We want to allow saving a KPL file to a kra by default. This should have a special spot in the UI. Import/Export of non-native formats. ------------------------------------------- * Ideally, KoColorSet is refactored to have the import export seperated into plugins. * We also want to allow python import/export plugins. * Exporting to a file would be done via a seperate command. Krita should not be saving out to a non-native or non-gpl file while not prompted. * We will not be handling localised names internally for now. We have no method to do anything with a list of names and language locales. * When dealing with multiple definitions, we will go for the most precise one first and then go off the list. Usability of the Palette Docker: ------------------------------------ * We need a better new palette dialog. The current one is implemented a bit lazily :p * Add/Remove colors. * Rename Colors * Drag and Drop reorganisation of Colors. ** There’s also a QDnD action we can use here, maybe? (Though this would only be for QColors) * Groups - As pointed out above we want groups for... ** Linking a group-color view to a layer. (Ex: Layer Character1 should show the group ‘character_one_colors’ when selected) *** We need an ‘all colors’ view to default to. - Users will otherwise get confused. ** Layer Split - Using the groups instead of individual colors. ** Generate palette from image, using each layer to fill a separate group. * Select ‘closest’ color to the current foreground color when this is changed to give an idea which is the closest color to current. * Palette docker should default to the KRA internal palette. This palette is auto-generated with a Black and White patch. Templates will be able to save palettes internally. * Swatch size, multiple options: ** Fill out according to column size(current) ** Size defaulted according to Resolution. ** Large Swatch Size + Column-based outlines has the issue of swatches disappearing from view. * Allow python plug-ins for manipulating the palette. * We need a dialog for editing the palette meta-data (Name, Comment, Columns) * Probably allow the same for a swatch. Other: ---------- * Append other palette to current - necessary for quickly having a existing palette added to the file-palette. * Search and autogenerate palette IDs vs. Palette Names. * Functions for appending and inserting color. * Internal image palette - **Option** to automatically fill it with color history. * Filter and Search options for the IDs and Names. -> These also need things in the KoColorSet. * ICC ColorLists will also need to be handled internally. Todo: ------ * @woltherav will be fiddling with KoColorSet and adding append/insert and similar functions. ** She will keep overseeing @lsegovia 's parsing efforts. * @rempt will write python bindings for KoColor and KoColorSet so these can be manipulated, generated and read. * @rempt will write an initial palette docker based on the notes above. - It might be best to have something working before we do UI design to remove the more abstract elements from the conversation. * @rempt noted that the KisColorSetChooser.cpp (that is the little dropdown to choose the colorpalette) needs a serious make-over. Ask @scottpetrovic if he wants to look at this.