Ok, I made https://docs.krita.org/Template:ConfigPath and https://docs.krita.org/Template:ResourcePath and updated the FAQ with it, the other thing I still ave no clue about how todeal with.

in Dockers > timeline docker >Frames Table: area on existent frame

this part of the manual,

"Ctrl+left mouse button+drag on any frame(or set of) to copy said frame(s) and drag it into a spot. "

it could state in the end (OSX: drag + ALT to copy)

Should we make a note somewhere in the docs that most keyboard shortcuts that involve ctrl can be replaced with command on OSX? Seems kind of tedious to have to go through every page and mention cmd instead of ctrl. But maybe it's less confusing in case there are shortcuts that really use ctrl.

Also for the record, the ctrl + H shortcut does not work on OSX because it's mapped to hide application by default, and users should map it to something else for now. On Photoshop, if you press cmd + H, users are prompted to choose whether or not they want to use cmd + H for hiding the app or hiding the selection. Not sure what we will decide for Krita.

Other notes:

• shift + click for completing polygonal selection does not work
• cmd + space is also another built in shortcut for calling up the Spotlight in OSX, and you can't use it in Krita to zoom the canvas. Probably PS does something similar to the cmd + H shortcut.
• shift + n, m and i only work once. No idea about m because it never worked. A bug, possibly?
• cmd + tab to switch tabs/sub windows doesn't work because it's the default shortcut for switching between apps. By default, OSX uses cmd + shift + left/right to toggle tabs and cmd + ´ on US keyboards, but cmd + </> on QWERTZ keyboards.
• the alt + drag behavior in frames has the same behavior in layers as well, so instead of using cmd + drag to duplicate a layer, you use alt + drag (and only press alt after dragging).
• insert key for adding layers doesn't work. But this may just be because I'm on a Macbook Air which has no insert key by default. It's supposedly just fn + return, but it just simulates the return key. Oddly enough, fn + F keys work as they should, and you can use F3 to open the layers properties and F5 and F6 to edit and select brushes. I tried it with another USB keyboard with a physical insert key, and it doesn't work (I get a ? showing up though).
• shift clicking the eye icon on a layer doesn't hide the other layers and behaves like regular click.
• double clicking the filter mask layer has the same effect as double clicking any layer - just allows you to rename the layer.
• when using the vector manipulation tool, shift locks translation to an axis, not ctrl or cmd. Same with manipulating vector points.
• Just a small notice: on macbooks with trackpads, you can invoke middle click + drag by doing a three finger scroll. Works for canvas panning.
• shift + click doesn't undo the last point when using the polygon tool.
• I find you have to move the cursor after holding down cmd but before clicking before the scale icon shows up for cage transform.
• zooming out with the zoom tool is cmd + click rather than ctrl + click (right click).
• alt + shift + +/- for blending modes doesn't work.

I don't know how manuals should be constructed so that as many people get as much information as possible.

But the idea of a universal note for OSX users sounds like a good idea. Something like this:

"Because there are not enough OSX testers for proofread the manual, OSX user might have to find the needed functions by testing different combinations. Ctrl might be cmd or alt, or you have to reverse the order of command compared to the manual, to get what you need. If you find something that differs from the manual, you can help the Manual by reporting it to...(KDE forum?)."

If I would happen to come by something like that, lets say, in couple of crucial places in the manual, I might remember this and I believe it could keep me more active when finding out the right key combinations. Then if the user is really active, they might register to the forum and report it.

During the meeting of october 18 it was decided that we should indeed just collect differences as we go and then annoy the programmers.

boud: Wolthera_laptop: well, let's just collect a list of all the differences. Somethings > will have to be solved in code, instead of in the manual, like switching tabs.
As soon as beelzy and others have compiled a reasonably complete list, we can start > patching