GSoC - transformation anchors - before apply
Hello,
I am interested in working on the "transformation-anchors" project in GSOC this year. I am a graduate student in Computer Science in Canada.
I knew Inkscape would win GSOC projects this year, as usual. :-) Congrats. I hope it is not too late to say Hi here. Inkscape is one of my favorite open source software. I also have strong interests and work experiences in image processing, image editors. I have developed a vector-based graphics editor from scratch before. That graphics editor uses customized XML formats, have OOP architecture design to deal with all shapes/primitives with object classes, and allow SVG and DXF (Solidworks drawing file) import and export.
Therefore, it seems Inkscape GSoC projects are most interesting and relevant to me. The project, transformation-anchors, seems interesting and doable to me. Wiki docs are very helpful. It is impressive that GUI mock-up has already been posted several months before the Gsoc actually starts. I will read and plan in further detail.
I have similar work before, to have the default rotation center to be the geometric center of all shapes. Anchor coordinates are a part of the object (drawing) attributes. It can be adjusted, so that geometrical transformations, rotation, translation, scaling, and shearing, can be performed with the updated center. In this project, there will be some GUI modification, e.g. enable and disable buttons, display coordinates and values, take XY input from users, and allow undo and redo. Maybe some nice intuitive and simple designs will help on these. There may be some refactoring to do, but I am not sure. In this stage, I hope to understand more for this project. Please kindly share comments. I will draft a full proposal in about 10 days.
Technically, this project seems doable to me. Besides that I am good in C++, which may be a basic requirement, I have done some work using the following.
XML: I have used it for many projects, using C++, Python, C# and Java. Libraries used: .NET, DOM, JDOM, Minidom. SVG: I have written a SVG viewer before. GTK+: I have experience with it. It is the most complex GUI widgets that I have used. SVN: I used it at work before.
Regards,
Zhenfeng.
On Wed, Mar 24, 2010 at 12:12 AM, < inkscape-devel-request@lists.sourceforge.net> wrote:
Send Inkscape-devel mailing list submissions to inkscape-devel@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/inkscape-devel or, via email, send a message with subject or body 'help' to inkscape-devel-request@lists.sourceforge.net
You can reach the person managing the list at inkscape-devel-owner@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific than "Re: Contents of Inkscape-devel digest..."
Today's Topics:
- Re: bzr question (Marcin Floryan)
- Re: bzr question (Ted Gould)
- Re: Inkscape-Aqua for Snow Leopard (~suv)
- Re: Inkscape-Aqua for Snow Leopard (Stuart Edwards)
- Re: Inkscape-Aqua for Snow Leopard (Stuart Edwards)
- Re: GSoC 2010 Cairo canvas (Krzysztof Kosi?ski)
- Re: GSoC 2010 Cairo canvas (Krzysztof Kosi?ski)
- Re: Hello everybody & GSoC Open Asset Import Library (Carl Worth)
On 3/24/10, Zhenfeng Zhao wrote:
Hello,
I am interested in working on the "transformation-anchors" project in GSOC this year.
Go bless you for that! Some hardcore XFig users get really hot about this feature missing in Inkscape.
And... You traded GIMP for Inkscape this GSoC? :)
SVN: I used it at work before.
We rely on bazaar-ng these days, but it bears some resemblance to SVN, so it shouldn't be a problem.
Alexandre
On Wed, Mar 24, 2010 at 4:04 AM, Zhenfeng Zhao <zhenfeng.zhao.8@...400...> wrote:
Hello,
I am interested in working on the "transformation-anchors" project in GSOC this year. I am a graduate student in Computer Science in Canada.
Great, thanks! Please take into account my comment at the page of the spec:
http://wiki.inkscape.org/wiki/index.php/SpecTransformAnchors
As far as I can see the interface mock-ups ignore this comment, so they need to be redone. The essence of it is that we must not introduce two different entities: center of rotation and anchor; we should have a single thing, the one now marked by the cross, and everything should move it and refer to it. This object already exists in the code, basically what you need is just add more UI facilities to move it. It is also (already) automatically saved into SVG per object, if moved. So we don't need that star button for separate "rotation center", but instead we need a way to set its coordinates numerically.
Please feel free to discuss or ask any questions you might have. The saving of the rotation center was coded by John Cliff, maybe he will agree to be your mentor for this?
Hi Bulia,
Thank you very much for the quick reply, and comments.
On Wed, Mar 24, 2010 at 12:55 PM, bulia byak <buliabyak@...400...> wrote:
On Wed, Mar 24, 2010 at 4:04 AM, Zhenfeng Zhao <zhenfeng.zhao.8@...400...> wrote:
Hello,
I am interested in working on the "transformation-anchors" project in
GSOC
this year. I am a graduate student in Computer Science in Canada.
Great, thanks! Please take into account my comment at the page of the spec:
http://wiki.inkscape.org/wiki/index.php/SpecTransformAnchors
As far as I can see the interface mock-ups ignore this comment, so they need to be redone. The essence of it is that we must not introduce two different entities: center of rotation and anchor; we should have a single thing, the one now marked by the cross, and everything should move it and refer to it. This object already exists in the code, basically what you need is just add more UI facilities to move it. It is also (already) automatically saved into SVG per object, if moved.
OK. I have tried it and found out what it does. The center of rotation, marked as cross, can be dragged and moved to a different location. It is saved for the object, so that when closing and reopening this SVG file, we can see the cross (center of rotation) stays where it is left. In the SVG file, it shows:
inkscape:transform-center-x="7.6874748" inkscape:transform-center-y="-3.2402241" /
I can see it is a field or attribute of the path object.
So we don't need that star button for separate "rotation center", but instead we need a way to set its coordinates numerically.
Do you mean that we need some UI facilities to allow moving this center easily with better control? This way, it would be easier for users to know where it can be moved to, and what that will do.
Do we need to use that 9-button-matrix shown in the Wiki?
I understand the needs to input center coordinates. This way, all transformations will perform based on it.
I also tried to move the center, and did some tests for different transformations. - For rotate and skew, different centers will give different results. (It is the most obvious for rotation.) - For scale, moving the center gives the same results, with the same transform values.
Are we keep this way?
Regards,
Zhenfeng.
Please feel free to discuss or ask any questions you might have. The
saving of the rotation center was coded by John Cliff, maybe he will agree to be your mentor for this?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Thu, Mar 25, 2010 at 3:44 AM, Zhenfeng Zhao <zhenfeng.zhao.8@...400...> wrote:
Do you mean that we need some UI facilities to allow moving this center easily with better control? This way, it would be easier for users to know where it can be moved to, and what that will do.
Right now it can be dragged freely, but some people need more precision, which is why we need X/Y fields for it I think they should be at a separate tab of the Transform dialog.
Do we need to use that 9-button-matrix shown in the Wiki?
Definitely, it's a handy widget, and familiar to users from other programs.
I also tried to move the center, and did some tests for different transformations.
- For rotate and skew, different centers will give different results. (It is
the most obvious for rotation.)
- For scale, moving the center gives the same results, with the same
transform values.
Are we keep this way?
Not quite. Speaking about transform with handles, we're fine: we have simple drag which should remain as is, and Shift+drag which scales around the rotation center which is also fine. But scaling by numbers is messy: selector toolbar does it relative to top right corner, and Transform scales around geometric center. Both should use rotation center too, and X/Y in selector toolbar should also display the coords of that center, not the top left corner as now.
On Thu, Mar 25, 2010 at 11:22 AM, bulia byak <buliabyak@...400...> wrote:
Not quite. Speaking about transform with handles, we're fine: we have
simple drag which should remain as is, and Shift+drag which scales around the rotation center which is also fine. But scaling by numbers is messy: selector toolbar does it relative to top right corner, and Transform scales around geometric center. Both should use rotation center too, and X/Y in selector toolbar should also display the coords of that center, not the top left corner as now.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
OK, I thought that was a bug/issue, having scaling works slightly differently from other transformations, or not using the rotation center. I agree that they should be consistent and use the rotation center. If I understand correctly, the goals are to (i) allow precisely inputting XY coordinates, and have 9-button widget to assist it, and (ii) have a few fixes so that all transformations will be around the rotation center, which is more consistent.
It sounds like some interesting work to do. I will need some time to be familiar with these parts. I just saw what selector toolbar is. It is the mouse icon, and its tool bar shows the XY coordinates for the shape. It seems to be the bottom left corner though. Or, it is just my version is not really updated.
At work before, I recommended some GUI adjustments and designs according to Inkscape's style. That software has too many pop-up dialog boxes. With the tools on the left, and its tool bar in the top, it is much better than having to open and close any input dialogs. :-)
I wonder what kind of UI is needed for rotation center XY coordinates. Thanks.
Regards,
Zhenfeng.
On Thu, Mar 25, 2010 at 8:19 PM, Zhenfeng Zhao <zhenfeng.zhao.8@...400...> wrote:
OK, I thought that was a bug/issue, having scaling works slightly differently from other transformations, or not using the rotation center. I agree that they should be consistent and use the rotation center. If I understand correctly, the goals are to (i) allow precisely inputting XY coordinates, and have 9-button widget to assist it, and (ii) have a few fixes so that all transformations will be around the rotation center, which is more consistent.
Exactly.
It sounds like some interesting work to do. I will need some time to be familiar with these parts. I just saw what selector toolbar is. It is the mouse icon
called "tool"
, and its tool bar shows the XY coordinates for the shape. It seems to be the bottom left corner though. Or, it is just my version is not really updated.
weird, it is normally above the canvas
At work before, I recommended some GUI adjustments and designs according to Inkscape's style. That software has too many pop-up dialog boxes. With the tools on the left, and its tool bar in the top, it is much better than having to open and close any input dialogs. :-)
Yes, certainly, being able to do more in the main interface without opening any dialogs is best.
I wonder what kind of UI is needed for rotation center XY coordinates.
Just a couple spinbuttons for X and Y plus a unit selector, defaulting to the document units.
Hi, I'm the author of the specification.
@Z. Zhao
I am interested in working on the "transformation-anchors" project in GSOC this year.
Good to hear! Welcome. If something on the spec is not clear just ask on this mailing list. I'm not a coder but I might be able to help you. I have the original SVG files of the GUI mock-up in case you want to play with them.
For your consideration: there are two other projects related to this one: * 1) adjust origin of coordinates of document * 2) allow math operations (like sum, substraction, multiplication, division) inside the spin boxes for Height, Width, X, Y; and now I would add center of transformations. Doing everything in just one run might be too much but try to keep them in mind.
@b. byak
I wonder what kind of UI is needed for rotation center XY coordinates.
Just a couple spinbuttons for X and Y plus a unit selector, defaulting to the document units.
The unit selector is already there with X, Y, Height and Width. Why not reuse it and just have one unit selector for everything? (I'm guessing you meant this).
As far as I can see the interface mock-ups ignore this comment, so they need to be redone.
The mockups do ignore it. But I left you a comment saying that I agreed with you. I didn't want to update them because I prefer if the development of the idea is shown. New mockups should be done and appended instead of updating the old ones. It would be confusing if readers read old comments which point to new mockups.
@both:
the goals are to (i) allow precisely inputting XY coordinates, and have 9-button widget to assist it, and (ii) have a few fixes so that all transformations will be around the rotation center, which is more consistent.
Exactly.
Yes, exactly. The 9-button widget is there to move the X/Y coordinates. The spinbuttons should be update to reflect the selection of one of nine anchors.
Regards.
On Fri, 2010-03-26 at 23:09 +0300, Alexandre Prokoudine wrote:
On 3/26/10, Pajarico wrote:
- allow math operations (like sum, substraction, multiplication,
division) inside the spin boxes for Height, Width, X, Y; and now I would add center of transformations.
Just steal code from GIMP 2.7.0+ :)
And C++ify it ;)
Cheers, Josh
participants (5)
-
Alexandre Prokoudine -
bulia byak -
Joshua A. Andler -
Pajarico -
Zhenfeng Zhao