- Inkscape Devel - Inkscape Mailman

win32 compile problem
by Adib Taraben 04 Feb '05

04 Feb '05

I get following error in the current CVS: in the current MinGW compiler there is no such io/sys.h file HTH, Adib. dialogs/export.cpp:53:20: io/sys.h: No such file or directory dialogs/export.cpp: In function `void sp_export_export_clicked(GtkButton*, GtkOb ject*)': dialogs/export.cpp:972: error: `file_test' is not a member of `Inkscape::IO' dialogs/export.cpp:974: error: `sanitizeString' is not a member of `Inkscape::IO ' dialogs/export.cpp:1022: error: `sanitizeString' is not a member of `Inkscape::I O' mingw32-make[1]: *** [dialogs/export.o] Error 1 mingw32-make[1]: Leaving directory `E:/projekte/inkscape/src' mingw32-make: *** [all] Error 2

3 3

Object Rotation
by Aaron Spike 04 Feb '05

04 Feb '05

I have a few questions/comments about rotation. First a confession: for the last week I thought the "snap to angle with ctrl" function was broken. It wasn't. I had the snapping set at 2 degrees and the angle indicator in the status bar follows pointer. So I didn't notice that the bbox actually was snapping and I convinced myself it wasn't snapping because of the numbers didn't snap. The point is I'm wrong a lot. But would it make sense if the number in the status bar snapped with ctrl too? Or what if the number followed the object instead of the mouse? Would that make more sense or is the current behavior what one would expect? Second, what would be the pros and cons of allowing a user to choose arbitrary degrees for snapping? I was just working on a pentagonal design. I though "Hey, this will be easy. I'll just set the snapping to 72 degrees. 72 is a nice even number, right." But it wasn't a choice. I suppose you can't have every factor of 360 in the list. In the end I was saved by the tile-clones dialog which doesn't have a list. Aaron Spike

4 3

Status needed for ReleaseNotes
by Bryce Harrington 04 Feb '05

04 Feb '05

One other task needed before we get too much further is to update the Roadmap. Mental, Ted, Ishmal, and others, can you give us some quick status on the following items? [Perl, Python scripting; XSLT] [embed/outbed, gamma scripts] [Effects menu] [extensions warning and logging] [Namespace changes] [Making reprs private] Also, Arpad, can you give us a list of the translations that were updated from 0.40 to 0.41? Thanks, Bryce

9 17

Fwd: [Inkscape-user] Line marker colour
by bulia byak 04 Feb '05

04 Feb '05

forwarding to devel too.. ---------- Forwarded message ---------- From: bulia byak <buliabyak@...400...> Date: Fri, 4 Feb 2005 08:51:14 -0400 Subject: Re: [Inkscape-user] Line marker colour To: inkscape-user(a)lists.sourceforge.net On Fri, 04 Feb 2005 13:45:17 +0100, Arnout Standaert <arnout.standaert@...687...> wrote: > is there any intention of fixing bug #995815 for the 0.41 release? It's > the bug where line markers (for instance, arrowheads) don't follow the > colour of the line they're attached to. Not for 0.41 for sure, it's almost out. In fact it's not really a bug, it's just a limitation of SVG which needs to be worked around. This workaround has to be quite complex, though doable. We just need a coder who would be motivated enough to dive into it. My comments in that bug give a rough plan for attacking it. To All: Note that the people in that bug started offering real monetary awards for whoever will do this first. So, if you want to make some money, here's a good task for you! :)

1 0

embed/outbed, gamma scripts ??
by Bryce Harrington 04 Feb '05

04 Feb '05

What is "embed/outbed" and "gamma scripts" ? I see these mentioned in the release notes, but with no elaboration... This is also the first I've heard of them. Bryce

2 1

locale madness
by Kees Cook 04 Feb '05

04 Feb '05

So, to really confuse things, I decided to go see if The Gimp under windows would blow up the way we are (were). It does not. So I then removed all the .DLL's from my inkscape directory so it would use the install GTK defaults. It worked like a charm. No utf8 errors, nothing. Very interesting. -- Kees Cook @outflux.net

1 0

Info needed from Ishmal for release notes
by Bryce Harrington 04 Feb '05

04 Feb '05

Bob, can you say a few words about the status of scripting and XSLT for us to use in the ReleaseNotes? I.e. what can users make use of, and what level of functionality will be available in this release? Thanks, Bryce

1 0

Re: [Inkscape-devel] Basic tasks ?
by Bryce Harrington 04 Feb '05

04 Feb '05

On Wed, 2 Feb 2005, Ashwin Bharambe wrote: > Hi Bryce, > > > Another area we will need a lot of help in fairly soon is with upgrading > > the UI to gtkmm. This will involve a lot of meat-and-potatos C++ class > > creation and conversion of C code into OOP style. Presently this work > > is going on in a separate cvs module but it's scheduled for integration > > within about a week. If you're interested in working on this, let me > > know and I can give more details. It should be pretty straightforward > > work, and will be seeing progress rapidly, so it could be fun. :-) > > I would be interested in more details for this. Basically, once in a > while, it feels good to do "simple" things and get something useful > done. :) Let me know if and how I could help out here. Great! This work will begin in earnest after we release 0.41, but you can get involved now easily by downloading and tinkering with the inkscape_gtkmm codebase, and/or learning Gtkmm via the www.gtkmm.org site. If you're anxious to work on something with inkscape_gtkmm, and willing to take on a more challenging effort, I posted a few tasks to this list a couple weeks ago, you could look through. For example: http://sourceforge.net/mailarchive/forum.php?thread_id=6260552&forum_id=360… http://sourceforge.net/mailarchive/forum.php?thread_id=6260551&forum_id=360… Those include directions for checking out the code, too. Also, look in the PLAN document within the codebase for some tasks and projects (esp. at the end of the file). > > * Cairo Gtk Canvas - A long term project we have talked about is to > > replace our internal renderer with Cairo, but there's a ton of R&D > > experimentation needed to get there. If you like working from a > > blank sheet of paper and just coming up with a lot of good ideas > > that others can build off of later, this would be a good > > opportunity. > > How would one start here? I briefly tried figuring out how exactly > livarot is used within inkscape at this moment - is there a > well-specified layer here? If you could get me started on a brief > outline of what the goals are, I am willing to spend considerable > amount of time performing experimentation with cairo. This would be great. I think you have already made some progress at this but I can give some additional random info: * Cairo is itself composed of several libraries that each provide different wrappers atop the core. For instance, the SVG bindings are in a library that sits atop the more underlying cairo bits. * We need to understand exactly which cairo pieces are required, how they're packaged, and how we can distribute them to users. For example, what pieces would we need to distribute to Windows users? * There is a GtkCairo lib, that you looked at the other day, but actually we need a full Canvas. What exactly does this mean? How would we go about packaging such a thing? * I believe I saw that there is a Qt Canvas for Cairo. Is there any possibility of sharing code between this and a Gtk Canvas? * What portions of the existing Inkscape codebase would get subsumed into a GtkCairoCanvas object? What would be most appropriate to keep out at a different level? In general, the idea behind creating a gtk cairo canvas would be to enable things like these: * A game developer could use it to render and manipulate the graphical components in their game. * A project aimed at creating a shared whiteboard project could tie a canvas to the Jabber message protocol stream to enable interactive drawing functionality. * A company wishing to provide their customers with an application showing attractive, dynamic graphs and diagrams could use it for drawing this information as it is broadcast to the client app. * An application for viewing/managing rack mounted computer hardware could use it for displaying a top-down view of the data center, which could be interactively clicked on to view front-views of the racks, and with further clicking to see individual hosts in the racks, usage/performance graphs, machine statistics, and wiring diagrams. Of course, in addition, the canvas would provide rich functionality for Inkscape to use it for editing SVG documents. ;-) Bryce

1 0

RE: [Inkscape-devel] Inkboard linking/dependencies
by Montgomery, Steven S 04 Feb '05

04 Feb '05

No, we don't have our code linking normally. Since it was such a brickwall for our progress, we moved the Jabber code into a file we added under dialogs(where it was being called from). Obviously this links, but we definitely would like to separate the code back out how it should be. I've seen some recent posts about automake 1.9 causing problems for some people. Perhaps that is our issue as well? It's not clear to me where our documents would be appropriate in the Inkscape Wiki. However, we do have all of our documents and sourcecode available online. The documentation is at http://inkboard.sourceforge.net and our code is in the Sourceforge CVS(/cvsroot/inkboard/). The Inkboard module is the correct one(we plan to clean up the CVS repository at some point). Steven Montgomery

2 4

RE: [Inkscape-devel] Inkboard linking/dependencies
by Montgomery, Steven S 04 Feb '05

04 Feb '05

Ok, the code DID link fine, but it was because it included the .cpp instead of .h. So, we're still having problems linking. Steven -----Original Message----- From: inkscape-devel-admin(a)lists.sourceforge.net [mailto:inkscape-devel-admin@lists.sourceforge.net] On Behalf Of Montgomery, Steven S Sent: Thursday, February 03, 2005 3:21 PM To: inkscape-devel(a)lists.sourceforge.net Subject: RE: [Inkscape-devel] Inkboard linking/dependencies Actually, I just confirmed that we're running automake 1.7. And it just linked fine a second ago. So, the latest version of code is in the CVS. Steven -----Original Message----- From: inkscape-devel-admin(a)lists.sourceforge.net [mailto:inkscape-devel-admin@lists.sourceforge.net] On Behalf Of Montgomery, Steven S Sent: Thursday, February 03, 2005 2:59 PM To: inkscape-devel(a)lists.sourceforge.net Subject: RE: [Inkscape-devel] Inkboard linking/dependencies No, we don't have our code linking normally. Since it was such a brickwall for our progress, we moved the Jabber code into a file we added under dialogs(where it was being called from). Obviously this links, but we definitely would like to separate the code back out how it should be. I've seen some recent posts about automake 1.9 causing problems for some people. Perhaps that is our issue as well? It's not clear to me where our documents would be appropriate in the Inkscape Wiki. However, we do have all of our documents and sourcecode available online. The documentation is at http://inkboard.sourceforge.net and our code is in the Sourceforge CVS(/cvsroot/inkboard/). The Inkboard module is the correct one(we plan to clean up the CVS repository at some point). Steven Montgomery ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

RE: [Inkscape-devel] Inkboard linking/dependencies
by Montgomery, Steven S 03 Feb '05

03 Feb '05

Actually, I just confirmed that we're running automake 1.7. And it just linked fine a second ago. So, the latest version of code is in the CVS. Steven -----Original Message----- From: inkscape-devel-admin(a)lists.sourceforge.net [mailto:inkscape-devel-admin@lists.sourceforge.net] On Behalf Of Montgomery, Steven S Sent: Thursday, February 03, 2005 2:59 PM To: inkscape-devel(a)lists.sourceforge.net Subject: RE: [Inkscape-devel] Inkboard linking/dependencies No, we don't have our code linking normally. Since it was such a brickwall for our progress, we moved the Jabber code into a file we added under dialogs(where it was being called from). Obviously this links, but we definitely would like to separate the code back out how it should be. I've seen some recent posts about automake 1.9 causing problems for some people. Perhaps that is our issue as well? It's not clear to me where our documents would be appropriate in the Inkscape Wiki. However, we do have all of our documents and sourcecode available online. The documentation is at http://inkboard.sourceforge.net and our code is in the Sourceforge CVS(/cvsroot/inkboard/). The Inkboard module is the correct one(we plan to clean up the CVS repository at some point). Steven Montgomery ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

Need to hunt things down
by Jon A. Cruz 03 Feb '05

03 Feb '05

I'm 'bout off to work, but I remembered something that just needs a little help from extra eyes. One of our problems with reading and writing files with names containing characters outside of the 7-bit ASCII range is with library and/or API calls that take filenames directly. Our uses of fopen have been mainly fixed, as are some of the pass-it-a-filename calls. However... there might be a few places that still pass a filename on directly. Could people take a quick peek to see if we have spots where that happens? For things to work well, we have to do one of two things 1) Convert filenames from UTF-8 to filename encoding before calling 2) open the file and pass the API an open file or a data source (depending on the needs of the API). #1 will work for Linux, but *not* Windows XP and friends, since all characters possible on the filesystem can't be respresented in the current ANSI codepage. If anyone has a chance and can find a few of the lingering places, I can go in more quickly tonight and fix them. Thanks.

1 0

node editing
by Jakub Steiner 03 Feb '05

03 Feb '05

Hi folks, I've already filed a request to be able to edit nodes of multiple objects. The reasoning behind this is that I constantly change shape of a drawing and that mostly consist of multiple overlaid objects so all of those need to be changed (currently one by one). I do, however like the way Inkscape restricts node selection within an object too. So I think the following behaviour would work best -- you could only select from the shown nodes as it is now. But apart from working on a single object, Inkscape would also allow to select multiple objects first, then change to node editing and have nodes from all selected objects selectable. Does that make sense? If we had a nice floating dock of the object tree, an object locking mechanism may be just as effective (lock uninteresting objects first, node select working on all objects). But we don't ;) -- Jakub Steiner <jimmac@...659...>

3 5

status & plans
by bulia byak 03 Feb '05

03 Feb '05

Looks like the drawing tools crash (1107922) is going to be fixed soon. The other crash bug (1113187) seems to be easy, and the svgz loading on windows is a matter of supplying a correct DLL. So, we're close. Once all these are resolved, I think we need to make one prerelease which would be tested for 2-3 days, and then do the final release if nothing critical is found. This time I'd very much like the prerelease to have a Windows binary as well (0.40 prereleases didn't). Will someone be willing to provide it?

4 3

new bugs
by bulia byak 03 Feb '05

03 Feb '05

I consider these two bugs to be MUSTFIX as well: - the one found by Kees (without pref file, objects are drawn black), see my post with more details on why this happens - the new crash on load: http://sourceforge.net/tracker/index.php?func=detail&aid=1113187&group_id=9… The first of these bugs appears mild, but they both are in the new repr code by Mental and therefore may be signs of something more sinister which we haven't found yet. And both are regressions compared to 0.40. Mental, will you please look into them? If you need my help I'll do what I can, though currently I'm swamped by work.

3 4

typos and a translation question
by Arpad Biro 03 Feb '05

03 Feb '05

Hi, A typo in src/extension/extension.cpp: beacuse Double colon in src/extension/dependency.cpp: out_file << _("Dependency::") << std::endl; Also a question: in this piece of code from src/extension/dependency.cpp: gchar const * Dependency::_location_str[] = { N_("path"), N_("extensions"), N_("absolute") does "path" mean "filesystem path" (as opposed to "vector path")? Arpad Biro __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

4 6

Papers on Inkscape
by Bryce Harrington 03 Feb '05

03 Feb '05

Hi all, A week ago we talked about Inkscape technical papers. Several people were interested in writing on particular relevant topics, which is great! I think we should make several attempts, that way if some aren't accepted, we'll have multiple chances. Here's what to do if you're interested: 1. First, read through this email and think about a) what you would like to write on, and b) which conference(s) you'd like to author or co-author a paper for. Reply back here with this info, so co-authors can link up. 2. Next, look at their Call for Papers and see what they require for submitting a proposal (some just need abstracts, others need paper drafts), and when the due date is. Also look through their archives to see examples of types of papers that conference accepts. 3. Make a first stab at a short abstract. It should state in 1-3 paragraphs everything that the paper will discuss. Doesn't have to be perfect. :-) 4. If you want to work on the paper in a version control system, please feel free to create a subdir in the inkscape_project CVS module. It sounds like papers could be written on the following topics. I would be interested in co-authoring on any of these papers. Packaging Inkscape on Linux: Autopackager and Other Options ============================================================ Mike Hearn is interested in a paper that presents Autopackager and tells how it has provided a convenient option for Linux users to try. We can compare and contrast our experiences with it along with other packaging options, including use of (near-)static binaries. There are probably other related issues we could discuss, such as the C++ ABI change that caused problems on gentoo, and maybe our experiences with portability of Gtk apps to Windows and OSX. Quality Control in Open Source Desktop Linux Applications ========================================================= Kees is interested in writing up something related to bug fixing in Inkscape. I think there's a really engaging story in how over the course of a year we went from a codebase plagued with bugs and crashes, we were able to stabilize it and achieve a level where today reviewers remark that they "simply could not get it to crash". :-) Part of the story could explain how we rely on and use the bug tracker to prevent any bug from slipping through the cracks unexamined. Another part I think would be worth describing is how we include the larger community as teammembers in the process. Encouraging users to file bugs, showing them how to use gdb for making back traces, and involving them with validating our patches (perhaps via the nightly snapshots) is something that seems like a really obvious process, but a lot of projects and companies don't know how this works, so our experiences with making it work will be valuable. Drawing File Format Conversion Scripting in Inkscape ==================================================== Ted is interested in a paper describing our scripting system, and the clever ways we've been able to bend other open source applications to do our bidding. We can describe the crude stdin/stdout extension mechanism that we've been using for the last year to add support for various kinds of file formats, and describe the successes and problems we've seen. Also, it would be valuable to outline some of the other ways we've looked at extending Inkscape, including the ECMA and DOM work Ishmal's been doing (esp. if he'd be willing to participate in the paper). I think this paper would have a huge side benefit in that it'd give us really good motivation to create a complete but concise piece of documentation on our extension system. Since we have several upcoming milestones focusing on extensions, this would probably help in firming up those efforts. It would also gain us something we can give to new developers that would like to extend Inkscape. This might be a good OSCON paper. Best Practice in Open Source Graphic Design =========================================== Andy is interested in helping out with a paper on graphic design, and thinks this could be a good collaboration with Scribus as well. The paper would explain the benefits of using SVG for illustration, and explore reasons and methodology. This could be a good way to showcase examples of the more complex uses that Inkscapers have put the tool to use. I know that people recognize Inkscape can be used for simple, small scale stuff, but I think a lot of people aren't aware of the huge, complex, beautiful works that some folks have done with Inkscape (Scislac's work, for instance). Some other ideas for possible things worth mentioning in a paper like this: The Deviant Art Inkscape group, OCAL, SVG compatibility between other tools/projects (cairo, batik, illustrator, oodraw, et al), bitmap tracing tricks, node and gradient editing techniques, etc. This paper may be best given in a conference geared around art or svg, rather than a strictly technical convention, since it would be aiming at artists rather than developers. Rejon mentioned OpenSVG in the Netherlands, which might be a bit of a trip for most of us. This paper may be something that could be shopped out to several conferences, each near one of the authors (Australia, California, France...) so depending on which conference accepted it, we'd potentially have someone to present there. Conferences =========== Here's some info about what conferences are coming up, how much they cost, when things are due, etc. OSCON - O'Reilly Open Source Convention Proposals: Due Feb 13, 2005 Date: Aug 1-5, 2005 Loc: Portland, Oregon URL: http://conferences.oreillynet.com/os2005/ FOSSTEC - Int'l Symp on Free/Open Source Software, Technologies and Content Abstracts: Due March 2, 2005 (500-1500 words) Date: July 10-13, 2005 Loc: Orlando, Florida URL: http://www.iiisci.org/fosstec05/website/callforpapers.asp OpenSVG Papers: Due March 1st Date: Loc: Netherlands Cost: URL: http://www.svgopen.org/2005/registration.html LWE - Linux World and Expo, SF Proposals: Due March 22, 2005 Date: Aug 8-11, 2005 Loc: San Francisco URL: http://www.linuxworldexpo.com/live/12/speakers//callforpapers LWE tends to be sort of business-ish. The Autopackager paper may fit here, but the others would probably have a tougher chance. LISA Drafts: May 10, 2005 Date: Dec 4-9, 2005 Loc: San Diego, CA URL: http://www.usenix.org/events/lisa05/cfp/ STARWest - Software Testing Analysis & Review Proposals: Due May 20, 2005 Date: November 14-18, 2005 Loc: Anaheim, CA URL: http://www.sqe.com/starwest/speak.asp Might be good for the paper on our bug fixing process... And there's probably more conferences out there... Google around to see if there's an appropriate you think would be worth submitting a proposal to. Bryce

1 0

RE: [Inkscape-devel] Inkboard linking/dependencies
by Montgomery, Steven S 02 Feb '05

02 Feb '05

Yah, we had done that for the files in src and in dialogs. I don't think it was even attempting to build them before we edited the Makefile_insert files... Steven -----Original Message----- From: inkscape-devel-admin(a)lists.sourceforge.net [mailto:inkscape-devel-admin@lists.sourceforge.net] On Behalf Of Bryce Harrington Sent: Saturday, January 29, 2005 3:30 PM To: Montgomery, Steven S Cc: inkscape-devel(a)lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkboard linking/dependencies On Sat, 29 Jan 2005, Montgomery, Steven S wrote: > Where/how do you set dependencies in the Inkscape makefile setup? When > integrating this new code(which is of course in it's own file) to be > called from a dialog, we're having issues with linking. It finds the > function definition, but then gives the following error: > dialogs/libspdialogs.a(inkboard-connect.o)(.text+0xa91): In function > `sp_inkboardConnect_dialog_inkboardConnect(_GObject*, _GObject*)': > dialogs/inkboard-connect.cpp:226: undefined reference to > `connect_and_auth(char*, char*, char*)' > > connect_and_auth is defined in src/inkboard.cpp and is called from > src/dialogs/inkboard-connect.cpp when the user clicks a button on the > new dialog. > > I ran mkfiles.pl and mkdep.pl. Make.dep lists inkboard-connect.o being > dependent on inkboard.h, but it's not picking up the function > definition. > > We appreciate any help/direction on this. Thanks, > Steven Hi Steven, Whenever you add a new file to the codebase, you need to add that file to the makefile as well. Look in src/Makefile_insert, and try adding a line to the libinkpre_a_SOURCES = .... section like this: inkboard.cpp inkboard.h \ You may also need to add inkboard-connect.cpp to the Makefile_insert in the src/dialogs directory as well. Bryce ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

3 2

incrementing ids and other findings
by bulia byak 02 Feb '05

02 Feb '05

OK, I think I understand now why removing "count++" was wrong in this commit: http://cvs.sourceforge.net/viewcvs.py/inkscape/inkscape/src/sp-object.cpp?r… and why I had to restore it, having run into a bug. I think it might be interesting to others too, so I'm copying to the list. (Mental: one question/request for you is at the bottom.) Since count is a global static variable, before that change it was incremented on every object added to any document, no matter was there a conflict or not, including adding object on document loading. As a result, at each point of time, count was no less than the total number of element nodes in all loaded documents. After pjrm's change, count was incremented only for conflicting ids, i.e. very unfrequently. This produced nice small ids and worked fine, but only so long as you are within a single document. The badness of this approach was only evident when you copied things across documents. For example, imagine that you copy a group which has three objects, two of which use the same gradient and the third uses some other gradient. Then the defs_clipboard will contain three objects with ids, for example. gradient100 gradient100 gradient56 The second one is a copy of the first, but when it will be added on pasting to a different document, it will be re-ided. By itself this does not matter because the first copy of gradient100 will still be there and will be used, and the re-ided second copy will just be unused. However, since after pjrm's change count is small, and since the second document (where I'm pasting) may have few objects yet, the generated id for the second copy of gradient100 will have a small number in the new id. For example, 56. So when it's time to insert the gradient56 from the clipboard, it will clash and be re-ided too - now that's a big problem because the object that uses it will now refer to a wrong gradient. Sure, making count big enough does not prevent problems still. Clashes will occur until we reimplement the clipboard properly, with not only re-iding but also updating references to re-ided objects. But until then, the original approach which increments count on each added object is much safer, because it starts finding a new id skipping at least as many numbers as there are objects in _all_ loaded documents. (By the way, Peter, probably your idea in this change was to make ids shorter, but you didn't go far enough in that. You could just as well remove the global count altogether and start counting from 0 each time, until there's no conflict in the current document. This would have approximately the same effect as your change, but the code would become simpler. However, the entire idea behind the global count is to prevent not only the real intra-document conflicts, but also the potential cross-document conflicts, and from this viewpoint it would be still safer to do not only count++ on each added object, but even count+=99 or something like that.) You may ask, why does clipboard pastes two copies of the same gradient? This is a result of another change made by Mental. Pasting defs_clipboard has this check: SPObject *exists = doc->getObjectByRepr(repr); if (!exists){ SPRepr *copy = sp_repr_duplicate(repr); sp_repr_add_child(SP_OBJECT_REPR(defs), copy, NULL); sp_repr_unref(copy); } In 0.40 and before, this worked, i.e. after the first gradient100 was added, the second one would have exists != NULL and will be skipped. This was before getObjectByRepr was implemented via getObjectById and therefore only compared ids. Now it is rewritten differently and this check no longer works (i.e. exists is always NULL). Mental: I'm not sure why (or if) the new behavior is better, I just want to point out that it's different from the old one, and therefore there's a danger that it broke something else as well. Should we restore the old behavior, if only for backwards compatibility?

1 1

Fwd: Re: [office] [Fwd: clarification: OpenDocument and SVG]
by unknown＠example.com 02 Feb '05

02 Feb '05

FYI, we seem to have sparked some needed discussion... ----- Forwarded message from Bjoern Hoehrmann <derhoermi@...240...> ----- Date: Wed, 02 Feb 2005 16:20:29 +0100 From: Bjoern Hoehrmann <derhoermi@...240...> Reply-To: Bjoern Hoehrmann <derhoermi@...240...> Subject: Re: [office] [Fwd: clarification: OpenDocument and SVG] To: Michael Brauer <Michael.Brauer@...678...> * Michael Brauer wrote: >this is not the case on the element level. Reusing attributes from SVG >is considered to be very reasonable by our TC, because SVG is a >widespread and established standard already. However, we face the >problem that, if we want to reuse attributes from SVG, we need to >reference them from our own schema, although the attributes themselves >are contained in anonymous or per-element partition namespaces. (Note that www-svg is a public mailing list for SVG discussions, people on the list do not necessarily represent the SVG WG.) The cited example: <draw:rect svg:x = "2cm" svg:y = "3cm" svg:width = "10cm" svg:height = "20cm" svg:transform = "rotate(45)" draw:style-name = "object-with-shadow" xmlns:draw = "urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" xmlns:svg = "http://www.w3.org/2000/svg" > is semantically equivalent to <qenj:erpg fit:k = "2pz" fit:l = "3pz" fit:jvqgu = "10pz" fit:urvtug = "20pz" fit:genafsbez = "ebgngr(45)" qenj:fglyr-anzr = "bowrpg-jvgu-funqbj" xmlns:qenj = "hea:bnfvf:anzrf:gp:bcraqbphzrag:kzyaf:qenjvat:1.0" xmlns:fit = "uggc://jjj.j3.bet/2000/fit" > which is semantically equivalent to <x/> unless you define something else. So you would have a specification that defines how user agents are expected to process a svg:width attribute on a draw:rect element. In that specification you could as well call the attribute { "file:///usr/bin/dahut", "largeur" } or { "", Breite" }, or whatever you like. From a specification point of view there is nothing to be gained from calling it { "http://www.w3.org/2000/svg", "width" }. So there is no actual need to use the SVG namespace (or any other name- space) to refer to "SVG attributes" and whether there is a benefit is quite questionable in my opinion. Using "http://www.w3.org/2000/svg" does however limit the ability of the SVG Working Group to define what {"http://www.w3.org/2000/svg", "width"} means in a specific context, in particular, if the SVG WG defines some- thing that is not compatible with the definition of the OpenDocument XML format, integrating the OpenDocument format with SVG would be difficult as you have to remove the ambiguity. As far as I can see, unless one considers familiarity with the string "http://www.w3.org/2000/svg" of any importance (like, easier to type/ remember than e.g. urn:oasis:names:tc:opendocument:xmlns:drawing:1.0), there is not really much point in using the SVG namespace, or in fact any other namespace. Why not call it { "", "width" } instead? -- Björn Höhrmann · mailto:bjoern@...679... · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ----- End forwarded message -----

1 0

Re: Bug Status for 0.41 -- 1/27
by Bryce Harrington 02 Feb '05

02 Feb '05

Wow, 45 points worth of bugs closed today has put us well over the top of our goals. Nice! :-) Bug ID# PRI Owner Description ------------------------------------------------------------------------ 1095300 6 ishmal WIN: Save as: no formats to choose from 1082188 9 joncruz Linux: File->Import crash 1044322 6 joncruz Relative Locations <image> tags. 1085586 6 bulia Error in opening AI / EPS file 1103936 6 bulia Bad markup found in translations 1109223 6 mental CVS: Error using calligraphy tool 1108231 6 mental sp_repr_set_position_absolute breakage 1108620 9 joncruz Drag and drop case sensitive 1107775 3 pjrm wrong paper sizes 1105787 9 johncl Installation problem: libatk-1.0-0.dll not found 990677 6 ted readme needed for extensions 1107562 9 bulia Node Align Crash 1101210 3 bulia CVS: Flowtext not working 1103001 3 ted Grid is shown non-uniform 1102318 9 kees Crash on "save as" 1104741 6 bulia Printout 25% too large 1105352 6 pjrm Markers are not shown in Plain-SVG-Export 1075860 9 pjrm WIN: assert when doing stamping during move 1080252 9 bryce crash on intersectiion 1068116 6 mental complie error in gc.cpp with inkscape-20041116 1076872 6 kees ngettext isn't used 933461 6 kees Win32 Install Directories 1068299 6 kees Build failure on mips(el) 1100675 6 mental svg tag requires xmlns attribute in CVS2005-01-10 1097652 9 pjrm crash on whitespace property value ------------------------------------------------------------------------ Current: 165 Goal: 150 Feature Freeze - Jan 26 Hard Freeze - Feb 1 Release - Feb 5-6 Bryce On Sat, 8 Jan 2005, Bryce Harrington wrote: > Okay, since there were no comments to the contrary, I suppose it's safe > to assume this proposal is acceptable to everyone. If not, lemme know. > We'll shoot for 150 points for low/med/high (3/6/9 pts) that are closed > as FIXED (i.e., no points for dups, won't fix, invalid, etc.) and that > are confirmed as present in 0.40 or in CVS. > > Bryce ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

4 9

default shape prefs?
by Kees Cook 02 Feb '05

02 Feb '05

Can we make the default shape prefs as colorful as they used to be? Right now if I start up inkscape without prefs, they're just black shapes. I liked the partially see-through yellow, blue, red, etc. -- Kees Cook @outflux.net

7 22

Possible delay in Hard Freeze
by Bryce Harrington 02 Feb '05

02 Feb '05

We're scheduled to hard freeze today 2/1, however it sounds like there are still some outstanding must-fix bugs, and that some new bugs have appeared in the codebase recently. I think we can hold off making a decision until later tonight, and it sounds like the remaining bugs are simple fixes, so it's possible that we could still make it, if people can make some time tonight to fix bugs. We've been doing good at slaughtering bugs lately so I think there's a good chance of this. :-) If not, then we can postpone the release a bit. It'd be impressive if we could make the date, but we're in no particular hurry so can delay if it'll result in a better product. In any case, please be especially communicative about the status of the must-fix bugs you know about; the more we know, the quicker we can get more eyes on the ones that need it. Bryce

3 3

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

02 Feb '05

We're getting close to the 0.41 release. We're not quite ready for a hard freeze, as there's still several must-fix bugs left, but hopefully soon we'll enter that phase soon. It's worth special mention that there has been some surprisingly successful work done during this bugfix phase on fixing some nasty old crash bugs that have been sitting in our bug tracker for quite a while. It looks like the past two weeks have seen a number of new Inkscaper's judging from the jump in Inkscape-devel@ mailing list membership numbers. Welcome aboard everyone. Looking forward beyond 0.41, once the release is out the door the focus will shift fully towards the GUI redesign work. Much has already been done in this area, but even more work remains. Fortunately for us, GUI work tends to be quite noticeable by nature, so I think in coming months our progress will be highly visible. Statistics Jan 1 Jan 15 Feb 1 ========== ===== ====== ===== Lifetime Rank on SourceForge: 598 570 569 (95.8%) (96.0%) (96.0%) Max Week's Rank on SourceForge: 45 72 * (99.8%) (99.6%) * Total SF Page Views 2,213,324 2,283,160 2,296,458 Total SF Downloads 110,182 114,695 115,645 Total Freshmeat URL Hits 14,291 14,634 15,108 Total Freshmeat Subscriptions 149 151 156 Lines of Code in src/: 321,883 323,251 323,324 Code lines 227,114 227,965 227,872 Comment line 56,048 56,308 56,438 Blank 45,398 45,664 45,624 Lines of Docs in doc/: 17,901 17,901 17,918 Lines of content in website: 9,234 9,328 9,486 Size of the Inkscape wiki: 21,030 20,931 23,576 Bugs open/total: 135/829 145/858 148/917 Features open/total: 340/514 353/530 352/556 Patches open/total: 5/145 6/148 7/154 CVS Commits (as per inkscape-cvs) 9,450 9,625 9,975 Inkscape-devel membership: 132 131 143 Inkscape-announce membership: 147 155 166 Inkscape-user membership: 172 177 181 Num Translations: 33 33 33 Ave Translation Ratio: 43.7 42.0 44.7 * - Statistics unavailable

1 0

thanks!
by Jakub Steiner 02 Feb '05

02 Feb '05

Hi guys, before I get to provide some hopefully useful feedback to you guys, I just wanted to say thank you guys for the work you've done on Inkscape. I can see you're steering the ship towards the right direction - making a nice tool for an _artist_ to draw vector illustrations. I'm aboard! ;) -- Jakub Steiner <jimmac@...659...>

10 11