I think this is a reasonable enhancement, but probably the main challenge is making this universally useful. I can see people wanting to customize the export settings in various ways, so the UI for this feature could get complex. So that sounds like a plugin could be a better fit here after all.
You have to draw a line somewhere, or with that logic, we can also ask colour wheels to be plug-in since we can draw in monochrome and people have drastically different approach to colours.
Yes, we can’t have a pre-made solution for every single possible use case, but the whole point of an app existing, is to have some pre-made solutions for someone. It’s never a problem of “Whether or not”, but “How much”.
that can run into some difficulties like how to name the files (avoid conflicts if the layer has the same name?)
That is indeed a problem…well, we can just use layer name as default solution, and put _n behind if the name conflicts.
If that doesn’t suit some people’s need, they can resort to plugins; If enough people have problem or someone proposed a better idea, make adjustment later.
I don’t think it’d be technically expensive to iterate out a solution of naming exported files, we don’t have to be THAT careful taking the first step.
whether it is a problem that relative canvas position of the layer is lost (if you crop it, how do you put it back in the right place?)
I don’t think it would…?
First of all, why would Krita do the “Crop the canvas, export, revert the crop” workaround? Can’t it just take the data in the layer and render it?
Let’s just say it can’t, it needs to crop the whole canvas for every export, what’s the engineering problem for that…?
I mean, the thumbnail of a layer only contains the part that has pixels, so I’d guess a layer was already “Image+position” in the first place; but if it’s not, temporarily storing some Vector2 data and retrieve it later…would that really be a problem for a developer or computer that can handle the whole Krita in the first place?
Or maybe they’re all problems somehow…then just don’t modify the project file during the export, make a shadow copy and free it after export finishes…?
I’m armature in programming, but I really don’t see the issue HERE.
I see issues like that which make it more complex than it seems at first. It may be non-issue for you, but it could be for someone else.
I agree I can always be overlooking complex issues, it’s the nature of feature request, one can only see as much through the lens of a user.
But I really can’t get your point, from both technical standpoint and a UX one.
Technically, aside from transparent-cropping and FX applying, my proposes are just rearranging existing functions.
If some of those are hard-coded in a way that doesn’t allow rearranging without huge refactoring…That’d be a way bigger problem that I can’t comment on.
From UX perspective, if the button turns out to be horrible, people can…just not use it?
It’s not really disruptive to an existing workflow, we can resort back to the manual way if it doesn’t pan out.
If someone really need the layer export to be in layer context somehow, leave it in and mark it as “Legacy, will be deprecated”, and we can at least get some conversation going.
I’m aware that this mindset runs the risk of bloating the menu…but let me point out that we already have an “Export Advanced” option that does nothing but adding a resize option. This, I’d ask whoever needs it to get a plug-in, because I really struggle to figure out a use case for it.
All those being said though, it doesn’t seem like anyone was exited by the idea so far, maybe I AM an edge case, and I won’t really complain if my issue doesn’t get prioritized.
That’s all I have to say. Thanks for reading this far.