Hadriscus

Thanks @stokerg ! while we're on the subject, I would like to creep in a feature request that is related to the issue raised here : mirroring operations right now are done in world space (or document space, not sure how that would be called internally), which means that mirroring a rotated object will change its orientation as well. It would be really cool to have an option to mirror in object space as well (line of symmetry going along the object's own axes, instead of the document's). Alternatively, this could be made to work by letting the user snap to the inverted size of an object when scaling it negatively (which is exactly like mirroring, except currently the user can't constrain the object to the original ratio while doing that, and will inevitably stretch it in one direction or another). Hadrien

I may be wrong but I think this only applies to image layers, from which AP can deduce the ratio between original and scaled. For pixel layers, there is no such ratio, because there is no "original" to compare with.

Oh ok, I can see it now -thank you ! The inconsistency still exists, but at least it is documented. Hadrien By the way -I assumed this was an oversight, but maybe I'm missing something ? is there a rationale for keeping this disparity ?

Hi, the mirror operations found in move tool > right-click menu > transform > horizontal/vertical mirror do not respect "lock children" preferences as set in the tool settings (ie any underlying mask or child layer will be mirrored as well). Hadrien

Thanks ! where exactly do you get that ? The tooltip I'm seeing on hovering the button in question does not contain this information (maybe it's an oversight in the french translation?).

Hi, activating "transformation origin" in the tool settings bar (with move tool) works flawlessly with rotation, but for it to be taken into account when scaling or shearing an object, the user has to hold down ctrl, which I don't think is documented (unless I missed it, always possible). It is quite hidden, but the real problem is it's inconsistent with rotation, which doesn't require holding down ctrl (and I believe is the correct way to handle it : either you require the user to hold down a modifier key, or to check a button, but not both). Hadrien

Oh thank you I really appreciate it.

Not at all, I am asking for a setting to override the system default DPI, that proves to be unwieldy in practice ! if the default does not work well, it's either 1.change one program or 2.change every program but one I understand this so well, and this is frustrating because you could be doing something, but instead you choose to settle with "it's not my fault", which is and never will be a fitting answer for anyone. This reminds me of when Torvalds shut a developer down because they had made a similar decision : "the problem is on their end, let them fix it" (paraphrasing). But the kernel was shipping and there has to be something done about it, so they ifdef'd that particular fix on their side, because it had to work, right ? you may have heard of this story. The point being, when you interface with an OS/other programs and something is wrong that's obviously the other party's fault, fixing it on your end doesn't make it your fault -All that matters is that users are able work with your solution as swiftly as possible, and you are bound to be praised for acknowledging that, at least by me. This was particularly exerting to write out, English not being my language, so I'll leave it at that for the moment. I am glad you are staying to discuss this though, over your initial relunctant...ness (?). Anyway cheers ! Hadrien

Thanks for the tip ! however that sounds an awful lot like "user having to go in and configure some UI scale that is specific to each application". All because AP does not let me scale its interface. It looks like ideology may be a hindrance here ? should we really be forced into reconfiguring our entire systems just because an editor makes the choice of not providing a simple solution for their users, based on the belief that "all should be consistent" ? Let's not be Apple, please... anyway I made my point in the previous post -I hope you guys will be able to hear it. Thank you for your attention, Hadrien

I agree that would be ideal, but "ideal" is the enemy of "good" : many programs simply don't take Windows' GUI scale into account, and Windows scales them forcefully into a double pixel size. Some others do take it into account, but imperfectly : texts are truncated, UI elements overlap one another, etc (GTK2 based programs namely have a lot of problems). And finally, I would like to be allowed to scale a particular program's GUI differently than I do another, because the work that happens there is different, and so are the needs, can you see what I mean ? Blender does it, Houdini does it, Krita does it, the few "desktop" programs that I use do it at least to some extent (Foobar, Notepad++, etc) In essence it's really a binary choice : either you make you entire userbase wait for most existing programs to correctly implement Windows' GUI scale (potentially years), or you provide a handy way to circumvent that so that people can work in the meantime (bold for emphasis). I also am an idealist, but sometimes we have to be pragmatic : several users have expressed the need for such an "GUI scale override" over the years -they're not throwing a fit, they have valid reasons. Ultimately stuff has to work -and when it doesn't, the end user does *not* care whether it's some application's fault or some other's. Please give me the choice to scale that GUI, Mark... I am not about to go nag a hundred contributors in fifteen different FOSS and proprietary projects to ask them to respect Windows' GUI scale parameter, hoping that everything will be fixed within the next decade. This is called a workaround, and it's filthy, but sometimes we have to get our hands and our pencils dirty. Thank you for your attention, Hadrien

Hello, that's the thing : I don't scale my Windows interface because it makes other programs render incorrectly, so I am also stuck with a super small AP GUI. This thing should be handled at the program level, because users have different needs in different programs, it's really that simple. Hopefully since the interface scaling tech is there already, you can provide your users with a way to override the system setting. Thank you, Hadrien

Hi, going for the scrollbar is tiring after a while, I wish we could just MMB-grab-and-scroll lists such as layers, samples, brushes, and so on. This is standard in Blender, Krita, etc. and I'd love to have it in AP as well. I understand this is possible with a scroll wheel, unfortunately I use a tablet, and the "hot wheel" or whatever it's called is not readily accessible. Currently MMB has no function over the interface, so it could well be mapped to that. Thank you for your attention.

In the transform docker, there is a field called "déformation" in french, when it should be "cisaillement" (as demonstrated by the short label "s" which I reckon stands for "shear" = cisaillement).

Hi, a small error in the french translation : the french translation for layer groups in the layers docker (which are signaled with "(Group)" in parentheses) gives "(Grouper)" which means 'to group' (the verb). It should be "Groupe". I guess the error comes from the fact that in english, the verb 'to group' and the noun 'a group' share the exact same word. Hadrien

Thanks for the info, I'll do that.