- Inkscape Devel - Inkscape Mailman

Win32 inkview in 0.43 release ?
by Adib Taraben 06 Sep '05

06 Sep '05

Hi, inkview compiles fine under Win32. At least it was not part of the distributions. As is has been ask already do want to ship inkview in the next release ? The changes in the makefile are minimal. Adib.

1 0

gtkmm .exe and Windows
by Hal Lorenz 05 Sep '05

05 Sep '05

Hi there, While not a strictly Inkscape-related question, Inkscape is one of the best gtkmm/c++ apps around (or at least I hope, as I noticed you started with gtk/c), so I thought you might be able to help. I'm experimenting with gtkmm and have the simplest program as outlined in the docs compiled as a Windows .exe, here's the code: #include <gtkmm.h> int main(int argc, char* argv[]) { Gtk::Main kit(argc, argv); Gtk::Window window; Gtk::Main::run(window); return 0; } My problem is that the resulting .exe opens the console Window along with the GUI, Inkscape doesn't do this, and I wondered how you achieved that. I know this list isn't for general Q&A, but if you have the time that'd be great, if not no worries. Kind regards, Hal

3 2

Wrong Color ...
by Florian 05 Sep '05

05 Sep '05

Maybe i found a bug? Here is my SVG-File http://mindb.de/t/schatten-r.svg But if i render it as png i get this result: http://mindb.de/t/schatten.png As you can see (http://mindb.de/t/zoom.png) the bottom-shadow is darker thant the upper-shadow (and the right one darker than the left. Is this a bug?

3 2

gtkmm .exe and Windows solved
by Hal Lorenz 05 Sep '05

05 Sep '05

Well it does seem I have a knack for asking obsolete questions, although I really was stuck with this problem and Google wasn't helping, it seems a fresh pair of eyes did the trick. The problem was that it was running in the console subsystem, as opposed to the GUI windows subsystem. Solved simply by adding the flag -mwindows to g++. Thanks for Inkscape anyway. ;) Kind regards, Hal

1 0

Re: [Inkscape-devel] commit warning
by Kees Cook 05 Sep '05

05 Sep '05

On Sun, Sep 04, 2005 at 05:03:56PM +0200, Ralf Stephan wrote: > for this reorganization. However, some issues are unresolved at the > moment, and I'll pursue them ASAP: > - slideshow is probably broken > in spite of five days of testing, so don't hesitate to report. I suspect that "slideshow" being broken probably means that the About box is dead too. Is that right? I get the following crash when opening the Help->About box now: (inkscape:17201): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GObject' (inkscape:17201): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed -- Kees Cook @outflux.net

3 3

SOC Mentors - Review process
by Bryce Harrington 05 Sep '05

05 Sep '05

Ted, Jon, and Peter, Here is what you need to do to complete the Google Summer of Code project. Go to this URL: http://code.google.com/grants/survey-m.html It sounds like they'd like to get these all collected by the 5th. Please let me know when you've filled it out (so we can make sure all the students get accounted for). Thanks, Bryce

4 5

Autorouting Connectors
by Michael Wybrow 04 Sep '05

04 Sep '05

Hello all, The Summer of Code has offically finished up. I've since caught up on some sleep and a few non-SoC things. I've also fixed up the obvious bugs, so this seems like a good time to announce what I actually achieved with the connector tool. Autorouting polyline connectors are in CVS and work well. However you manipulate them, they will avoid objects marked as 'avoided'. Objects can be marked as 'avoided' or 'ignored' via the connector context toolbar buttons. Tricky to explain, but easy to see and understand... just have to play with it. The following wiki page has instructions and further discussion: http://wiki.inkscape.org/cgi-bin/wiki.pl?UsingTheConnectorTool There are a couple of obvious problems: * Connectors are drawn to object's bounding boxes, rather than edges. I have a couple of ideas and some code to address this, so it shouldn't be too long till this is in the codebase. * Bounding boxes are used for the avoidance code, i.e., lines will route around a diamond as if it was a rectagle. The routing code deals with polygons so it's just a matter of me or someone else properly implementing the NR::ConvexHull class. There are plenty of other features I plan to add, some that have been requested by people already. Toolbar marker (arrow head) controls being one of these. See my TODO list on the wiki or in connector-context.cpp. Please have a look at the wiki page, and try out the connectors. Then add to the wiki page with ideas/problems or open bugs/RFEs. I've really enjoyed working on Inkscape the past two months, and as I said in an earlier mail, I feel like this time has got me over the initial hurdle of learning the codebase. I feel much better placed to comfortably contribute in the future. Basically, expect me to become a regular on the mailing list and Jabber. :-) Also, one of the things I've noticed as a result of the Summer of Code time is the real community aspect of the Inkscape project. It's a really open, welcoming community. I'd heard of students working for other projects who really didn't have much contact with their mentoring organisation, and were still waiting for accounts for CVS etc at the end of August. With Inkscape on the other hand, developers and users were always helpful and friendly. Just wanted to thank everyone for that! Cheers, Michael

2 2

Tree changes for DOM stuff
by Bob Jamison 04 Sep '05

04 Sep '05

With the help of Bryce, I am planning on (finally) adding the DOM code to the tree, even though it's not done. This will give people a chance to look at it while it is in progress. Some changes to the tree were necessary: /src/ecma and /src/xpath are gone /src/dom is created /src/extension/script/js is moved to /src/dom I updated the win32 Makedep files, and the win32 build works nicely. It looks like configure.ac has no missing dependencies, so hopefully the unix build won't be broken. If anyone has any problems like this, check out the makefiles listed at the bottom of configure.ac. No, xpath and ecma are not gone. xpath is now part of DOM. Since Swig no longer supports JS, is behooves us to bind JS directly to DOM, hence the move there. Hopefully as we begin hooking things up, we can have some fun with this. Bob

1 0

Gimp Conference 2006
by David Neary 04 Sep '05

04 Sep '05

Eat Frog's Legs and snails in garlic butter! Enjoy the refreshing taste of duck liver! Eat baked pig intestines (a local speciality)! Come to Lyon for the GIMP Conference, 2006! We're in the early stages of the planning - and now's the time to stand up & be counted. The GIMP conference, which may become a more general Free Graphics conference, if other people like the idea, will be held in CPE, Lyon, in March or April 2006. We have 4 possible weekends (Friday/Saturday/Sunday) available. The first is the weekend of St. Paddy's Day (the patron saint of Guinness), and David Odin's birthday - 17/18/19 March. The second is the weekend afterwards, when there's not much on - 24/25/26 March The third is the birthday of Dave Neary (me!), and April Fool's Day (think of the press release possibilities!) - 31 march/1/2 April. The last one - 7/8/9 April. We need to decide when the conference will be on soon, to reserve space in the university, get in contact with youth hostels, figure out what's going to happen, and work up some sponsorship. Once the dates are fixed, I'll send a follow-up announcement (if there are dates that are definitely out for you, let us know now). Everyone's welcome! Spread the word! Bring your dog! (But tie them on a leash outside) Bring your partner! (Lyon's lovely in March) We're looking forward to having you all. Cheers, Dave. -- Dave Neary bolsh@...85... Lyon, France

1 0

commit warning
by Ralf Stephan 04 Sep '05

04 Sep '05

hello, in case you're wondering, my recent commit moved SPDesktop from GObject to C++/sigc++. Fortunately, it was only necessary to touch about 80 files for this reorganization. However, some issues are unresolved at the moment, and I'll pursue them ASAP: - slideshow is probably broken - compiling inkboard was not tested, probably broken A crash on shutdown was removed in the last minute. There might be more, in spite of five days of testing, so don't hesitate to report. Regards, ralf

3 3

Re: Inkscape still does not work on FC
by Artur Rataj 04 Sep '05

04 Sep '05

It's some un-upgradeable FC3 -- yum upgrade shows some missing openssh deps or something -- with glib updated manually to 2.0. With the previous glib, Inkscape would not compile. I'll try to recompile Inkscape on FC4, or replace that distro with another one. Linux linux 2.6.10-1.760_FC3 #1 Wed Feb 2 00:14:23 EST 2005 i686 athlon i386 GNU/Linux The error was: *** glibc detected *** free(): invalid pointer: 0x09fced60 *** Valgrind output: ==19138== Memcheck, a memory error detector. ==19138== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==19138== Using LibVEX rev 1313, a library for dynamic binary translation. ==19138== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==19138== Using valgrind-3.0.0, a dynamic binary instrumentation framework. ==19138== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==19138== For more details, rerun with: -v ==19138== ==19138== Syscall param write(buf) points to uninitialised byte(s) ==19138== at 0x1C110353: __write_nocancel (in /lib/tls/libpthread-2.3.5.so) ==19138== by 0x1C27704F: (within /usr/X11R6/lib/libX11.so.6.2) ==19138== by 0x1C277312: _X11TransWrite (in /usr/X11R6/lib/libX11.so.6.2) ==19138== by 0x1C25B3F2: (within /usr/X11R6/lib/libX11.so.6.2) ==19138== by 0x1C25B47A: _XReply (in /usr/X11R6/lib/libX11.so.6.2) ==19138== by 0x1C2471B7: XInternAtom (in /usr/X11R6/lib/libX11.so.6.2) ==19138== by 0x1C26408C: XSetWMProperties (in /usr/X11R6/lib/libX11.so.6.2) ==19138== by 0x1BF8498D: (within /usr/lib/libgdk-x11-2.0.so.0.400.14) ==19138== by 0x1BF8795E: gdk_window_new (in /usr/lib/libgdk-x11-2.0.so.0.400.14) ==19138== by 0x1BF667CD: gdk_display_open (in /usr/lib/libgdk-x11-2.0.so.0.400.14) ==19138== by 0x1BF473DC: gdk_display_open_default_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.400.14) ==19138== by 0x1BD893FE: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.400.14) ==19138== Address 0x1CBE4288 is 128 bytes inside a block of size 16384 alloc'd ==19138== at 0x1B901B47: calloc (vg_replace_malloc.c:279) ==19138== by 0x1C24B835: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2) ==19138== by 0x1BF666B3: gdk_display_open (in /usr/lib/libgdk-x11-2.0.so.0.400.14) ==19138== by 0x1BF473DC: gdk_display_open_default_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.400.14) ==19138== by 0x1BD893FE: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.400.14) ==19138== by 0x1BD89431: gtk_init (in /usr/lib/libgtk-x11-2.0.so.0.400.14) ==19138== by 0x1BA7A17C: Gtk::Main::init(int*, char***, bool) (main.cc:376) ==19138== by 0x1BA79E57: Gtk::Main::Main(int*, char***, bool) (main.cc:333) ==19138== by 0x8112CA2: sp_main_gui(int, char const**) (main.cpp:514) ==19138== by 0x81D21EB: Inkscape::NSApplication::Application::run() (application.cpp:134) ==19138== by 0x8112966: main (main.cpp:431) ==19138== ==19138== Conditional jump or move depends on uninitialised value(s) ==19138== at 0x1C4B52E5: GC_push_all_eager (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B63EE: GC_push_current_stack (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4BD574: GC_generic_push_regs (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B6532: GC_push_roots (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B40B5: GC_mark_some (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD524: GC_stopped_mark (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD151: GC_try_to_collect_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B6EC9: GC_init_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2964: GC_generic_malloc_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2AC0: GC_generic_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2DB4: GC_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x8359A40: sp_repr_new(char const*) (gc-core.h:72) ==19138== ==19138== Conditional jump or move depends on uninitialised value(s) ==19138== at 0x1C4B52EA: GC_push_all_eager (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B63EE: GC_push_current_stack (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4BD574: GC_generic_push_regs (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B6532: GC_push_roots (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B40B5: GC_mark_some (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD524: GC_stopped_mark (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD151: GC_try_to_collect_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B6EC9: GC_init_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2964: GC_generic_malloc_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2AC0: GC_generic_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2DB4: GC_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x8359A40: sp_repr_new(char const*) (gc-core.h:72) ==19138== ==19138== Conditional jump or move depends on uninitialised value(s) ==19138== at 0x1C4B454E: GC_mark_from (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B41C8: GC_mark_some (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD524: GC_stopped_mark (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD151: GC_try_to_collect_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B6EC9: GC_init_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2964: GC_generic_malloc_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2AC0: GC_generic_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2DB4: GC_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x8359A40: sp_repr_new(char const*) (gc-core.h:72) ==19138== by 0x8356930: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:454) ==19138== by 0x8357D6C: sp_repr_do_read(_xmlDoc*, char const*) (repr-io.cpp:364) ==19138== by 0x8357E0E: sp_repr_read_mem(char const*, int, char const*) (repr-io.cpp:288) ==19138== ==19138== Conditional jump or move depends on uninitialised value(s) ==19138== at 0x1C4B4553: GC_mark_from (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B41C8: GC_mark_some (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD524: GC_stopped_mark (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD151: GC_try_to_collect_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B6EC9: GC_init_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2964: GC_generic_malloc_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2AC0: GC_generic_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2DB4: GC_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x8359A40: sp_repr_new(char const*) (gc-core.h:72) ==19138== by 0x8356930: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:454) ==19138== by 0x8357D6C: sp_repr_do_read(_xmlDoc*, char const*) (repr-io.cpp:364) ==19138== by 0x8357E0E: sp_repr_read_mem(char const*, int, char const*) (repr-io.cpp:288) ==19138== ==19138== Conditional jump or move depends on uninitialised value(s) ==19138== at 0x1C4B4568: GC_mark_from (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B41C8: GC_mark_some (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD524: GC_stopped_mark (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD151: GC_try_to_collect_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B6EC9: GC_init_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2964: GC_generic_malloc_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2AC0: GC_generic_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2DB4: GC_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x8359A40: sp_repr_new(char const*) (gc-core.h:72) ==19138== by 0x8356930: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:454) ==19138== by 0x8357D6C: sp_repr_do_read(_xmlDoc*, char const*) (repr-io.cpp:364) ==19138== by 0x8357E0E: sp_repr_read_mem(char const*, int, char const*) (repr-io.cpp:288) ==19138== ==19138== Conditional jump or move depends on uninitialised value(s) ==19138== at 0x1C4B456D: GC_mark_from (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B41C8: GC_mark_some (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD524: GC_stopped_mark (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD151: GC_try_to_collect_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B6EC9: GC_init_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2964: GC_generic_malloc_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2AC0: GC_generic_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2DB4: GC_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x8359A40: sp_repr_new(char const*) (gc-core.h:72) ==19138== by 0x8356930: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:454) ==19138== by 0x8357D6C: sp_repr_do_read(_xmlDoc*, char const*) (repr-io.cpp:364) ==19138== by 0x8357E0E: sp_repr_read_mem(char const*, int, char const*) (repr-io.cpp:288) ==19138== ==19138== Invalid read of size 4 ==19138== at 0x1C4B4543: GC_mark_from (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B41C8: GC_mark_some (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD524: GC_stopped_mark (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD151: GC_try_to_collect_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B6EC9: GC_init_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2964: GC_generic_malloc_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2AC0: GC_generic_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2DB4: GC_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x8359A40: sp_repr_new(char const*) (gc-core.h:72) ==19138== by 0x8356930: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:454) ==19138== by 0x8357D6C: sp_repr_do_read(_xmlDoc*, char const*) (repr-io.cpp:364) ==19138== by 0x8357E0E: sp_repr_read_mem(char const*, int, char const*) (repr-io.cpp:288) ==19138== Address 0x52C00030 is not stack'd, malloc'd or (recently) free'd ==19138== ==19138== Process terminating with default action of signal 11 (SIGSEGV) ==19138== Bad permissions for mapped region at address 0x52C00030 ==19138== at 0x1C4B4543: GC_mark_from (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B41C8: GC_mark_some (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD524: GC_stopped_mark (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4AD151: GC_try_to_collect_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B6EC9: GC_init_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2964: GC_generic_malloc_inner (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2AC0: GC_generic_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x1C4B2DB4: GC_malloc (in /usr/lib/libgc.so.1.0.2) ==19138== by 0x8359A40: sp_repr_new(char const*) (gc-core.h:72) ==19138== by 0x8356930: sp_repr_svg_read_node(_xmlNode*, char const*, _GHashTable*) (repr-io.cpp:454) ==19138== by 0x8357D6C: sp_repr_do_read(_xmlDoc*, char const*) (repr-io.cpp:364) ==19138== by 0x8357E0E: sp_repr_read_mem(char const*, int, char const*) (repr-io.cpp:288) ==19138== ==19138== ERROR SUMMARY: 552 errors from 8 contexts (suppressed: 140 from 3) ==19138== malloc/free: in use at exit: 300190 bytes in 5874 blocks. ==19138== malloc/free: 7914 allocs, 2040 frees, 603035 bytes allocated. ==19138== For counts of detected errors, rerun with: -v ==19138== searching for pointers to 5874 not-freed blocks. ==19138== checked 2931004 bytes. ==19138== ==19138== LEAK SUMMARY: ==19138== definitely lost: 0 bytes in 0 blocks. ==19138== possibly lost: 7136 bytes in 24 blocks. ==19138== still reachable: 293054 bytes in 5850 blocks. ==19138== suppressed: 0 bytes in 0 blocks. ==19138== Reachable blocks (those to which a pointer was found) are not shown. ==19138== To see them, rerun with: --show-reachable=yes On 8/28/05, Mike Hearn <mike@...869...> wrote: > On Sun, 28 Aug 2005 18:59:38 +0200, Artur Rataj wrote: > > Static binary 42.0 did not work, the latest sources 42.2 compiled but did > > not work. > > Do you mean the same error occurred? What version of Fedora is this and > did you upgrade from an earlier Fedora release? > > If you can run the program in valgrind that'd be good. > > thanks -mike > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

2 1

Interesting OS X tidbits
by Jon A. Cruz 04 Sep '05

04 Sep '05

Here are a few interesting tidbits that came up in the latest mailing I got from the Apple Developer Connection Technical Note TN2137 Building Universal Binaries from "configure"-based Open Source Projects http://developer.apple.com/technotes/tn2005/tn2137.html Adopting Universal Binaries on Mac OS X http://developer.apple.com/macosx/adoptinguniversalbinaries.html Working with Xcode: Building Applications for the Future http://developer.apple.com/tools/xcode/xcodefuture.html

3 2

Exporting (was: Using Inkscape)
by Gavin Band 04 Sep '05

04 Sep '05

Hi Sorry, I split this topic off from the other one about zooming. Bulia Byak wrote: > Choosing export area is also bitmap-only. For vector export, we may > only select which _objects_ to export (though we don't currently have > code for this, always exporting the whole image), but not the export > area. That only makes sense for bitmaps. <snip> I see what you mean, but doesn't it also make sense to be able to export a region of the picture, or the whole picture, or the whole page, to postscript or encapsulated postscript? What if you want to print the bottom half of the picture, or send it somewhere else to be printed? You're right though - the current Export Bitmap pane is very easy to use (I hadn't noticed the selection-tracking behaviour, though on my machine it seems to get stuck on "Custom" and I have to click "Selection" again to make it update). So I suppose I'd like it to a) have a proper file browser (the same as the "Save as..." one) b) have a preview pane like you mentioned c) have a choice of file type. gav.

2 1

CRASH: connector to node tool
by unknown＠example.com 04 Sep '05

04 Sep '05

In the lastest CVS. Create some rectangles. draw a connector between two and immediately switch to the node tool. creates the following output in gdb. Aaron Spike (gdb) run Starting program: /usr/local/inkscape/bin/inkscape [Thread debugging using libthread_db enabled] [New Thread -1222482112 (LWP 12057)] ** ERROR **: file connector-context.cpp: line 247 (void sp_connector_context_dis pose(GObject*)): assertion failed: (cc->newConnRef == NULL) aborting... Program received signal SIGABRT, Aborted. [Switching to Thread -1222482112 (LWP 12057)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7296175 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb72977d8 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xbfffe320 in ?? () #4 0x00000000 in ?? () #5 0x00000020 in ?? () Previous frame inner to this frame (corrupt stack?)

3 2

Inkscape Build Report 20050903-0640
by Bryce Harrington 03 Sep '05

03 Sep '05

Most of the problems from the previous build report were fixed with the inkscape-20050830-1220 snapshot. = Analysis Report for inkscape = Platform Unpack Config Build Install WRNS ERRS ------------------------------------------------------------------------ debian x86 0 0 0 0 5 0 Test Status Score Info ------------------------------------------------------------------------ sut-1 ?? == Errors == none == 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 ==

1 0

Is it allowed to post Atachments?
by Florian 03 Sep '05

03 Sep '05

my first question... or is it better to upload the svg-file to my webspace greetings florian

3 2

Inkscape Project Status Sept 1, 2005
by Bryce Harrington 02 Sep '05

02 Sep '05

Project Status September 1, 2005 Lots has happened over the past month, including a new 0.42 release, completion of the four Google Summer of Code projects, several really useful features including pressure sensitivity, enhanced node editing, and extensions, and some project infrastructure work, such as a new RSS feed at http://inkscape.org/inkscape.rss. We've seen a number of articles and mentions of Inkscape in various magazines and online news sites. We've just initiated a new Inkscape Tester community. This group is being organized to focus on testing of robustness, usability, performance, etc. This is just getting started, so if this sounds interesting its a great time to get involved. There is a mailing list (http://lists.sourceforge.net/lists/listinfo/inkscape-tester) and a wiki page (http://wiki.inkscape.org/cgi-bin/wiki.pl?TestingInkscape) The Inkscape User community is considering starting up a monthly Logo competition, to generate high quality logos for open source projects that need them. If you'd like help with organizing or participating in this, please join us at the inkscape-user list. Tavmjog Bah announced a new, much more complete release of his Inkscape book, covering 90% of the user interface. http://tavmjong.free.fr/INKSCAPE/MANUAL/html/index.php Looking forward over the next month, we're planning on continuing development for a bit longer, then get a 0.43 release pushed out. We're hoping it can be delivered reasonably quickly, but we still have some more features to fold in. It sounds like the concensus is to do 100 points worth of RFE's, followed by 100 points of bug fixes, then a hard freeze, and a release. Statistics Jun 1 Jul 1 Aug 1 Sep 1 ========== ====== ====== ====== ====== Max Week's Rank on SourceForge: 38 35 3 23 Total SF Page Views 1,935,964 3,797,037 4,452,437 4,139,401 Total SF Downloads 254,647 283,789 378,712 448,994 Total Freshmeat URL Hits 19,149 19,809 21,261 22,422 Total Freshmeat Subscriptions 183 189 208 220 Lines of Code in src/: 374,180 376,319 389,945 404,800 Code lines 260,236 261,600 270,423 279,621 Comment line 67,136 67,724 70,478 73,904 Blank 53,443 53,651 55,698 57,937 Lines of Docs in doc/: 27,790 27,792 28,090 28,121 Lines of content in website: 42,490 42,700 44,483 44,732 Size of the Inkscape wiki: 26,729 28,525 34,890 34,847 Bugs open/total: 215/1223 196/1312 215/1445 250/1555 Features open/total: 453/ 728 471/ 767 440/816 466/ 874 Patches open/total: 11/ 230 10/ 268 8/325 6/ 332 CVS Commits (as per inkscape-cvs) 12,040 12,372 12,915 13,423 Inkscape-devel membership: 179 188 200 217 Inkscape-announce membership: 202 217 236 274 Inkscape-user membership: 248 258 276 295 Num Translations: 33 33 33 33 Ave Translation Ratio: 47.8 48.6 54.6 54.9 * - Statistics unavailable

1 0

Re: [Inkscape-devel] 0.42.2 Announcement
by JAKOB ILVES 02 Sep '05

02 Sep '05

Hello! Any progress on getting the static rpm for inkscape 0.42.2 up on the downloads section? Right now only the static rpm for inskcape 0.42.0 is available, and that is the broken version and I'm looking forward to test the 0.42.2 version. Best regards IlvJa __________________________________________________ >From bulia byak <buliabyak@...400...> Sent Fri 8/26/2005 7:21 AM To Ted Gould <ted@...11...> Cc Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> Subject Re: [Inkscape-devel] 0.42.2 Announcement __________________________________________________ On 8/26/05, Ted Gould <ted@...11... (mailto:ted@...11...)> wrote: > Now that there are binaries for 0.42.2 Still missing are autopackage and static rpm. I think we need at least one of these to make an announcement. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org (http://www.inkscape.org) ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf (http://www.sqe.com/bsce5sf) _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net (mailto:Inkscape-devel@...142...ge.net) https://lists.sourceforge.net/lists/listinfo/inkscape-devel (https://lists.sourceforge.net/lists/listinfo/inkscape-devel)

2 1

dxf dev?
by Jon Phillips 01 Sep '05

01 Sep '05

How is the dxf Summer of Code developing? I haven't heard much about how this is progressing? When is the summer of code up anyhow? Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 jon@...235... http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: rejon@...896... IRC: rejon@...897... Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org)

8 20

Linux Journal
by Carl Hetherington 01 Sep '05

01 Sep '05

Hi all, Sorry if this has already been mentioned, but Inkscape has won the 2005 Linux Journal Editors' Choice award: http://www.linuxjournal.com/article/8293 Well done everybody! Carl

1 0

python for windows
by bulia byak 01 Sep '05

01 Sep '05

I'd like to revisit the issue of shipping Windows package with their own Python/PyXML. By now I use Aaron's python extensions all the time, they are immensely useful. Not as convenient as native solutions would be, but still a lot of fun and an important part of my design work. The current instructions page for Windows: http://wiki.inkscape.org/cgi-bin/wiki.pl?GettingEffectsWorking/Windows is way too scary for an average user. Python alone might be OK, but PyXML on top of that is certainly too much. I think very few dedicated users would venture into this. So, what do you think about including a minimum Python/PyXML into the Windows installer and enabling extensions by default? I think the file size increase won't be intolerably big. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

7 15

Re: [Clipart] Re: [Inkscape-devel] releasing Clip Art Browser 0.4!!
by Nicu Buculei 01 Sep '05

01 Sep '05

Tobias Jakobs wrote: > >>Inkscape and OCAL folk, do you think we should host this as an Inkscape >>project, or an OCAL project, or open up a separate project for this? I'm >>tempted to open a new separate project for this browser, as it is very >>useful to OSS in general, yet, if we move the codebase too far away, >>will the locus of attention be too far outside of our combined >>developers? >> >>** PLEASE give some feedback on what I jus proposed soon!!!! ** >> > > > I would say, its more OCAL than Inkscape related and I would like to see > it in AbiWord, Gnumerik, Gimp, ... integrated too. It would be nice to have it in all those apps, but we also need it on all platforms where Inkscape run, so we can close RFEs like this (for an object palette): https://sourceforge.net/tracker/?func=detail&atid=604309&aid=1262745&group_… -- nicu

1 0

Re: [Inkscape-devel] CVS for dxf import
by Matt Squires 31 Aug '05

31 Aug '05

---------------------------- Original Message ---------------------------- Subject: Re: [Inkscape-devel] CVS for dxf import From: "Matt Squires" <matthew.squires@...854...> Date: Wed, August 31, 2005 3:16 pm To: "John Taber" <jtaber@...480...> -------------------------------------------------------------------------- The readme has links to the dxf files that I have been using. I have a copy of AutoCAD at school, and use CadStd Lite at home. But CadStd lite doesn't implement many features for that reason I am using the files that I know exist and those are at Thorlabs and Newfocus. here are the links to the two images on the web site. The first has two elements that import incorrecty on the left hand side. I will try to get to that in the next few days. http://newfocus.com/images/mechanicaldrawings/edxf/9807e.dxf http://newfocus.com/images/mechanicaldrawings/edxf/9051e.dxf Thorlabs uses solid and trace a lot for their drawings. I haven't supported those yet, so the drawings look a little funny. I currently don't support dimensions so that also looks funny. AutoCAD sometimes complains that their dxf is bad. http://www.thorlabs.com/thorcat/1700/1708-E0W.dxf http://www.thorlabs.com/thorcat/8500/8577-E0W.dxf Later tonight I will put all the sample files that I used for initial work in the dxf2svg folder, and will build a test file with AutoCAD that will have most of the commonly used elements in dxf. I have other comments...see notes below > Later - You should first post the examples that you have tested with, so far we have seen none, just an assurance or screenshot that it all works - it is or should be your job to show the code works before we spend our time checking it, you're the one being sponsored . And besides, you I have tested with files of my own creation and from two separate commercial companies. I also used the demo file from QCad, and it imported great. I used commercial CAD drawing to get real drawings that are used in the real world. I don't spend all my time looking for new test files. I have 6-10 files from 4 different sources. Call it 15 files and 5 sources if you count the files from Eric. I have spent my time trying to get the features to work in the files. > know it is pretty basic PhD 101 to show(prove) that your methodology works. You should be treating this the same as any other research project. In all research projects I have been involved in it is only the most proprietary researchers that withhold information from others. My research group directly competes with a group in Germany, but I have never had a question not answered or information withheld from them, even for the stupid questions. > > Matt Squires wrote: >> I just did a test using dxf versions R12, 2000, and 2004 and it loaded with out hanging. It used circles, plines with arcs, arcs, lines, and text. It was created using AutoCAD 2004. >> >> If you can be more specific as to what was in the file I will try to fix the problem. Most of the segfaults in the code from last Saturday came from blank lines in the dxf files, that has been completely fixed. I assume you are refering to the file Eric tested. Did you also have a file >> that segfaulted? If so, please send it to me. I can handle large attachments. >> >> Matt >> >> >>>The dxf2svg code still does not work for simple R12 dxf drawings (it goes into an indeterminate loop and every 3 minutes outputs the same "translate..." line) - OpenOffice Draw code handles the same translation perfectly in a microsecond. The first code submission (just last Saturday), completely segfaulted. I don't think we should be the ones having to test for such basic operation. Personally I think this project still needs a lot of work to be finished and useful. >>> >>>Bryce Harrington wrote: >>> >>>>On Tue, Aug 30, 2005 at 10:08:51AM -0600, Matt Squires wrote: >>>> >>>> >>>>>Bryce, >>>>> >>>>>The dxf2svg part is coming along. I have gotten it to work in >>>>> Inkscape >>>>>with an .inx file. I would like to add it to the Inkscape CVS tree under >>>>>share or extensions. Can I get CVS access and some guidence where to put >>>>>code that is not directly part of the Inkscape code base but an extension? >>>>> >>>>>I think there is a simple way to add dxf export using pstoedit. I >>>>> don't >>>>>know if anyone has tried it before, but I was able to do some simple conversions. Again the only change would be .inx files. >>>>> >>>>>My SF id is squires >>>> >>>> >>>>Hi Matt, >>>> >>>>Thanks for posting the request; I've enabled your SF CVS access. >>>> >>>>Bryce >>>> >>>> >>>>------------------------------------------------------- >>>>SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices >>>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA >>>>Security * Process Improvement & Measurement * >>>>http://www.sqe.com/bsce5sf >>>>_______________________________________________ >>>>Inkscape-devel mailing list >>>>Inkscape-devel(a)lists.sourceforge.net >>>>https://lists.sourceforge.net/lists/listinfo/inkscape-devel >>>> >>>> >>> >> >> >> >

1 0

Build report for inkscape-20050830-0240
by Bryce Harrington 31 Aug '05

31 Aug '05

The Inkscape automatic tarball packages have been broken for a few days. It looks like there is some sort of cvs merge issue going on. Could someone check to see if the process that generates the tarballs is working correctly? I'm guessing that cvs got confused and has borked the tarballs up. Here is the latest build report: = Analysis Report for inkscape = Platform Unpack Config Build Install WRNS ERRS ------------------------------------------------------------------------ debian x86 0 0 2 5 28 Test Status Score Info ------------------------------------------------------------------------ sut-1 ?? == 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 == Bryce

1 0

Locale settings on windows
by Jon A. Cruz 31 Aug '05

31 Aug '05

There have been a few issues now and then with gettext and friends on Win32. A few related tracker items are [ 1250581 ] WIN32: Inkscape uses locale settings for determining UI lang [ 1246076 ] Mixed languages in UI [ 1246463 ] Language Selection Option / Menu Entry After talking with Peter some last night, it was bubbling around in my brain, and kicked out a work-around. This will need to be tested/refined, but the basic approach could be to hook into things right at program startup (over in the Win32 bits). At that point we could check if LANG and/or the other POSIX environment variables were set. If not, we could then just query the Win32 NLS calls and then build up and set LANG and LC_* properly. Some preferences could be set to affect this, and perhaps override it with explicit user values/choices. The details need to be hammered out, but I think this is a good work- around to allow us to get a better user experience on Win32 without having to get libc changed, etc. I wanted to toss this out in case others were still pondering things today.

1 0