Press
by unknown＠example.com
All this talk about website redesign and reorganization makes me wonder.
On many commercial websites I see a "For the Press" section. Should
inkscape have one of those?
Also, since the question has come up multiple times can we attach
licensing information to each screenshot on the website. I noticed the
gamemap example does this. Would someone who knows how place a PD
designation next to both of my screenshots?
Aaron Spike
17 years, 6 months
host reorg
by Ralf Stephan
Hello,
a quick glance tells me there is no RFE I as beginner with the code
could possibly implement in short time, so I want to offer my help
in the host reorganisation away from SF. Maybe people can use this
thread also to collect things that have to be done in this regard.
My limitation is that I have no broadband internet, nor a 24h line
at my hands, though. But surely there are other things to do.
I want the switch, badly, and I think it is more important than RFEs.
ralf
PS: no flames or RFE discssions please in this thread
17 years, 6 months
Re: [Inkscape-devel] Getting involved
by Bryce Harrington
On Fri, Aug 26, 2005 at 09:11:54AM +0200, Ralf Stephan wrote:
> You wrote a while ago:
> > ...
> > Next is the main window work. This involves conversion of two code
> > objects: SPView and SPDesktop. Each of those also have a variety of
> > accessory classes to convert as well. This is the area I've been
> > working on, and I'm trying to do it by first refactoring these from C to
> > C++. If anyone's interested in working on this, I can give more details.
>
> Yes, please. I assume ui/view/edit.* is the new class for SPDesktop,
> so I guess what is next is completing Edit according to SPDesktop
> and test it in the --new-gui environment. After that,
That's correct.
However, I found that straight up conversion of SPDesktop to ::Edit to
be difficult; I attempted to do this in one all-at-once conversion but
it quickly unravelled into a mess. I think the best approach is to do
the conversion a piece at a time. Start at an easy point and work your
way in.
The place I found to start was with converting SPView to C++. I've got
this about half done, and it'll be fairly obvious what's left to do.
After that, it may make sense to go ahead and knock out conversion of
the SPViewWidget class next, since that's not too complicated.
Since SPDesktop derives from SPView, having SPView in C++ is the first
step to convert SPDesktop. Next thing would be to start converting
SPDesktop into a C++ class. Next move the file(s) to their proper final
location. Finally rename SPDesktop to Inkscape::UI::View::Edit.
I found for the renaming, that it helped to create a typedef.
Note that there are some forward definitions of the class that get in
the way; I wasn't sure if it was better to remove them or to try to
refactor them. Ultimately, though, at some point you have to just start
going through the whole codebase and rename stuff. That sounds like a
lot of work, but actually for SPView I found I was able to do it over
the course of a long airplane flights. ;-)
> > ...
> > Fourth, there are several main window components such as the statusbar,
> > context menu, and so on that have not received any attention so far. We
> > have the gtk+ code for these items, and they just need to be converted
> > to gtkmm. I suspect the best approach is to refactor them in place.
> > The current statusbar code is pretty good, although it could use a few
> > enhancements. The current context menu is okay but could use a lot more
> > attention to make it more usable.
>
>
> Do I have the order of things right?
> It is likely I will take over single steps of the process *without*
> taking over the whole thing officially, as I like to work on several
> different micro-tasks at the same time, probably going the circle
> documentation->bugfixing->refactoring->doc...
>
> Thus, I will ask you from time to time 'what next?' until I have
> the big picture.
Yes, I think you've got it. The process isn't totally linear; there's
several things that could be worked on independently. Let me know how
your progress goes; I expect to keep plugging away at it too.
Bryce
17 years, 6 months
Re: Inkscape still does not work on FC
by Artur Rataj
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
>
17 years, 6 months
dxf dev?
by Jon Phillips
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)
17 years, 6 months
python for windows
by bulia byak
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
17 years, 6 months
Re: [Inkscape-devel] CVS for dxf import
by Matt Squires
---------------------------- 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
>>>>
>>>>
>>>
>>
>>
>>
>
17 years, 6 months
Build report for inkscape-20050830-0240
by Bryce Harrington
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
17 years, 6 months
Locale settings on windows
by Jon A. Cruz
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.
17 years, 6 months
