GSoC 2010, pen tool and layers dialog
by Matthew Todd
Hello,
My name is Matthew A. Todd. I am a second year computer science student at UCSD interested in working on Inkscape as part of Google Summer of Code.
During my use of Inkscape previously, I had wanted a couple of changes/feature additions. I would like the chance to add these features, with some help, as my project in GSoC.
I'm posting here for feedback regarding my ideas. I don't have enough experience to know how long it would take to implement them. I don't even know if others besides myself would even find such functionality useful.
First idea (pen tool):
I primarily use the pen tool, and would like to add the following to it:
When drawing a curve, often times I place a node then decide I want to move the node's position. In Adobe Illustrator, this is accomplished by simply pressing a key (the space key.) I would like to add this ability to Inkscape.
Currently, this is already possible through the use of the arrow keys. But allowing the user to move the node with the mouse would increase ease of use because the user wouldn't have to take his or her hand off the mouse. Also it would allow him or her to move the node more quickly. And he or she could still use the arrow keys if desired.
Because the arrow keys method already exists, adding the use of the mouse is by no means of high importance. But several times I have desired such functionality.
Second idea (layers dialog):
I find the layers dialog to be a little cumbersome.
Its not possible to simply move layers up and down by dragging them. Instead an user has to click a button or press a key combination. I think adding this small feature will increase ease of use because then the user doesn't have to click multiple times if there are many layers. He or she could simply just drag the layer to the desired location.
The layer dialog doesn't show what is in a layer. So currently, the only option is to hide all other layers, which still isn't a great solution. Adding the ability to inspect items in a layer and move them in z-order or perhaps even move them to other layers, would make layers work better. I'm thinking of something would look like a tree view. Again, I came over from Adobe Illustrator, so my idea of what it would like is similar to how Illustrator's layer dialog, but it need not be.
Thanks,
Matthew A. Todd
13 years, 8 months
Re: [Inkscape-devel] Intel Aqua packaging
by ~suv
On 8/4/10 13:40, Lloyd Sargent wrote:
> Okay, I went back and looked at the build info and I've found two problems:
>
> #1.
>
<...>
> The following build commands failed:
> ScriptExec:
> ProcessPCH /var/folders/D+/D+KS42xe2RWRN++1YwAjD++++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/ScriptExec_Prefix-fufpslfnljyhqverjsxrfdvyqeus/ScriptExec_Prefix.pch.gch ScriptExec_Prefix.pch normal ppc c com.apple.compilers.gcc.4_2
> ProcessPCH /var/folders/D+/D+KS42xe2RWRN++1YwAjD++++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/ScriptExec_Prefix-ewyzzpalxmpnnsapxxvoyqkdnuir/ScriptExec_Prefix.pch.gch ScriptExec_Prefix.pch normal i386 c com.apple.compilers.gcc.4_2
> (2 failures)
See my earlier answer to Stuart:
On 22/3/10 14:00, ~suv wrote:
> Yes, the lack of MacOSX10.4u.sdk is obviously significant for the
> available xcodeproject of the application launcher. Please be aware that
> the release version 0.47 was not built on Snow Leopard, nor are the
> current development snapshots built on Snow Leopard. I.e. you are trying
> to do something new that seems to require part of the packaging modules
> to be modified and updated to run on OS X 10.6 Snow Leopard.
>
> I recommend to file a bug report, detailing the SL related errors you
> see when trying to package the application. Please include all relevant
> information about your OS and Xcode version.
I'm not familiar with Xcode projects and don't know what changes are
needed to compile 'ScriptExec' on Snow Leopard. Earlier in this thread
it was mentioned to use gcc 4.0 instead of gcc 4.2 when employing the
MacOSX10.4u.sdk on SL, but I don't know which changes you'd have to make
to which files to change the compiler for the Xcode project only (you
don't want to downgrade the compiler when building MacPorts or Inkscape
itself).
Looking at your error messages I see two issues to be addressed:
1) carbon vs cocoa (i.e. has anyone tried to create a new application
launcher - ScriptExec - based on a current version of Platypus that
might build with the 10.5 or 10.6 SDK?)
2) Universal build for PPC/i386 as target? (i.e. do we need 'ScriptExec'
to be built Universal on Snow Leopard, and if so, does it need to
support PPC - considering that SL doesn't run on PPC arch - or should
the (platypus) launcher application be built either as Universal
i386/x86_64 or as x86_64 only on Snow Leopard?).
> #2
>
> cp: /opt/local/etc/pango/pangox.aliases: No such file or directory
>
> Which makes sense as I have no pangox.aliases... what package would
> this be from. I've built and installed pango, so that's not the problem...
Has been answered in this thread already: the file is installed by pango
when compiled with support for the X font backend. AFAICT the file is
not needed when using Inkscape with GTK+/Quartz and both the packaging
scripts and the application launcher script put inside the application
package will have to be adapted to not look for this file when
building/launching Inkscape without X11:
On 22/3/10 14:00, ~suv wrote:
> The GTK+/Quartz (so-called "Aqua") version will also require changes to
> both the build scripts and the launcher scripts - but this should be
> handled in a separate bug report, similar to the one Wolf filed for
> removing the code launching X11 on Tiger.
~suv
13 years, 8 months
Hello Inkscape Developers
by Peter Boström
Hello!
I thought I'd finally send out a word or two and introduce myself. My
name is Peter, I'm a second-year computer-science student at the Royal
Institute of Technology here in Sweden. I've been programming casually
for a few years before school, but most things I've done have either
been simple or been abandoned. Though as a last-year project for high
school, I made a simple fast Guitar-Hero clone in C. I'm also currently
working on a game with a friend, which is slowly coming together.
I'm making a proposal with Google Summer of Code to create a new
New-From-Template dialog. I think Inkscape has a good interface, and
it's one that I'd definitely want to help improve. Without previous
experience with the code base, it's also a project that I find feasible
to finish. A template menu, I think, is a good thing, so it's a part
that I'd want to keep. I just think it needs to become structured into
categories as well. So if you just need a static template for a CD, you
can go to New.. -> Covers -> CD.
In case this proposal gets accepted, I'd want to regularly provide
something for feedback, either from this list or a mentor, wherever
suitable. I think the interface is important, so this needs to be
something that everyone would find easy to use. Also, I'm very
interested any ideas you may have. (:
Best to mention: I submitted a patch that resolves the following
wishlist ticket: https://bugs.launchpad.net/inkscape/+bug/43730
This patch reports export results to the main window status bar. To have
it report properly, I had to change sp_export_png_file's return type, as
suggested, to an enum. It now returns EXPORT_OK, for a successful
export, EXPORT_ERROR=0 for an error, and EXPORT_ABORTED for a canceled
overwrite. I think it's a good change, because it makes this dialog more
verbose. I hope you agree. Existing code checks for a false value, if(!
sp_export_png_file...), which still works, same as before.
I'd be happy to answer any and all questions you might have!
Best regards
- Peter Boström
13 years, 8 months
Re: [Inkscape-devel] Intel Aqua packaging
by ~suv
On 8/4/10 05:50, Lloyd Sargent wrote:
> 1. Macports installed at /opt/local
>
> 2. DYLD_LIBRARY_PATH was uncommented.
>
> With the above I get the same error as the OP (worse I had to make sure
> the 10.4 SDK was installed).
>
> So something else is going South. Any suggestions?
I don't know what error you are referring to - it might help if you
attach the crash log / console messages (but I haven't built the +quartz
version myself nor am I using Snow Leopard - which I assume you do since
you mention the 10.4 SDK optional install?)
~suv
13 years, 8 months
Mac OS X: osx-dmg.sh - osascript: dmg_set_style.scpt
by Wolf Drechsel
Hello everybody,
I tried to dmg inkscape 047 X11 - but ended up with an image, which
contains a link to /Applications and a folder called "Contents" -
which seems not to be a .app bundle.
When running the osx-dmg.sh, I get the message:
osascript: dmg_set_style.scpt: No such file or directory
In fact, the dmg_set_style.scpt cannot be found on my machine, it
looks as if it were contained by earlier source packages and dropped
recently.
Could somebody be so kind and mail me the script - or - in the case -
guide me to another solution of that problem.
Yours, Wolf
13 years, 8 months
Document versioning (was: Coordinate system fix)
by Krzysztof Kosiński
W dniu 6 kwietnia 2010 18:31 użytkownik bulia byak
<buliabyak@...400...> napisał:
> 2010/4/6 Krzysztof Kosiński <tweenk.pl@...400...>:
>> W dniu 6 kwietnia 2010 15:33 użytkownik bulia byak
>> <buliabyak@...400...> napisał:
>>> This sounds inevitable, but rather hairy. Why have both
>>> inkscape:version and inkscape:document-version? Can you get what you
>>> need with inkscape:version only?
>>
>> 1. Document version changes must be atomic, because the upgrade is
>> conducted only one time for each type of defect. This means
>> inkscape:document-version (or inkscape:document-format) can change
>> several times between two releases.
>
> But why can't we just fix ALL the defects we find between 0.47 and
> 0.48 and have just two states of upgrade for <=0.47 and for >=0.48?
The upgrade procedure must run exactly once for any document. This
means that if we introduce a change in the interpretation of XML
between revision FOO and FOO+1, then FOO+1 must perform the upgrade on
documents saved in FOO and earlier, but it must also be smart enough
not to upgrade documents saved with FOO+1. That's true regardless of
how many defects are fixed in each version or how many document
formats there are. This means the version number must be accurate down
to a single revision, which is a bad idea for reasons I've already
mentioned. If we have only the bare version number (e.g. 0.47 or
0.48), then anything saved in FOO+1 or later cannot be opened until we
make a stable release.
It would be possible to have the document format version number equal
to the Bazaar revision in which it was first introduced. However, this
would complicate working on the backwards compatibility fixes in
branches. I think a simple number increasing from 1 would be the best
way to go.
This is hairy, possibly tedious to implement, etc., but at the same
it's the long-term solution.
Regards, Krzysztof
13 years, 8 months
Bug Hunt Update - 93/300
by Joshua A. Andler
Hey all,
Here is the current Bug Hunt scoring. I'm starting the count as of 3/29.
Following past traditions, here is how it works:
Scoring:
Low: 3 pts
Med: 6 pts
High: 9 pts
Critical: 12 pts
Double if over one year old.
Only fixes to "true bugs" (i.e. no website/translation/docs/etc. bugs).
This list contains fixes between 3/29 - 4/7 @ 2:22pm PST.
Pts BugID Fixer Description
------------------------------------------------------------------------
3 520532 Kosiński Single app for GUI and console mode on Windows
12 215020 Kosiński Win32 - DOS/Command window pops up when...
12 168557 Jon Cruz Fill & Stroke dialog randomly stops updating..
9 544833 Jon Cruz Crash in SVG font editor on "New"
6 541956 Kosiński comandline option don't work on win xp
6 522327 Daniel_J Inkscape 0.47 fails to build with GCC 4.5
3 554109 Kosiński unwanted printout of PYTHONPATH (Win32)
12 167455 Kosiński WinXP2: Command line file names not current...
9 551433 Kosiński inkex.py not found for extensions in user's...
6 553911 Jon Cruz Inkscape hangs when selecting CJK fonts in...
6 556233 Jon Cruz 'Rows and Columns' dialog fails when used...
3 548918 Alvin Penner HPGL output scaling incorrect
6 512447 Alvin Penner save as in DXF format fails in 0.47
------------------------------------------------------------------------
13 years, 8 months
GSOC proposal - Improve GUI for transformation center
by Zhenfeng Zhao
Hello,
I appreciate all suggestions and technical details from you as to the
“transformation anchor” project. I have summarized them into a proposal in
the following. There is plenty of information for the project goal and plan.
Later discussion, confirmation on tasks, and further input may help me to
keep in the right track in the implementation. So far, the project and its
tasks seem clear enough to me. And, according to my experience, I can see
that this project can be done. As well, if there is any time left (I guess
there would be), I would like to work on adjusting origin of document
coordinates, and allowing math operations for spin boxes.
The beginning of April is often the busiest time for students in Canada. It
will be much better in the summer (May to August). Last year, I completed a
10+ page proposal for Gimp in the last day. This year, I am slightly
earlier, after talking in Inkscape mailing list for half a month.
Your feedback will be welcome and important. Then, I will submit the
proposal very soon, or I will revise it there. Thank you very much.
Regards,
Zhenfeng.
GSOC proposal - Improve GUI for transformation centers
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
PROJECT SUMMARY (a longer abstract)
There are some existing issues with selecting and modifying the
transformation center. This project focuses on improving and modifying GUI
for transformation centers to solve existing issues and enhance precision
and flexibility. In the three month GSOC period, first I will discuss with
Inkscape designers and decide a GUI mockup as an implementation guide. With
the further analysis and detailed plan, possible refactoring will be done. A
control of precision of moving the transformation center will be
implemented. Center coordinates would be set numerically. There will be a
9-button-matrix widget that is used to quickly move the center to 9
positions, and a separate tab in the Transform dialog, for adding XY fields
using a couple spin-buttons for X and Y. Then, the linkage between the
9-button-widget and the spin-buttons can be done.
Another relevant projects will be analyzed and implemented (i) adjust origin
of coordinates of document, and (ii) allow math operations (sum,
substraction, multiplication, division) inside the spin boxes for Height,
Width, X, Y.
All implementations will be tested and ensure accuracy, flexibility, and
robustness. All code produced will follow the Inkscape coding style.
Documentation will be done during coding.
BACKGROUND AND SKILLS
I am interested in working on the "transformation-anchors" project in GSOC
this year. Inkscape is one of my favorite open source software. 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. The following is a few points about my background.
· Master student in Computer Science (GPA: 4.0/4.0) in Canada, thesis:
medical image processing and 3D reconstruction.
· Successfully completed GSOC 2009 for a Gimp project, Advanced GUI for
brush dynamics.
· Four years full-time work experience in programming and architecture
· Played key roles in technology R&D and innovation in image processing,
vector graphics, 3D modeling, and CAD
I have developed vector-based graphics editors both from scratch and on
existing large applications. One of them is for a leading manufacturing
company in Canada. For example, a graphics editor uses customized XML
formats, have OOP architecture design to deal with all shapes/primitives
using object classes (e.g. rectangle, ellipse, closed-path with arcs and
lines, curves), and allow SVG and DXF (Solidworks drawing file) import and
export. I have used Inkscape and SVG at work for one year (e.g. for SVG
work, and GUI and HCI design example). One of my contributions for this
software is to replace the previous raster based image editor with vector
based editor using custom XML format.
Every year, hundreds of customers use it for industrial designing, including
NASA, Boeing, Google, Microsoft, MIT, US Army, GE, GM, Lockheed Martin, and
many more. The company can product near anything that is made using the
software. Meanwhile, the R&D goal was to provide the software that reflects
what products can be made. Therefore, it is high level quality software that
provides flexibility and precision. A few highlights of my work:
· Completed the release of version 3.1 within 1.5 months of hire,
with minimal input
· “accomplished tasks the first day that took half a month before;
amazing” – President
· “The good news is, you are on the top.” – Chairman, in a review
for R&D team performance
Besides this software, I have developed dozens of image and video editors.
When I worked as Lead Developer with 2D-3D Video Inc. for two years, I
worked on image processing, and video editing software, and 2D to 3D
image/video conversion. I have led the development of 3D movie player on
iPhone/iPod Touch, and LG 42-inch 3D TV. The technology is used to convert
image or video and generate 3D viewing effects without 3D glasses required.
Sample work:
3D face of Barrack Obama. It is converted to 3D photorealistic view using a
single 2D still face photo.
http://www.2d-3dvideo.com/3Dphotos/BarrackObama.wmv
Other:
http://www.2d-3dvideo.com/NewSite/SchoolPhoto.wmv
http://www.2d-3dvideo.com/3Dphotos/Couple.wmv
http://www.2d-3dvideo.com/3Dphotos/33framerotation24degree.wmv
http://www.2d-3dvideo.com/IDcards/male130BG40deg.wmv
In my Master thesis research, I have had two publications, and will have
couple more soon. I have developed new algorithms and techniques in image
segmentations, interpolations, 3D reconstruction, and missing structure
generation. Since the work deals with different shapes, it has a vector
graphics sense. I used XML to store and process 3D structure and wireframes.
Technically, I am good in C++. 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. It is used in my thesis and each
of my jobs at work.
SVG: I have written a SVG viewer before.
GTK+: I have experience with it in the Gimp GSOC project.
Git and SVN: I used it at work before.
Bazaar: I tried it, and it is very similar with SVN and Git.
PROBLEMS AND IMPLEMENTATION PLAN
A well designed GUI and interaction of transformation anchor manipulation is
very important for Inkscape. Currently, the rotation center (in an example
of transformation) can be dragged freely. However, where it is dragged to
cannot be precisely defined, except eye-balling roughly.
There needs to be new UI facilities with an intuitive design that allows the
precise adjustment of the center. This precision control is expected to be
useful to many Inkscape users, such as Xfig users. In the Transform dialog,
XY fields need to be added as a separate tab. A 9-button-matrix widget,
which is intuitive and helpful to users, will be implemented to assist
moving the center among nine locations easily with one click.
To prevent errors or misleading, there should not be center of rotation and
anchor as two different entities. A single tool should be used, which is
marked by the cross. Then, all transformations should refer to it. Since
this object exists in the code, a list of better UI facilities can be added
to move it. As well, the cross can be automatically saved into SVG for each
object.
A simple test was done to confirm this. The center of rotation, marked as
cross, can be moved to a different location. It is saved for the object, so
that when closing and reopening this SVG file, the cross (center of
rotation) stays where it is left. In the SVG, the fields or attributes of
the path object shows:
inkscape:transform-center-x="7.6874748"
inkscape:transform-center-y="-3.2402241" /
Another quick test was done for moving the transformation centers.
- For rotate and skew, different centers will give different results.
- For scale, moving the center gives the same results, with the same
transform values.
- Transform using handles is correct. A simple drag keeps the center as it
was, and Shift+drag scales around the rotation center.
Obviously, there is an issue in the consistency with scaling. It does not
work correctly if scaling by numbers. Selector toolbar, or the mouse tool in
the top left interface, uses the top right corner, while Transform scales
around the geometric center. The correct way is to use rotation center for
scaling, with X/Y in selector toolbar displaying the coordinates of the
center. The above issues will be fixed.
The UI needed for rotation center XY coordinates is a couple
Gtk-Spin-Buttons for X and Y plus a unit selector, defaulting to the
document units. Since there is already the unit selector for X, Y,
Height and Width, it may be used without writing a new one.
After the 9-button-widget is used to move the X/Y coordinates, the
spinbuttons should be updated to reflect the selection of one of nine
anchors. Hence, the linkage is required for the 9-button-widget and the
spinbuttons.
It was pointed out that there were two other relevant projects related to
this one:
- adjust origin of coordinates of document
- allow math operations (sum, subtraction, multiplication, division) inside
the spin boxes for Height, Width, X, Y.
I believe that it would be more beneficial if I work on this two during
GSOC. The main focus of the project is on transformation centers, and the
above two will be analyzed and planned, when transformation center tasks are
half way through. I will propose another implementation plan for them, with
a reasonable class structure design/rewrite.
I will work on the two after completing the transformation center project.
If there is no
time to finish all of these in three months, I will try to make sure
on-going work is easy to do. After the three months of work, I may be
interested to continue contribution.
At some point later, it may become clear what can be done, when unknowns are
solved.
It was suggested that the math operations can be taken from GIMP 2.7.0+. It
can be done easily with my previous experience in Gimp contribution. Taking
code from open source is something that I have done for many times, both for
Master thesis and at-work programs. Recently, I took some open source code
of spline interpolations into my thesis. Translating math operations into
C++ is doable too. I do porting of different languages on daily bases.
TASKS AND TIME TABLE
Goal: Improve GUI for transformation centers for precision and flexibility
1. Communication. May 10 – May 20.
Communication with the mentor.
Code review on relevant source code, class structure.
2. Studying. May 21 – May 25.
Study Inkscape development workflow, coding style, committing process.
Study libraries required.
3. Reaserch. May 26 – June 6
Analysis of the architecture.
Discuss and decide a GUI mockup as an implementation guide.
Get familiar with sample SVG files and GUI mock-up that Pajarico has.
Preparing a list of implementation.
Intuitive GUI design.
4. Coding and implementing. June 7 – July 17
Possible refactoring.
Precision of center moving.
Fix the issues for scaling around different centers.
Allow setting the center coordinates numerically
Add 9-button-matrix widget
Add XY fields in a separate tab of the Transform dialog
Implement XY coordinates UI, a couple Gtk-Spin-Buttons for X and Y.
Ensure the linkage between the 9-button-widget and the spinbuttons.
Display coordinates and values, take XY input from users, and allow undo and
redo
5. Second stage implementation. July 18 – July 31.
Further analysis of two relevant projects:
1) adjust origin of coordinates of document
2) allow math operations (sum, substraction, multiplication, division)
inside the spin boxes for Height, Width, X, Y.
Have another implementation plan for them, with a reasonable class structure
design/rewrite.
Implement them.
8. Overall debugging, code optimization and further improvements. August 1 -
August 10.
9. Further optimization. August 11 - August 15.
10. Documentation and clean up. August 16 - August 20.
REFERENCES AND LINKS:
http://wiki.inkscape.org/wiki/index.php/Google_Summer_Of_Code
https://blueprints.launchpad.net/inkscape/+spec/transformation-anchors
http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/inkscape
https://bugs.launchpad.net/inkscape
http://wiki.inkscape.org/wiki/index.php/InkscapeInvariants
http://inkscape.org/bzr.php
Note:
I am also interested in a few other interesting projects:
- Power Stroke - Modulated width stroke LPE.
- xar-to-svg converter - Converter for Xara Xtreme to Inkscape
- KML SVG translation - For use of Inkscape with Google Earth or Maps
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
13 years, 8 months
Problem of chatting in IRC
by Zhenfeng Zhao
Hi,
I have a question about chatting in IRC. In windows, it did not work for me.
So, I just tried XChat in Linux. Now I can see other people chatting in the
channel. But I cannot send messages there.
I have changed it to utf-8.
#inkscape :Cannot send to channel
Charset changed to: utf-8
Still, it shows:
<ZZF_> hello
* #inkscape :Cannot send to channel
Also, some more messages below... Can anyone told me how to fix it, in order
to chatting in the channal? Thank you.
<ChrisMorgan> That is probably all you need, but if you need more, you could
create a rectangle the size of the whole thing and apply it as a clipping
mask.
<ChrisMorgan> (Then everything else would need to be in a group)
<kn100> so in other words there's no way to hide overflow at the design
stage without changing how i work with the tool?
* troy_s has quit (Quit: Leaving.)
* vlada has quit (Remote host closed the connection)
* Justicejr (~Justicejr@...2337...) has joined
#inkscape
<ZZF_> hello
* #inkscape :Cannot send to channel
Regards,
Zhenfeng.
13 years, 8 months
