i wanted to answer dmitry first.

I have tested your patch. It looks fine, but I'm really not sure that users need "clone frames" in a state as we (developers) understand it. The thing that animators need is to create infinite cycles (not technically infinite, but "until the next custom frame"). And, optionally, they might also like "unwrapping" such cycles into a set of normal or clone frames. Can we first implement such "cycles" in the GUI and then start thinking about real "clones"?

The branch has been merged. However, there are some notes:

@rempt, it might be worth it to remove the fore and background color buttons, namely, while foreground color is translated to style="color:#ff00ff;", which should become style="fill:#ff00ff;" or something, backround color doesn't translate to stroke in the same way. So maybe remove background color and instead put in letter-spacing, which does need a slider.

The default composite ops are back, btw.

@woltherav : We need someone like @timotheegiet or @Deevad design a nice highlighter palette. This is a bit... bright...

Now I can see the current highlight colors thanks to the screenshot of @rempt . On dark theme, I like "Oblivion" colors from https://github.com/mig/gedit-themes/blob/master/oblivion.xml .
But I guess everyone has a prefered highlight color palette. Here is how look Oblivion with 3 color only on SVG:

In T1004#49754, @dkazakov wrote:

5. Support any kind of scripts (doesn't in automagically comes with unicode?) [[https://www.w3.org/TR/jlreq/ | w3c standard for Japanese text)

I've been reworking the current text dialog so it uses (our fork of kxmlgui) and presents a more conventional gui for text editing:

Added rightclick selection of background color based on the fact that is what we use elsewhere to select the background color.

@woltherav I would like to request an additional feature which will also aid in vector object colors too. I request a shortcut for selecting background color by shift clicking on the swatches.
Currently when changing the foreground color through palette or the toolbar it changes the color of vector objects fill color, changing the background color from toolbar changes the stroke color. Adding this shortcut (Shift click to select background color) to palette docker will make it more intuitive and inline with what inkscape does, will be helpful for user due to familiarity. I have also added a bug report for this here-> bug 381789

Okay, so I have been adding some stuff, but then had a dicussion with boud about the usability.

Did some testing today.

I have been chugging away at making a new palette docker while staying at boud and irina's. When I was initially doing this in python, we realised it might be better to extend KisPaletteView(this widget is used in the palette docker and the lazybrush tool options amongst others).

Memorandum: for vertical writing for Japanese, "Tategaki" plugin for Gimp could be useful.
http://reddog.s35.xrea.com/wiki/GIMP%E3%81%A7%E7%B8%A6%E6%9B%B8%E3%81%8D.html
Source code: http://reddog.s35.xrea.com/software/tategaki-1.2.1.tar.xz

NB: There's been previous attempts at getting Vertical Text layout into Qt: Abandoned patch from 2014 here It might be that it isn't playing nice with the stripped-down version of Harfbuzz that Qt uses(Harfbuzz-ng), but I cannot be 100% sure about that. Also of interest: Related Qt bug

More NB, as far as CSS and SVG are concerned...

Rotation around a hot position would be a two step process, where first you select the location of anchor. Alt + left click can be used to determine the position of anchor and then left click to rotate.

KisColorSetChooser.cpp definitely needs a redesign, as I've implemented group support, but there's no way for the user to select only a group within a palette. This is necessary for the layer-split dialogue for example.

This is a pretty large list of requirements for this improved color palette. Has the scope of this work been decided after all this brainstorming (this is just a stretchgoal right?). If I do a UI for this, should I include everything listed. Obviously if I do the overall design will be more complex.

I was wondering about that, because that's a regression; there must be a set of default favorite composite ops.

@dkazakov That is a good point. There is a big amount of blending modes and it can be overwhelming at times.

Btw, probably my comment is a bit irrelevant to this discussion, but there is one more problem we have with the default settings: by default the user has no favorite composite ops. And it is really difficult to find Normal composite op in our long folded list. I even had a report in VK telling that "Krita 3.1.1 has no Normal composite op". The problem can be solved by adding a few blending modes to favorites by default.