@tymond and @rbreu, I've sent you both an invitation to edit the document using the email addresses attached to your git commits. I can also post an editable link if that's easier.

Thanks for the edits, Rebecca!

Ok. I've talked this over with Boud and we'll be shipping on Steam for Linux alongside the next release, probably in the middle of next week.
Feel free to hype it up, I'll be making a few reddit posts in coming days. =]

Ok! I've updated the English wall of text and I've added a link.
Please add your translation below, and let me know when you think it's ready to go.
Also feel free to put your own spin on things localize the writing until if feels natural to your language or culture.

Tiar also tested on Linux Mint 19.1 and it works fine.

Cool. We'll sort out the dependency and license stuff and push it.

Alright, I've made the requested changes:

1. The controls are really bigger than the original ones for some reason. New:
   
   Old:
   

In D16833#387940, @rempt wrote:

Maybe we should also have a global action or option to enable/disable picking the alpha value. People are getting confused again...

Hey again, and happy new year.

It looks like I didn't set Update to be checked by default in the .ui file, so that may be what caused the issue.

In D16833#358291, @dkazakov wrote:

Hi, @emmetoneill!

I have tested your patch very briefly. It looks fine :) Here are the notes:

1. [Regression?] Normal Ctrl+click in a paint too has stopped working for some reason. Do you have the same?
2. Shift+Ctrl+click seem to work fine and does what expected
3. Blending while dragging seem to work.
4. The Color Picker GUI looks good :)

Part of T8708

Add of adjust a KisSignalCompressor with configurable sensitivity.

If D8015 didn't take care of it already, this would also close this wishlist/bug: https://bugs.kde.org/show_bug.cgi?id=324005

Sounds good to me! Nice work so far.

From a UI standpoint, my main concern is that 90% of the people that use export want it the way it works now. They just want to simply output the file to a different format.

I think the balancing act is how do we appease people that want to see a lot of settings at one time, and how do we appease the people that want just a slice of the settings so they can maximize their canvas workable area.

Hi Scott. I like the direction of the new design and I think you did a great job saving space without making any major compromises.

I'm not totally sure about this

Hi Alvin,

(Removing myself as a reviewer since I helped a bit with this one.)

Reddit user Rous2 suggested the possibility of pressure sensitive color picker mixing (blend).

Ok, thanks for the help!

Installed Sphinx. It was super easy to get working (on Linux, at least), just install and build. Overall Sphinx has been great to work with! Much improved workflow, in my opinion.

Spelling and grammar fixes.

If you want to take a stab at it, the contributor's manual (readme) has instructions on how to contribute to sphinx. You can also write up the text here, in which case I'll port it.

Hey Wolfthera, I'd like to help with this if possible. Is this the only page that needs to be updated? I'd be happy to write about the new features as of 4.1 and edit what's already there.

Fixed and built the tests, and then pushed! Closing. Thanks again, Dmitry.

Pushed R37:7030f6a906da7b9ec0d660394dad7f691edf9bc2. Closing.

Resolved the regression caused by my previous patch 7c639729115b3a3bb20e1b0a1046c1bfbb6f41fe, which caused only one frame to be added by the "insert frames/columns left/right" actions regardless of number of selected frames. These actions now correctly insert new blank keyframes on the correct side of the cursor based on the number of currently selected frame slots.

Alright! I'm looking into it right now.

In D12977#267692, @dkazakov wrote:

I have tested your patch, it works and looks mostly fine. I have managed to find one small regression though:

1. Select three consecutive frames
2. Press "Insert keyframe right"
   
   Expected (old) behavior:
3. Three new frames are added at the right of the current selection
   
   Regression in the patch:
4. One new frame is added
   
   The same problem happens with "Insert frame left" and their columns counterparts. I guess this small regression is the last thing that blocks the patch from being pushed :)

Here's an update patch that fixes the menus. I popped a few more of the one-liners that call more general member functions into the header. I also fixed a tiny bug with the separators in the insert frame/hold columns menus and cleaned up some unused headers.

Pertaining to "what is/isn't a resource":

I assume in your example the run cycle is drawn somewhere outside the range of frames you describe here.

Our users should be able to:

• mark a cycle on the timeline
• change the range frames which are repeated
• edit the frames of a cycle. Changes should be reflected in the repeats.
• convert repeats into actual keyframes or clone frames
• draw on repeats without breaking the cycle due to automatic keyframing (option in autokey?)

Hey everyone, I just wanted to share a possible design mock-up for animation cycles that I put together.

Interesting idea.

Added code-reuse refactor for hold frames and hold columns.

Hey boud and wolthera. Would it be ok to add these feature revisions to the task? They're both in master now.

Color selector tool changes to the random colors. [ https://bugs.kde.org/show_bug.cgi?id=394396 ]

Great. Thanks again, Dmitry.

Stupid mistake there, sorry about that! Seems to be all fixed up now and working correctly. Thanks for catching that, Dmitry.