- Inkscape Devel - Inkscape Mailman

Re: [ inkscape-Patches-1000235 ] Save as Flash (.swf)
by Ted Gould 02 Jul '05

02 Jul '05

Raymond Penners wrote: > > definitly lacking on some ways that your plugin is good, but > we'd like to start using the extension approach in the > future, and spalah can do some things your code can't. > Also, we really don't want to add a dependency on ming. I > realize it is a configure option, but the reality is that no > one compiles from source. If we don't make it the default, > no one will ever see the code. It's the sad reality of open > source today. > > Thanks for your contribution, I hope that you will consider > contributing to Spalah, or to Inkscape in other ways. Sorry > again to take so long to get back to you. > > I am wondering, does this mean that Spalah will be distributed > out-of-the box with Inkscape? If not, then IMHO not having a simple > "Save as .swf" feature in Inkscape would be a real shame. Well, we're still trying to figure all that out. On one hand we really want to reduce the size of Inkscape, make it easier to install and faster to load. Which means that we want to make as much external as possible. On the other hand, most people aren't of the mindset to install lots of different packages. On Linux this is pretty easy, most distributions have reasonable package management. On Windows, it is much less so. But it still leaves the issue: how do users know where to go to get these features? We need some way to advertise them also. I realize that wasn't much of an answer to your question, but that is more because we don't quite have one yet. It's quite a thorny issue. --Ted

3 2

LJ Editor's Choice 2005
by unknown＠example.com 02 Jul '05

02 Jul '05

I just flipped to page 82 of the August 2005 issue of Linux Journal. Congratulations to all you devs for the Editor's Choice Award for Graphics Software. Aaron Spike

5 4

object.cpp build failure on Solaris
by Christopher Wiedel 02 Jul '05

02 Jul '05

I've been trying to build Inkscape 0.41 on sparc-sun-solaris2.8, and have run into a bit of a problem. It configures fine, and when I start 'make' it initially goes well, occasionally popping out warnings like: node-context.cpp: In function `void nodepath_event_attr_changed(SPRepr*, const gchar*, const gchar*, const gchar*, bool, void*)': node-context.cpp:313: warning: cast from `GTypeInstance*' to `SPItem*' increases required alignment of target type node-context.cpp:322: warning: cast from `GTypeInstance*' to `SPItem*' increases required alignment of target type However, it blows up when it hits src/object-edit.cpp. Or more accurately, something inside it. It throws out a great many of the same type of warnings as the ones above. This doesn't appear to be the problem, since other files had the same warnings, but were able to compile. It winds up with this: object-edit.cpp: In function `void sp_offset_offset_set(SPItem*, const NR::Point&, const NR::Point&, unsigned int)': object-edit.cpp:897: warning: cast from `GTypeInstance*' to `SPOffset*' increases required alignment of target type object-edit.cpp: In function `NR::Point sp_offset_offset_get(SPItem*)': object-edit.cpp:909: warning: cast from `GTypeInstance*' to `SPOffset*' increases required alignment of target type make[2]: *** [object-edit.o] Error 1 make[2]: Leaving directory `/usr/foo/inkscape/0.41/inkscape-0.41/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/foo/inkscape/0.41/inkscape-0.41' make: *** [all] Error 2 This is using gcc 3.3.2. It doesn't appear to have any actual error message that I can find. I would appreciate any pointers. Thanks. -- Christopher Wiedel

2 1

Fwd: Re: [Inkscape-devel] Inkboard CVS updates
by David Yip 01 Jul '05

01 Jul '05

On Friday 01 July 2005 01:04 pm, mental@...3... wrote: > I suspect the element and its sodipodi:type attribute might be > getting transmitted separately. > > i.e. the remote client ends up getting a bare <svg:path>, and > immediately creates an SPPath object. The sodipodi:type attribute > which would have instructed it to create an SPEllipse or whatever > might not arrive until it's too late. Actually, it seems like that's exactly what's going on, judging from the way Inkboard processes messages: the new object message arrives, so Inkboard creates a new object. However, only _then_ does it actually parse the type attribute and set it. I'm reworking received_new_object_helper to extract and set the type attribute before it creates the new object. Hopefully, this'll fix the problem. -- David

1 0

Inkboard CVS updates
by David Yip 01 Jul '05

01 Jul '05

I have committed a number of fixes to the Inkboard CVS <http://sourceforge.net/projects/inkboard> that address crashes related to buffer overflows. Instructions for building and running Inkboard can be found in my request for Inkboard testers that was posted to this list. Inkboard should now be much more stable than it previously was, sans conditions like invalid Jabber usernames or passwords. (I haven't gotten around to debugging those yet; I've been chasing down another bug, which is described below.) In a session between two peers Alice and Bob, if Alice sends a star, spiral, or ellipse, it will show up correctly on Bob's canvas, and (almost) any manipulations that Alice makes will be correctly replicated on Bob's canvas. However, if Bob manipulates the star, spiral, or ellipse in any way, the changes will not be correctly replicated on Alice's canvas. Additionally, Bob will not see the object as a star, spiral, or ellipse -- he will only see it as a path. I think these two problems are related, and since I'm not sure where to start with addressing the first problem, I've been focusing on the second, in the hope that it will cure the first :) I don't think this is a case of missing information: if Bob saves the document, exits, and then reopens it, any star, spiral, or ellipse will be correctly recognized as such, and not just a path. I think there's just something that Inkboard is just not triggering correctly. If anyone has any ideas on where to look or what to look for, I'd greatly appreciate them. Another, smaller bug: gradient editing is not replicated properly. Pressing "add" will replicate the changes, but the gradient objects themselves fall out of sync. Finally, just some thoughts about the near-future integration with Inkscape: Ideally, I'd like to begin merging Inkscape with Inkboard only when all of the bugs have been ironed out of the Inkboard code. That's rather unrealistic, though, especially since the act of merging may expose new bugs anyway! :) So it may be a good idea to create a new branch in the Inkscape codebase specifically for integration with Inkboard, and then merge branches when an acceptable level of robustness is achieved. -- David

3 3

object-edit.cpp:842: error: `isfinite' undeclared in namespace `std'
by Jeremy C. Reed 01 Jul '05

01 Jul '05

Building inkscape-0.41 on NetBSD 1.6.2_STABLE with GCC 3.3.3. I receive this error: if c++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/pkg/include/freetype2 -I/usr/pkg/include -I/usr/pkg/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -DPOTRACE=\"potrace\" -I/usr/pkg/include/gtk-2.0 -I/usr/pkg/lib/gtk-2.0/include -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/atk-1.0 -I/usr/pkg/include/pango-1.0 -I/usr/X11R6/include/freetype2 -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/libxml2 -I/usr/pkg/include/sigc++-2.0 -I/usr/pkg/lib/sigc++-2.0/include -I/usr/pkg/include/gtkmm-2.4 -I/usr/pkg/lib/gtkmm-2.4/include -I/usr/pkg/include/glibmm-2.4 -I/usr/pkg/lib/glibmm-2.4/include -I/usr/pkg/include/gdkmm-2.4 -I/usr/pkg/lib/gdkmm-2.4/include -I/usr/pkg/include/pangomm-1.4 -I/usr/pkg/include/atkmm-1.6 -I/usr/pkg/include/gtkspell-2.0 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -O2 -s -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -MT object-edit.o -MD -MP -MF ".deps/object-edit.Tpo" -c -o object-edit.o object-edit.cpp; \ then mv -f ".deps/object-edit.Tpo" ".deps/object-edit.Po"; else rm -f ".deps/object-edit.Tpo"; exit 1; fi object-edit.cpp: In function `void sp_spiral_outer_set(SPItem*, const NR::Point&, const NR::Point&, unsigned int)': object-edit.cpp:842: error: `isfinite' undeclared in namespace `std' gmake[2]: *** [object-edit.o] Error 1 Any ideas? (Please carbon-copy me on replies.) Jeremy C. Reed BSD News, BSD tutorials, BSD links http://www.bsdnewsletter.com/

3 2

current cvs - problems compiling win32
by Adib Taraben 01 Jul '05

01 Jul '05

Hello, I checked out a fresh copy from the cvs. This does not compile with mingw because a used define is commented out in the makefile. See below. I also compiled a win32 installer for the 0.42pre0. This is 18meg, where should I put this? My webspace on geocities is only 10meg. Ciao, Adib. --- cvs diff -u3 -- Makefile.mingw.common (in directory D:\projekte\inkscape\) Index: Makefile.mingw.common =================================================================== RCS file: /cvsroot/inkscape/inkscape/Makefile.mingw.common,v retrieving revision 1.52 diff -u -3 -r1.52 Makefile.mingw.common --- Makefile.mingw.common 29 Jun 2005 07:07:29 -0000 1.52 +++ Makefile.mingw.common 30 Jun 2005 16:31:54 -0000 @@ -111,7 +111,7 @@ MSGFMT = $(GTKDOS)$(S)bin$(S)msgfmt ####### change me!! -DTG := 20050626 +DTG := 20050630 endif ########################################################################## @@ -120,10 +120,10 @@ ###### VERSION NUMBER -VERSION_NR = 0.41+devel +VERSION_NR = 0.42pre0 # VERSION_NR = 0.42+cvs -# VERSION = \"$(VERSION_NR)-${DTG}\" +VERSION = \"$(VERSION_NR)-${DTG}\" ####### the XP_WIN def is necessary for libjs.a CFLAGS = -O3 -Wall -mms-bitfields -DVERSION=$(VERSION) \ ***** CVS exited normally with code 1 *****

5 7

terminology proposal
by Jakub Steiner 01 Jul '05

01 Jul '05

Hi folks, Until yesterday I haven't had a chance to play with what you call effects. Because I believe this is a misleading terminology I want to propose an alternative: Scripts ------- Scripts are little programs, written in interpreted language, that supply extended Inkscape functionality. They can work on objects, or even drav new objects on the canvas. Both Blender and GIMP projects eventually came to a conclusion that it makes no sense to separate scripts form the core functionality in terms of interface. A script should be free to register anywhere in the menus, based on its functionality. Grouping them, creating yet another menu structure, just because they are written in a particular language is not helpful to the user. Yes, it is pretty much what you call effects now. Filters ------- Filters are operations on selected objects, on their bitmap renderings even. The result of the filter replaces the original object and cannot be easily changed in future. The resulting image is stored in the file upon save. Effects ------- Effects are similar to filters, yet they are "dynamically" applied on a bitmap copy of the object at the target resolution. Only effect settings are stored in the file on save, and the effect needs to be recalculated (possibly some caching/preview voodoo needs to be applied to speed up preview). cheers -- Jakub Steiner <jimmac@...659...> Novell, Inc.

11 17

Re: [Inkscape-user] center alignment about guidelines
by MenTaLguY 01 Jul '05

01 Jul '05

Incidentally, do you know what would be required to increase the default snap distance? It's currently quite small. -mental

3 2

guide lines: desktop vs document coordinate system
by Peter Moulder 30 Jun '05

30 Jun '05

Someone has bug #1222819: “guides have different orgin than objects”: horizontal guideline positions are currently stored as distance up from the bottom of the document (i.e. desktop coordinate system), whereas shape positions’ y coordinates are represented as distance from the top of the document. The result is that if you snap a shape’s position to a horizontal guideline and then resize the document (File>Document preferences, Custom page size, then change the page height), then the shape and the guideline will no longer appear to be at the same position. In my local copy I've mostly fixed this so that the guideline's position from the top of the document is preserved (as for shapes) rather than from the bottom. However, this does raise a user interface issue of how to report to the user what the guide line's position is: /* * For dialog boxes and status bar, should we report positions in the * document coordinate system or in the desktop coordinate system? * * The argument for reporting document coordinate system is that this is * the one that we honour when the document is resized, so in some sense * it is the true (or at least robust) position of the guide. OTOH, * resizing a document is rare. * * The argument for reporting desktop coordinate system is that this is * what's used by the rulers and "current position" indication. This is * the coordinate system that we usually report to users, so is less * confusing to users. * * ... * * (Hopefully, future versions of inkscape will get rid of the separate * desktop coordinate system, to remove this problem.) */ Comments? pjrm. -- bbyak: swatches, rich text, gradient on canvas... JonCruz: The answer to the ultimate question of life, the universe, and everything... JonCruz: Inkscape 0.42!!!!!!!

1 0