- Inkscape Devel - Inkscape Mailman

icon duplicates
by bulia byak 29 Jun '05

29 Jun '05

Some time ago I reported (and fixed) a duplication of strings in the unused code in src/ui. Now I discovered that the icons are also duplicated: in share/icons, alongside icons.svg, each icon is also in its own file. Bryce, can you please remove those duplicated icons because: - I'm in principle against tearing icons.svg into pieces, as I explained some time ago in a discussion here. This will slow down program loading (parsing lots of small files is much slower than parsing a single big file) and make editing less convenient. Another reason is that the separate SVGs will be significantly larger in the total filesize than the single file (and thus even slower to load) because in the single file, many icons with repeating elements use clones which save a lot of space and work faster. With separate files this is impossible. - People are already, and will be in the future, terribly confused as to which file is the real source for an icon. - The duplicate icons are already getting out of sync because icons.svg is updated from time to time. It would be nice to have this fixed before the release. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 1

A possible error in livarot\MyMath.h
by Alex S 29 Jun '05

29 Jun '05

I am new to InkScape, but from what I remember from math lessons the dot product and the cross product as defined in the file have been confused. Dot is defined to be x*x + y*y, but in this file the author defined cross to be x*x + y*y. And also cross should be x*y - y*x, but the author defined Dot to be x*y - y*x. Thanks, Alex.

2 1

Requesting Inkboard testing
by David Yip 29 Jun '05

29 Jun '05

Hi all, Before I begin integrating Inkboard's code into Inkscape, I'd like to verify the presence of a few large bugs that I've found in the Inkboard code. As bugs can sometimes manifest themselves differently (or not at all!) on different platforms, I'd appreciate large-scale testing of this software. Quick rundown of the project: The Inkboard project's aim was to develop code that would add virtual whiteboarding capabilities to Inkscape, using the Jabber messaging protocol as its communication infrastructure. Its source code is available at <http://sourceforge.net/projects/inkboard>; documentation is available at <http://inkboard.sourceforge.net>. The latest CVS is identical to the v0.25 release, as far as I can tell by looking through diffs. Compilation: I believe the only additional library required is loudmouth <http://developer.imendio.com/wiki/Loudmouth>. I am using version 0.17.2-r2; I do not know if version 0.90 will work, but I'd love to hear if it does. Basic operation: Two instances of Inkboard must be started. Both clients connect to a Jabber server using the File > Connect to Server option. Then an invitation is extended from one client to the other using the File > Share with User option. (The invitation is automatically accepted by the other peer; this will be changed in the integration process.) Upon acceptance, the two Inkscape canvases will be synchronized. Bugs: Here's the five biggest bugs I've found. The "server peer" and "client peer" as written below are as follows: Let A select "Share with User", and let A also enter B's Jabber ID as the user to share to. Then B is the server and A is the client. (It seems backwards, but it's the only way I've managed to get it to work.) 1) Usage of the text tool crashes Inkboard while in a whiteboard session. 2) Anything except solid fills/strokes either crash the server side or are not transmitted properly except on initial whiteboard synchronization. 3) Deletion is extremely finicky -- missing child nodes in the document tree are a common problem, causing assertion failures in the document tree manipulator. 4) The server peer is the only peer whose updates are committed; updates made by the client peer are ignored. 5) Changes to some properties of objects (e.g. number of star points, number of spiral revolutions) are not transmitted immediately like all other changes. My platform: I'm running Gentoo Linux 2005.0, x86 version. Library versions are as follows: libxml2 v2.6.17 gtkmm v2.4.11 glibmm v2.4.7-r1 (-r1 is a Gentoo thing) glib v2.6.3 gtk+ v2.6.7 libsigc++ v2.0.11 boehm-gc v6.4 loudmouth v0.17.2-r2 (ditto on -r2) I am running jabberd v1.4 internally on a machine running Gentoo Linux 2005.0, amd64 edition. The only configuration change I have made on the Jabber server is disabling rate-limiting for faster updates. I am compiling Inkboard using gcc 3.3.5-20050130 in a distcc setup with the P4 and the AMD64 machine. More information can be found in the attached file. I'd appreciate any testing and feedback you guys (and girls!) can give me. The more information, the better :) Thanks, -- David

6 11

Where's 0.42 at?
by Jon Phillips 29 Jun '05

29 Jun '05

Hey, where is the 0.42 release at? I haven't heard much about lately on the list and am curious. Seems like a cap just needs to be put on it to get it out to the masses...they are hungry... I haven't been keeping up so well with Inkscape development, but still seems like a refresher of what is happening is needed. Jon -- Jon Phillips USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

3 2

Re: [Inkscape-user] Drop Shadows
by Ted Gould 29 Jun '05

29 Jun '05

aaron@...749... wrote: > Ted Gould wrote: >> The two inx files that are in the share/extensions aren't actually >> installed, they are just in CVS. So if you make a tarball, they won't >> be in it. I left them there because, well, CVS sucks at deleting >> files. Hopefully SF.net will upgrade to Subversion so that we can >> delete them and still get them back in a more reasonable fashion. > > Actually they are installed with the Win32 builds. But if someone would > like to tell me how to fix that, I would love to have a go at it. I'm not really sure how the Windows builds work... can someone on -devel help Aaron here? Thanks, Ted

1 0

Summer of Code Participants Chosen
by Bryce Harrington 28 Jun '05

28 Jun '05

Hi all, Google has made the final selections for their Summer of Code and sent out the notifications. The following four applications were selected for Inkscape: Topic Applicant ------------------------------------------- Connectors - Michael Wybrow Inkboard - David Yip OCAL Interface - Greg Steffensen DXF Import/Export - Matthew Squires Of course, I was really hoping we could have a few more, because there were several other extremely good proposals for Connectors, Cairoification, libpdf from Scribus, a Genetics Algorithm based tracer, and much more. You can imagine how much discussion and debate that the reviewers have had this past week; it's been a very tough decision process. However, these four projects will provide Inkscape with some new strengths and new capabilities for our users. The prioritization process that the reviewers used in evaluating the applications weighed a number of factors to reach their decisions, including: The quality of the application, the background of the applicant and their familiarity with the subject matter, the importance of the feature to Inkscape, whether the effort would result in something of tangible benefit in the time available, and whether we felt the applicant had a strong likelihood of completing the effort successfully. Regarding mentors, we've not yet finalized on who will mentor which efforts, but there are several developers who have expressed interest in mentoring or whom I think would make good fits to the topics. Simarilius and I will be contacting these people over the next day or two and finalize the arrangements. In the meantime, Sim and I can field questions. Greg, Michael, David, and Matthew, I would also like to encourage you to post your proposals publically for the rest of the Inkscape community to see; they're quite good. :-) You're welcome to use the Inkscape wiki if you do not have a website of your own. In any case, please post your links on this page: http://www.inkscape.org/cgi-bin/wiki.pl?Googles_Summer_Of_Code If you're interested, a few folks are setting up software for you to use for blogging about your work as well. Also, if you're not already, please join the inkscape-devel@ list; we use that list for darn near all our technical discussion. Thanks, and welcome aboard! Bryce

7 9

Re: [Inkscape-devel] Re: Summer of Code Participants Chosen
by Aaron and Sarah Spike 28 Jun '05

28 Jun '05

Greg Steffensen wrote: > "The procedure entry point g_assert_warning could not be located in the > dynamic link library libglib-2.0-0.dll" > > which sounds like a gtk bug to me, though I can't be sure. Is this what > you were getting? No, at first I was getting a message about libglade. But then I did the ultimate evil (copying DLLs around). No I get an error that says: This application has failed to start because libxml2.dll was not found. Re-installing the application may fix this problem. Could you give me a link to the pygtk package you are using? Aaron Spike

3 4

Cut-off status bar text; solutions?
by Colin Marquardt 28 Jun '05

28 Jun '05

Hi, depending on your font and language settings, the current status bar sometimes has a problem of not showing completely. I especially notice this when I work on the German translation since German is more verbose than English. During the course of some discussions on Jabber/IRC, we come up with some ideas. One thing is what I'd call a "split" status bar: the primary text is in a normal font, and the secondary text is in a smaller font and typeset in two lines, like here: http://buug.de/~colin/inkscape_statusbar.png This is just a proof-of-concept (a hbox with two labels in it), and I guess some GTK hackery would be needed to make sure it doesn't expand to, say, 5 lines of text. One would also need to check that R-T-L script still works correctly etc. I can imagine that one thing is distracting: the "border" between the main text and the smaller additional text will move with every new string. cornelius[cz] made a mockup for another idea: a second status bar for the secondary text: http://cornelius.rvge.info/my_files/inkscape_status_mockup.png These two approaches places a rather big burden on the translators, of course, and has quite some impact on the strings in the code, so it is likely not be in 0.42. (Well, the "second status bar" approach would not necessarily need the text broken into primary and secondary text.) A third, "orthogonal" idea was to just have a tooltip for the status bar with the complete text. This would work for the current status bar as well as for any of the ideas presented above. Oh, and cornelius even has a fourth idea, see here: http://cornelius.rvge.info/my_files/inkscape_status_mockup2.png Comments welcome. Cheers, Colin -- Pluto Neptune Uranus Saturn Jupiter Mars Earth Venus Mercury Sun . o o o O . . . . /\ ^ \/ -- You are here

6 7

Font Size
by Ted Gould 27 Jun '05

27 Jun '05

After a little investigation yesterday, I think that the style test is failing when trying to set "font-size" to "0". I think that after it goes through all the style code it comes out as "0px". Is this correct? Is this a problem with the test? --Ted

2 2

Re: [Inkscape-tracker] [ inkscape-Bugs-1116480 ] eat memory with patterns
by MenTaLguY 27 Jun '05

27 Jun '05

On Mon, 2005-06-27 at 11:48 +0200, Ralf Stephan wrote: > > (Also the symptoms -- amount of leakage being related to > > screen area -- are consistent with leaking bitmap memory, > > which we never allocate with the collector.) > > As said before, 20% is here: The question is, why isn't that 20% being collected? The most obvious thing would be that, since the XML nodes are also refcounted (via Inkscape::GC::Anchored), that there is either: 1) improper refcounting by SPObjects which reference the XML nodes 2) SPObjects being leaked while they still reference XML nodes Either one would result in pinning the XML nodes so they could not be collected by the collector. There are also other, more esoteric possibilities (but those wouldn't generally be so consistent). If it were #1, you could expect to see most (rather than a smaller percentage) of the leaked memory coming from the GC heap. Since we are seeing a lot of leaked memory from conventional malloc(), that tends to suggest that garbage-collected memory is being pinned by references from the leaked conventional objects -- i.e. scenario #2. -mental

3 2