The Google Summer of Code projects are due to wrap up by September 1st.
We've been quite thrilled at the progress made from the SOC students,
but as they say, all things must come to an end.
We've not received direction from Google about the next steps, which is
kind of weird... I have expected we'd see some directions by now.
Possibly we'll hear something tomorrow?
In any case, based on what we've been told in the past, we expect that
we're going to need to go through a review phase where the mentors check
the student's work and decide whether it is acceptable. I think each
mentor will have his own set of criteria to judge from, but there are
some expectations that I suspect will be weighed heavily on:
* Has the code been checked into Inkscape CVS?
* Does the code function well enough that people can at least test it
* Has the developer participated with other inkscape developers to
ensure that bugs are fixed, requested changes made, etc.?
* If the developer has "bitten off too much to chew", have they
triaged the requirements and implemented an adequate subset?
Of course, if the code implements 100% of what was mentioned in the
original proposal, that's even better. ;-) But as long as it meets
most of the requirements and shows that the participant has been
successful at learning Open Source, I would think it would be
= Analysis Report for inkscape =
Platform Unpack Config Install WRNS ERRS
debian x86 0 0 2 5 28
Test Status Score Info
== Errors ==
attributes.cpp:34: error: syntax error before `<<' token
attributes.cpp:37: error: syntax error before `>>' token
connector-context.cpp:1195: error: syntax error before `<<' token
connector-context.cpp:1199: error: syntax error before `if'
connector-context.cpp:1199: error: ISO C++ forbids declaration of `__r' with no
connector-context.cpp:1199: error: redefinition of `int __r'
connector-context.cpp:1199: error: `gboolean __r' previously declared here
connector-context.cpp:1199: error: syntax error before `}' token
connector-context.cpp:1212: error: `inkscape_active_desktop' undeclared (first
connector-context.cpp:1212: error: (Each undeclared identifier is reported only
connector-context.cpp:1230: error: `cc_item_is_shape' undeclared (first use
connector-context.cpp:1249: error: syntax error before `>>' token
connector-context.cpp:1256: error: `selection' was not declared in this scope
connector-context.cpp:1258: error: syntax error before `if'
connector-context.cpp:1269: error: redefinition of `GType __t'
connector-context.cpp:1199: error: `GType __t' previously declared here
connector-context.cpp:1269: error: redefinition of `gboolean __r'
connector-context.cpp:1199: error: `int __r' previously declared here
connector-context.cpp:1269: error: syntax error before `if'
connector-context.cpp:1269: error: ISO C++ forbids declaration of `__r' with no
connector-context.cpp:1269: error: redefinition of `int __r'
connector-context.cpp:1269: error: `gboolean __r' previously declared here
connector-context.cpp:1269: error: syntax error before `}' token
connector-context.cpp:97: error: `void
sp-item.cpp:324: error: syntax error before `<<' token
widgets/toolbox.cpp:2993: error: `cc_selection_set_avoid' undeclared (first use
widgets/toolbox.cpp:2993: error: (Each undeclared identifier is reported only
widgets/toolbox.cpp:2999: error: `cc_selection_set_avoid' undeclared (first use
== Warnings ==
display/canvas-arena.cpp:91: warning: invalid access to non-static data member
display/canvas-arena.cpp:91: warning: (perhaps the `offsetof' macro was used
display/sp-canvas.cpp:127: warning: invalid access to non-static data member `
display/sp-canvas.cpp:127: warning: (perhaps the `offsetof' macro was used
libnrtype/Layout-TNG-Output.cpp:226: warning: enumeration value `
== Environment Summary ==
DXF export is now possible...
At my website (http://ucsu.colorado.edu/~squiresm/), that hopefully will
not be needed much more, I have posted .inx and .sh files that will export
to dxf using pstoedit. I found that dxf is already supported, there are a
fair number of features that I haven't explored. The conversion seems to
I also have more functionality in the dxf import. Layers are supported
and I have turned linetypes back on. The linetype is a little buggy
because it is defined in two places and I have tried to make a good
decision about which definition takes precedence. I also fixed problems
with bulges in plines and lwplines. The files are there for color
conversion, but I haven't included the color yet in the SVG.
I am open to people sending me their favorite dxf and then I test it
against AutoCAD (there is a license at school) or if you test a file and
you don't see what you want then let me know.
Eric: Along those lines... you are right the projection of a tilted
circle on a plane below should look elliptical. I will fix that sometime
> Generally, our policy is to provide at least one patch, and if good,
> then we give you cvs...it is our primary policy.
I will get a patch tomorrow when I have better facilities
Now that 0.42 is done, I thought I'd send the extension version of svgslice
for others to test and consider for inclusion.
It's pretty basic: just saves marked sections of the image into separate PNG
"slices", and generates a basic XHTML file that lists the slices. Most
notably, no equivalent layout is done in the XHTML file, so that it looks
like the original SVG drawing. Problem is, there are many ways to do that in
CSS, and the most obvious way (absolute positioning) is probably not much use
to people. I suspect it would lead to bad web pages, or just get in the way
of proper hand-crafted layout, and people who want to use a WYSIWYG CSS
editor to move them around easily can still do so.
Note also, that the slices will be saved in Inkscape's current directory. If
you load inkscape by double-clicking on an image in a project folder, and
save the XHTML file in the same folder, then this is fine -- your startup
directory will be that folder, and images will be right alongside the XHTML
But if you start inkscape from your home directory on the command line, or
from just running it via a menu entry, and then load and save a file in
another location, the PNG slices will end up in your home directory (at least
on unix; windows might save then in C: or "C:\Program Files\Inkscape", or
something like that.
At the moment, there's nothing I can do about that, since inkscape doesn't CD
to the output directory before calling the extension, and doesn't seem to
provide the extension with any idea of where it is actually saving stuff.
Personally, I'd like to see that issue fixed for 0.43.
But either way, it'll be good to hear if this works for others, if there are
any bugs, etc. So please give it a test, and let me know :)
Save both attached files in your inkscape extensions directory. If that
directory is somewhere other than /usr/share/inkscape/extensions, then you'll
need to edit the paths in svgslice.inx to reflect that.
Obviously, this will have a different path on Windows. Maybe someone could
edit the svgslice.inx file, and post it here for other windows users?
* Draw something.
* Create a layer called "slices".
* Draw rectangles in this layer representing the areas you want to slice
(note: it helps if you make the rectangles semi-transparent)
* Optionally, name any/all slices by using the built-in XML editor to edit the
"id" attributes of the rectangles.
* Hide the slices layer.
* Choose "Save as..." from the File menu.
* Select "XHTML file with PNG slices" as the file type to use.
* Enter a filename (e.g., "test.xhtml"), and save.
* You should have the test.xhtml file on your disk, alongside the PNG slices
for each area of the drawing that you made a rectangle for.
Follow up with Nuno Pinheiro:
> Im using 0.42, but i did not figured the correct way to use the
> swatches, i can see them, but i cant "paste" a color in a gradient,
> and also i don't know how to make a swatch, (but i can obviously
> learn), and the feature im requesting is also useful for a lot of
> other things, (such as creating a perfect gradient from one solid
> object to an other solid object, setind qa color for an outline and
Hey all, I'm releasing version 0.4 of the Clip Art Browser. This, of course,
is the release of the browser thats meant to be the final product for the
purposes of Google's Summer of Code. Grab it from
Hopefully, installation is even simpler now. The indexing process for local
clip art, which could be a bit confusing, has been integrated into the GUI,
so that now, you really only have to extract and run. The README has been
updated, but if you have trouble getting it to work, let me know.
Ironically, the one feature that no longer works is, uh, working as an
Inkscape extension. That should be very simple to do... it just need to
figure out how to have the executable that Inkscape calls launch the browser
as a separate process, but this has been surprisingly tricky in python. If
people would like to put this in 0.43, I can get this fixed tonight if
needed, but I assumed that it probbaly wouldn't be. I also figured that the
effects menu isn't really the appropriate place for something like this, and
we'd have to semi-hardcode it into some other menu later anyway (I think Jon
mentioned something about this earlier).
This isn't a final product, of course. I look forward to continuing to
improve it, and hopefully getting more into the code of Inkscape proper over
the coming months. Thanks to all the developers who provided feedback, and
Bryce and Jon in particular. Also, java sucks.
Some places in inkscape use inkscape:connector-avoid
(attributes-test.cpp, and the spelling of SP_ATTR_CONNECTOR_AVOID),
and some places use inkscape:avoid (sp_object_read_attr and
I think I prefer inkscape:connector-avoid.
Or is it intended for the same attribute to be used for removing
node-node overlaps? (Whether as a once-off operation, e.g. using Tim
Dwyer's implementation, or the dynamic linear approximation stuff that
njh & I did for UIST last year.) If so, then I'd go for inkscape:avoid,
and change the enum to SP_ATTR_INKSCAPE_AVOID.
A small bug exists in the code of the file: libavoid/timer.cpp
After running the code on an AMD64 system:
Error: clock_t is not 4 bytes
This snippet has a bug:
if (sizeof(clock_t) != 4)
fprintf(stderr, "Error: clock_t is not 4 bytes\n");
Its always a good idea to never compare a size_of with a constant (unless in
things like configure scripts or with very lowlevel program code). I havnt
read the rest of the file yet (so I dont know why you insist on having it 4
bytes), but it is obvious that such structures have different sizes on
If necessary, hop me an email and we can work this problem out via IRC (if you
have not an 64-bit system available).
Edwin de Jong
Last month we talked a bit about accelerating our releases a bit. Since
it's been a tad over a month since the 0.42 release, and feels like now
would be a good point to begin the 0.43 release process. Based on prior
releases I expect it may take several weeks to a month to go through
this release process.
I'd like to propose that we target Sept 1st as our feature freeze point.
Does anyone feel strongly that we should wait longer than this?
Are ther any Inkscape or OCAL hackers interested in participating and/or
presenting at the GNOME Summit in Boston Sat. Oct. 8 - Mon. Oct 10?
I don't think I can make this one, but it would be great if someone
could go to this conf. and meet up with folks to discuss various
endeavours. Trust me, this type of event is time well spent!
If anyone would like help with an abstract, slides, or needs some
encouragement, hit me up.
San Francisco, CA
USA PH 510.499.0894
MSN, AIM, Yahoo Chat: kidproto
Jabber Chat: rejon@...896...
Open Clip Art Library (www.openclipart.org)