Something I keep finding myself really wishing I had access to is a small canvas in a docker I could use as a place to plop down some colors and mix them to give myself a nice palette to color pick from like a traditional painter’s palette. There’s a thread in the forums from about 3-4 years back, but it seems it might of got lost in the shuffle along the way since then. So I thought it would be useful to bring it back up again here and see if there is anyone else who shares my interest in this feature.
My current solution is to use a template that includes an empty local palette that can be saved to just the current file. Then I do my mixing on the canvas on a separate layer, and then manually add colors I like to the palette docker. It works, but its really clunky and cumbersome and really doesn’t allow for the same randomness in choice that comes from picking along a patch of blended color.
For my own purpose, I just want a small canvas in a docker that gets saved along with the file so it stays available between sessions as the bare minimum of essential functionality. That’s all I need to be a happy camper in regards to this feature.
But some other potentially useful quality of life bonus additions to consider would include the option to save and load these as their own separate files, so you can bring in palettes you really liked from previous paintings. This would be really handy when working on a multi-image project, like backgrounds for a game to keep a common color theme throughout the related works.
Another potentially useful feature is setting up some basic paging to save on space and allow grouping together related colors that are likely to be needed at the same time. As far as UI goes, this can be something as simple as 2 arrow buttons pointing in opposite directions on the same stretch of header as the save/load options if they are implemented as well.
You can colour-pick from a reference image so that could take care of loading in your favourite custom palettes for a multi-image project. You wouldn’t be able to experiement with them live, unless you also opened them.
Having a live in-file palette with organisation facilities could be very useful.
In regards to that last point, you can already sort of have that with the palette docker. You can create a new palette that is local to the file. I use that quite a bit atm, and its nice cause you can adjust the number of rows/columns and the color swatches can be dragged around to change their order. To change out a color in a given slot though, you have to delete the current one and then click on it again to set it to your foreground brush color. It’s useful, but not as nice as hand mixing colors and picking from the created gradients.
Cannot this be achieved using subwindows? Have a window on full screen, and other file opened in small subwindow. When you right click in its bar, you can set “always on top”, so it’s always visible. At any time you can have color swatches, colorpick and mix colors with your brushes. Those palette files can be saved as separate .kra files.
Setting this up takes a while - you can’t open a document with the palette on one click, but I guess this would do. Or you mean some different kind of color mixing?
I have a better suggestion though it’s not too feasible given the complexity of Krita code. Artboards. A lot of professional grade software support artboards such as Adobe softwares, and Affinity softwares. It’s time that FOSS gets it too. Artboards are essentially multiple canvas with their own layers.
Interesting suggestion, but the main problem with using a separate regular file subwindow is that it can’t be docked into a side panel (or at least I couldn’t find a way to get them to dock). So it will always be competing for valuable canvas real estate with your actual painting. And unless you keep your main canvas small enough so both are visible at once, you will constantly be wasting time on switching back and forth between the two files. Neither the loss in canvas space or switching between files is really acceptable to me as a proper solution to this workflow problem.
Perhaps this points towards an alternative though, adding the option to dock a normal canvas view for a second file into the side panels. That would certainly get the job done without the current problems I’ve pointed out with using a second file for this task.
Artboards look like they could be useful for other things, but not so much for this, as they would have the exact same core problem as the last suggestion of using subwindows, and that is you have to waste canvas real estate to get the most use out of them as a traditional palette. Having it in a docker on a side panel means I don’t have to share canvas space with it, nor do I have to zoom back out to find it in order to use it.
It could still be a useful suggestion as it’s own feature request though. So do consider starting a new thread for it and giving us all a more thorough summary of your proposed use cases.
Ah, you’re right. Didn’t consider having to zoom back every once in a while. On artboard, I’m actually thinking it’s a better idea to have reference pictures being treated as a link to open file with to get around the artboard thing without wasting memory. I might make a thread on it.
@Uradamus - What different things would a scratchboard need to do? All I can think of right now is really clearing the contents. I will take a look at the forum thread too. I started something yesterday and this is what I have so far…
The screenshot is in a dialog now, but I am making it a python widget to use anywhere. I will change it to a docker once I get the functionality ironed out more. It is faster to code in a dialog at the start. The python doesn’t exist right now, so I am also creating the C++ bindings to make it available for people to use in scripting.
I tend to agree with fizzyflower, the one in MyPaint always seemed rather handy and met all my needs when I was still using that a fair bit more, so something along those lines would be pretty good.
The only thing that I don’t recall seeing brought up that might be of some use is an option to change the background color, though I wouldn’t go so far as to say that is essential in any way, just a nice little thing to have.
At the end of the day, just being able to have a docked canvas is the only essential bit. If we were able to save/load that area separately to be able to reuse palettes from previous works that would be a bit of icing on the cake.
Anyhow, really glad to see some activity on this front, thanks a lot for working on it!
Those are some good ideas from everyone. I will spend a bit more time seeing what I can add. There are quite a few ideas between this thread and all the forum ideas. Trying to add everything might be a bit too much for me to start things off. It will probably start off a bit more simple, and we can always iterate it over the future and slowly add more things.
If I may suggest - and if it’s easily doable - the background color should change before hitting the reflow/delete. If brings up artifacts around the swatches I think that’s less of a problem.
Imagine one is painting for sometime but considers changing the mood of the painting, one could use the scratch pad to check how would the color on canvas work against a cooler or warmer background.
That would be a “nice to have” feature though, not in the slightest very important if it means performance or breaking other essential functionalities.
@Rami - Changing the background color separate from the current strokes might have to be a v2 change. It is a bit complicated for me to try to do right now. Right now there is no difference between the canvas and the painting area. It is all just one layer. There would have to be an added extra layer of intelligence with how to interact and treat them different. The ‘canvas’ is also a bit more complicated than just being an image. It doesn’t really have a specific height and width and is considered a “paint device” in programming terms. This is why with the version I have now you can pan around and get an “infinite” scratchpad that you can use.
There are also probably some good solutions that I might not be thinking of or know how to program to do what you are asking. My thought with this is get a good base version out with the existing functionality. If people start using it, we can have more discussions on here with ways to improve and customize it.
@raghukamath - right now the scratchpad data is not saved to KRA files. With what I have, there is only the ability to load and save image files externally. This new scratchpad functionality is not a core Krita feature, but a python plugin. I think once we start adding more features to the scratchpad, we will have to have a discussion about how we might want to start saving this data to the KRA file…and if the python plugin I make should be included in the core version for Krita.
