[Gsoc 2011] Unified transformation tool
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
[Gsoc 2011] Unified transformation tool | Mohit _ | 26 Mar 09:50 |
[Gsoc 2011] Unified transformation tool | David Gowers (kampu) | 26 Mar 22:44 |
[Gsoc 2011] Unified transformation tool | Mohit _ | 27 Mar 05:12 |
[Gsoc 2011] Unified transformation tool | David Gowers (kampu) | 27 Mar 07:30 |
[Gsoc 2011] Unified transformation tool | Mohit _ | 28 Mar 19:21 |
[Gsoc 2011] Unified transformation tool
Hi,
I am interested in implementing Unified transform tool in GIMP. I went
through the specifications (
http://gui.gimp.org/index.php/Transformation_tool_specification) for the
same. First of all honestly speaking, I found the idea really cool and even
though I am not selected to do this project I would definitely love to see
this tool been added to gimp, as it would definitely help me a lot as a
user. Now, for the doubts regarding it.
- In the undo section it is mentioned that until the final pixel recalculation is done user should be able to undo every single step, though after that user should be able to undo the aggregate transformation only. Does this means that we would have to maintain another action stack just for unified transformation tool, or does gimp currently also maintains two different stacks, one for the current tool and one global stack for actions. If this is the case some reference to where it happens in code would be great.
- In the shaping up section, it is mentioned that the shape of transformation frame will change with every transformation and the width/height of the frame will be minimum width/height between the two sides/4. On the higher end it is clamped to 50 pixels, I believe that sometimes while doing perspective transformation this minimum distance can get pretty small which could make things a bit messy. Shouldn't we also have a limit on the minimum width of frame too, since we would have to put the marker for shear, and rotate also in those frames.
- In the corners of the frame the perspective markers and the scale markers are a bit confusing, obv this tool is for people who know what they are doing, but still. I have a few ideas in my mind regarding this, I would try and make some images for the same and put them up in the discussion page ( i guess that should be fair enough).
- How do we set up the corners of the transform frame after doing some transformations, they would be very easily converted into quadrilaterals, and sometimes pretty odd looking quadrilaterals, in which placing the perspective and scale markers would be even more complex.
- How do we change the rotation axis, suppose i dont want to rotate my selection around the centre of the rectangle, there doesnt seems to be any discussion regarding this over that page. I guess a neat idea would be to hide the move marker when a person clicks on rotation marker on the frame and make rotation marker permanent, after that till the user doesn't clicks on any other marker on the frame it should remain in the rotation__waiting state only. The only problem with it would be that aa user would not be able to use move marker just after rotation, but to do that he would have to click anywhere else on the frame first.
- How do I select a non-rectangular region for transformations?
Also, in my personal opinion, instead of changing the shape of transform frame with every operation it would be neater to keep it always rectangular where the size and position of rectangle is determined by the bounding box for the current transformation area, it could be any shape. And the current transformation area can be highlighted with dotted lines as it is done currently with most of the selection tools. This would solve many issues with restructuring of the frame after every transformation, and would make things pretty simple in my opinion.
Also, I had problems understanding transformation constraints, it would be really nice of someone to explain that.
Regards, Mohit
[Gsoc 2011] Unified transformation tool
Hello,
On Sat, Mar 26, 2011 at 8:20 PM, Mohit _ wrote:
Hi,
In the undo section it is mentioned that until the final pixel recalculation is done user should be able to undo every single step, though after that user should be able to undo the aggregate transformation only. Does this means that we would have to maintain another action stack just for unified transformation tool, or does gimp currently also maintains two different stacks, one for the current tool and one global stack for actions. If this is the case some reference to where it happens in code would be great.
Although I'm nobody official, I believe that this would happen through
the undo-group mechanism.
That is, when the latest group of undos was not 'closed', we should
undo within the group, and once it is 'closed', we should undo the
group as a unit (undoing an undo group as a unit is what currently
happens in general)
[Gsoc 2011] Unified transformation tool
David,
Thanks for the reply, but in the case of undo group, are the sub components of that group still saved individually in some sort of stack or are there different stacks for the group, and one general stack for all the groups.
Also, it would be great if you could point me to the code where it is happening.
On Sun, Mar 27, 2011 at 4:14 AM, David Gowers (kampu) wrote:
Hello,
On Sat, Mar 26, 2011 at 8:20 PM, Mohit _ wrote:
Hi,
In the undo section it is mentioned that until the final pixel
recalculation
is done user should be able to undo every single step, though after that user should be able to undo the aggregate transformation only. Does this means that we would have to maintain another action stack just for
unified
transformation tool, or does gimp currently also maintains two different stacks, one for the current tool and one global stack for actions. If
this
is the case some reference to where it happens in code would be great.
Although I'm nobody official, I believe that this would happen through the undo-group mechanism.
That is, when the latest group of undos was not 'closed', we should undo within the group, and once it is 'closed', we should undo the group as a unit (undoing an undo group as a unit is what currently happens in general)
[Gsoc 2011] Unified transformation tool
On Sun, Mar 27, 2011 at 3:42 PM, Mohit _ wrote:
David,
Thanks for the reply, but in the case of undo group, are the sub components of that group still saved individually in some sort of stack or are there different stacks for the group, and one general stack for all the groups.
Also, it would be great if you could point me to the code where it is happening.
I have no idea about how the implementation works internally :)
[Gsoc 2011] Unified transformation tool
Hi Austin,
This sounds pretty neat. I believe that since gimp still has certain tools in which one can undo the individual steps of that tool till one changes the tool, so I believe that there would already be a good enough infra tour for this.
Still any ideas who might be a good person to discuss my ideas regarding the ui. The specification for the unified transform tool seem to be added on wiki by guiguru, any idea if he is on the mailing list.
Regards,
Mohit
On Monday, March 28, 2011, Austin Donnelly -- yahoo wrote:
I did the last major changes to the undo system, to support the Undo History dialog.
When I last looked, there was only a single stack of undo actions. Some of those actions are special "start undo group" and "end undo group" markers: think of them as brackets ( ) around the individual operations. If you have an undo stack:
A B (C D) E
older wrote:David,
Thanks for the reply, but in the case of undo group, are the sub components of that group still saved individually in some sort of stack or are there different stacks for the group, and one general stack
for all the groups.
Also, it would be great if you could point me to the code where it is happening.
I have no idea about how the implementation works internally :) _______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer