- Inkscape Devel - Inkscape Mailman

[Eng] [Fwd: OSCON Call For Proposals Closing Soon] (fwd)
by Bryce Harrington 08 Feb '05

08 Feb '05

---------- Forwarded message ---------- Date: Tue, 08 Feb 2005 09:34:25 -0800 From: Randy.Dunlap <rddunlap@...1...> To: eng@...1... Subject: [Eng] [Fwd: OSCON Call For Proposals Closing Soon] -------- Original Message -------- Subject: OSCON Call For Proposals Closing Soon Date: Tue, 08 Feb 2005 09:31:19 -0800 From: O'Reilly Conferences <elists-admin@...699...> To: rddunlap@...1... The Call for Proposals will end soon for the 7th Annual O'Reilly Open Source Convention http://conferences.oreillynet.com/os2005/ OSCON is headed back to friendly, economical Portland, Oregon during the week of August 1-5, 2005. If you've ever wanted to join the OSCON speaker firmament, now's your chance to submit a proposal (or two) by February 13, 2005. Complete details are available on the OSCON web site, but we're particularly interested in exploring how software development is moving to another level, and how developers and businesses are adjusting to new business models and architectures. We're looking for sessions, tutorials, and workshops proposals that appeal to developers, systems and network administrators, and their managers in the following areas: - All aspects of building applications, services, and systems that use the new capabilities of the open source platform - Burning issues for Java, Mozilla, web apps, and beyond - The commoditization of software: who and/or what can show us the money? - Network-enabled collaboration - Software customizability, including software as a service - Law, licensing, politics, and how best to navigate other troubled waters Specific topics and tracks at OSCON 2005 include: Linux and other open source operating systems, Java, PHP, Python, Perl, Databases (including MySQL and PostgreSQL), Apache, XML, Applications, Ruby, and Security. Attendees have a wide range of experience, so be sure to target a particular level of experience: beginner, intermediate, advanced. Talks and tutorials should be technical; strictly no marketing presentations. Session presentations are 45 or 90 minutes long, and tutorials are either a half-day (3 hours) or a full day (6 hours). Feel free to spread the word about the Call for Proposals to your friends, family, colleagues, and compatriots. We want everyone to submit, from American women hacking artificial life into the Linux kernel to Belgian men building a better mousetrap from PHP and recycled military hardware. We mean everyone! Even if you don't want to participate as a speaker, send us your suggestions--topics you'd like to see covered, groups we should bring into the OSCON fold, extra-curricular activities we should organize--to oscon-idea@...699... . This year, we're moving to the wide open spaces of the Oregon Convention Center. We've arranged for the nearby Doubletree Hotel to be our headquarters hotel--it's a short, free Max light rail ride (or a lovely walk) from the Convention Center. Registration opens in April 2005; hotel information will be available shortly. Deadline to submit a proposal is Midnight (PST), February 13. For all the conference details, go to: http://conferences.oreillynet.com/os2005/ Press coverage, blogs, photos, and news from the 2004 O'Reilly Open Source Convention can be found at: http://www.oreillynet.com/oscon2004/ Would your company like to make a big impression on the open source community? If so, consider exhibiting or becoming a sponsor. Contact Andrew Calvo at (707) 827-7176, or andrewc@...699... for more info. See you Portland next summer, The O'Reilly OSCON Team ******************************************************* To change your newsletter subscription options, please visit https://epoch.oreilly.com/account/default.orm and click the "Manage My Newsletters" link. For assistance, email help@...700... O'Reilly Media, Inc. 1005 Gravenstein Highway North, Sebastopol, CA 95472 ******************************************************* -- ~Randy _______________________________________________ Eng mailing list Eng@...701... http://lists.osdl.org/mailman/listinfo/eng

2 1

SVG tutorial translation
by Lucas Vieites 08 Feb '05

08 Feb '05

Hi list, In August last year (08/2004) we had a small thread in this list discussing new ways of making the translation process of the tutorials in svg format easier. TMX and XLIFF formats were mentioned and I remember talking about not having tools for these formats. A few days ago I read about the freedesktop.org XLIFF tools project: http://xliff-tools.freedesktop.org/wiki/ and googling a bit for "xml to xliff" conversion tools I found several initiatives (this one very nicely illustrated http://infomanagementcenter.com/pdfs/translation_wxml_tools.pdf). Question: Can we make use of these technologies for svg files? I suppose that because svg is a subset of xml we shouldn't have big trouble, should we? Cheers, -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

5 4

SVG::Metadata 0.21 released
by Bryce Harrington 08 Feb '05

08 Feb '05

Version 0.21 of SVG::Metadata has been released to CPAN tonight. Changes: * Added a metadata edit feature to svg_annotate. The script now accepted a '-e' parameter which allows altering the metadata in an SVG file. It does this in the crudest possible fashion: It parses the file for metadata, makes the modification you request, then deletes all the metadata, then re-inserts the metadata back into the file. Beware! This could really fsck up your SVG files, make sure to keep backups before running, etc. If it does, send me a bug report. * Fixed bug where SVG::Metadata parses the publisher info incorrectly, causing further writes to display it as HASH. * Entirely removed an if clause that was causing 'improvisedkeywordparse', 'HASH', etc. to appear in keywords. This was just a hack around a bug in Inkscape that's been fixed for a few releases anyway, so the code's not that useful. * Fixed the problem that was causing the above bug to begin with. It now assumes the 'subject' field is proper RDF instead of permitting freeform text, as Inkscape used to do long, long ago. * Removed the default values for the cmdline options for license and title. Now they default to blank (''). This was done so that when running `svg_annotate -e`, it won't change contents of your SVG metadata to the defaults. * Changed the default for title from 'Clipart by <AUTHOR> - <FILEBASE>' to just '<FILEBASE>'. Enjoy! Bryce

1 0

Unable to open SVG in Inkscape
by Christian Fredrik Kalager Schaller 07 Feb '05

07 Feb '05

Hi guys, The attached file (our company logo) renders fine with librsvg, but inkscape seems unable to even load it. Any ideas why? Christian

4 6

"Bug" with command line export
by jiho 07 Feb '05

07 Feb '05

Hi all, first message on this list (following a first chat on jabber, lots of "first" today). I found a "bug" using inkscape 0.39 at the command line under mac (sorry but I can't spend all the necessary time to recompile CVS on my mac and I don't think this was mentionned before, so this wasn't fixed either probably). Anyway I wanted to export some file.svg to file.png: inkscape -d 72 -b white -e file.png file.svg as long as file.png does not exists, everything is fine. when file.png exists i receive a long list of errors starting like this: (process:12102): Gtk-WARNING **: Screen for GtkWindow not set; you must always set a screen for a GtkWindow before using the window (process:12102): Gtk-CRITICAL **: file gtkiconfactory.c: line 1224 (gtk_icon_size_lookup_for_settings): assertion `GTK_IS_SETTINGS (settings)' failed (process:12102): Gtk-WARNING **: gtkstyle.c:2037: invalid icon size '4' (process:12102): Gtk-CRITICAL **: file gtkstyle.c: line 1903 (gtk_style_render_icon): assertion `pixbuf != NULL' failed (process:12102): Gtk-WARNING **: Theme engine failed to render icon (process:12102): Gdk-CRITICAL **: file gdkpango-x11.c: line 53 (gdk_pango_context_get_for_screen): assertion `GDK_IS_SCREEN (screen)' failed [....long list of the same type of errors...] I imagine it is because inkscape tries to open a GTK windows asking me if I want to overwrite the existing file.png. a GTK window can't be opened because I launch this from the Terminal.app (and X11 is possibly not even started). But the point is that: -even if I run this command line on an xterm inside X11, I get the same errors -even if I add the "-z" option to the command line, I get the same errors If I try to export the same file from inside inkscape i got the correct dialog and I can export my file and overwrite the existing one without problems. So I think that on system where GTK is not "native" (I think it's a bad word but maybe you can understand what I mean) GTK popup windows like this can't be opened. Therefore, I think that, to make this command line tool more robust, it might be remplaced by a text sent to the standard output (terminal) asking if the user wants to overwrite the file or not. at least when the -z option is explicitely mentionned. thanks in advance for any help with this. ask me for precisions if yo need to. JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/

3 3

Keywords issue between OCAL and Inkscape
by Bryce Harrington 07 Feb '05

07 Feb '05

Uraeus pointed out that the keywords added by svg_annotate don't show up in Inkscape. It looks like svg_annotate is inserting the keywords correctly, more or less. (It doesn't add id numbers to the elements, but I'm fairly sure that's not required anyway.) The problem appears to be that Inkscape is not reading the keyword info in. It's simple to check this: * Start up a new drawing in inkscape * Draw a circle or something * Go to Document Properties > Metadata and type "asdf" for a keyword * Save the file and exit inkscape * cat the saved file and note that asdf is in the keywords section * Load the file in Inkscape again * Go to the Document Properties > Metadata page. No keywords shown. I've submitted a bug report on the above. Bryce

2 1

Fwd: [devel] New Gnome Project (Clipart Browser)
by Alexandre Prokoudine 07 Feb '05

07 Feb '05

FYI. ---------- Forwarded message ---------- From: Mike Powers <mjpowersjr@...400...> Date: Fri, 28 Jan 2005 12:14:12 -0500 Subject: [devel] New Gnome Project (Clipart Browser) To: paolo.bacchilega@...695..., criawips-devel@...448..., miguel@...653..., support@...696..., scribusdocs@...84... Hello, My name is Mike and I have been using Gnu/Linux teamed with Gnome for my main desktop at home. During the past year as I have used linux for Multimedia, Internet/Email and Office tasks, I have noticed a few areas where I the Linux desktop seems to be lacking.Please correct me if I am wrong, but their seems to be no easy way for the average user to insert clipart into typed documents.Most all Gnome Office related applications allow insertion of pictures via the File Open Browser window, but it makes it hard for the average person, without understanding of file systems, to insert clipart. I plan to (hopefully with the help from others ;-) ) develop a standalone program (or library) that other applications can call upon, to aid in Inserting clipart. I am planning on using the source code from the current release of gthumb as a starting point for this project, and have some ideas listed below. If this is something that you would be interested in using as a part of your applications, or have ideas, suggestions, ect. please let me know. Also, I have done some initial mockups, without reading HIG yet. (sorry, but their bitmaps until i can leave work and get a chance to convert them.) http://www.sharelinux.org/clipbrowser/ Here is a semi-organized list of thoughts on the project: Program Input Options: -Filters on what categories to make visible -Import Images to the clipart gallery via command line. Program Output Options: -Clipart Browser can return a list of selected files. Design Problems needed to be solved (I need your input :) ): -What would be the preferred way to call the browser. -Where should the clipart be stored by default? -What permissions should people have for the clipart? -How to approach importing clipart. -What external websites should be queried for the websearch feature. (google...) -Is their even a need for image conversion in the browser utility? -How would they be implemented into existing programs. Maybe someone is already working on this and I'm just ignorant to the fact, To give you a background on my coding experience, I have taken classes in c++ about two years ago, and recently started reading up on the language again. I have never started a major project before, only pieced together small programs to "get the job done" so any help would be appreciated. I have wanted to contribute to the Gnome desktop for quite some time now, and thought a Project like this would be a good place to start, as I would imagine much of gthumb's code could be used in this project. -thank you. -Mike Powers. (mjpowersjr at gmail dot com) _______________________________________________ criawips-devel mailing list criawips-devel@...448... http://lists.nongnu.org/mailman/listinfo/criawips-devel

1 0

[jonadab@...581...: Re: [Clipart] character coding]
by Bryce Harrington 07 Feb '05

07 Feb '05

Jon, can you give some advice on this one? ----- Forwarded message from Jonadab the Unsightly One <jonadab@...581...> ----- Date: Mon, 07 Feb 2005 00:01:33 -0500 From: Jonadab the Unsightly One <jonadab@...581...> To: clipart@...330... Subject: Re: [Clipart] character coding Nicu Buculei <nicu@...398...> writes: > i remember we talked several months ago about this problem and IIRC is > generated by the upload tool. The upload tool's approach to character encoding is completely naive: it just assumes that whatever form it _receives_ the data in is suitable also for _storing_ it. (At least, that's how it's supposed to work.) It doesn't care whether the data is ISO-8859-15 or what. (For the filename, it uses only 7-bit printable ASCII characters, but it doesn't remove non-ASCII characters from the actual metadata or change them in any way; it just represents them as underscores in the filename.) It does need the data to be in some encoding that encodes certain characters the same as in ASCII -- mainly the characters that have special significance to XML, such as < and > and / and so forth, plus the letters in certain tags (s, v, g, r, d, f, and so forth). But those are all 7-bit characters. It won't be able to handle EBCDIC data, for example, but any sane, ASCII-compatible encoding should work just fine. In theory. I do not off the top of my head know what character set ISO-8859-15 is, other than that I think all the ISO-8859-anything charsets are fully ASCII-compatible in the bottom seven bits. And it was my understanding that UTF8 has this property also. So in *theory* it should Just Work (in the sense of not making any undesired changes). The one problem I can think of off the top of my head that could occur with this is if the data that the upload tool receives is not consistent in its encoding -- e.g., if the SVG it receives is in one encoding, and the metadata the user fills in on the form is sent by the browser in a different encoding. Is it possible that that is what happened here? > is saved as ISO-8859-15 I was unaware that the filesystem maintained character-set metadata. What does it mean for a file to be "saved as" ISO-8859-15? How can you tell what character set a file uses, apart from looking at the charset information in the XML declaration? More to the point, how can the script detect what encoding the information it's receiving is encoded in, short of asking the user? Maybe we need a Unicode guru. I'm not one. Alternatively: does RDF allow for non-ASCII characters in the metadata to be encoded as entities? Could we just use something along the lines of HTML::Entities to encode it (so that e.g. the problematic character in the file in question would become é or somesuch)? Wouldn't that render the character encoding basically irrelevant? -- $;=sub{$/};(a);=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/ _______________________________________________ clipart mailing list clipart@...626... http://lists.freedesktop.org/mailman/listinfo/clipart ----- End forwarded message -----

1 0

Next up URI madness!!!!
by Jon A. Cruz 07 Feb '05

07 Feb '05

Well... now that 0.41 is all chilly and such, time to start thinking of next things to do. One of the ugly, sneaky, subtle probleme we have is URIs. What is a URI? Do we want to use URIs all over? Is there something else we want to use instead? Some places we have a 'gchar const *uri', Inkscape::URI, and 'gchar const *filename'. The first (sometimes) is some string representation that might be a URI The second is a class for a 'URI' as defined in RFC 2396 The third is just a local file path. One problem is that often the first and third get mixed up. Another problem is that URI's are supposed to be encoded in escaped ASCII, and all the glib routines like g_filename_from_uri expect properly formed URI strings. So there are things we use as file paths and such that break when treated as pure URIs. Soo....... what should we do about this mess?

1 0

Inkscape 0.41pre2 posted
by Ted Gould 07 Feb '05

07 Feb '05

Inkscape 0.41pre2 has been posted here: https://sourceforge.net/project/showfiles.php?group_id=93438&package_id=991… It is currently expected that this will be the last prerelease before 0.41, please check it for any bugs so they won't make it into 0.41! --Ted

1 0

Object Rotation
by Aaron Spike 07 Feb '05

07 Feb '05

I just wanted to say that having the degrees on the taskbar follow the objects rotation is fantastic. It makes 1 and 2 degree snapping very useable for me. I can even get 72 degrees now. :) Thanks very much. And I just found another really fun use for inkscape: creating gDesklets <http://gdesklets.gnomedesktop.org/>. A little XML, a little python, an SVG and wahla instant eyecandy. Thanks again, Aaron Spike

1 0

AI Input
by Ted Gould 07 Feb '05

07 Feb '05

There is a bug in the .inx file for AI input. One of the attributes got changed to the wrong name. It looks like it happened when changing a bunch of other values. Without the fix AI input will not work unless the extensions directory is put into the path. I've attached a patch, which I believe should be put in for 0.41. --Ted

2 1

Last minute file naughiness
by Jon A. Cruz 07 Feb '05

07 Feb '05

Well... I went on a last-minute search for file naughtiness. There are a few pixbuf loads here and there, but I'll ignore them for now. The one I am concerned about is in repr-io.cpp, in sp_repr_read_file I *think* that's the last main one, but is a biggie, so I'm going to try to munge things in. Of course, this is very sensitive stuff, so it will need verifying to ensure all is happy-happy everywhere.

6 25

line-height
by bulia byak 06 Feb '05

06 Feb '05

Peter: Please don't touch line-height property which I added to style.cpp. Reasons: 1. CSS2 says: "User agents must ignore a declaration with an unknown property." This means even if it is an invalid property, it will do no harm. It will just be ignored. 2. In SVG 1.1, line height is just given a fixed value equal to font-size. Our specifying a different value will have no effect whatsoever on compliant renderers. 3. SVG 1.2 indeed does not mention line-height for flowtext (as I wrote here some time ago). But it also proposes NO OTHER mechanism for controlling inter-line spacing. So I'm inclined to think that this is just an omission in the standard. If you're so worried by it, you can go to the W3C SVG list and raise this issue there. I'm reasonably sure that when made aware of the omission, the authors will reuse line-height as this is the most natural approach. 4. Without a way to control line spacing, flowtext is pretty much useless. So, if we cannot use line-height nor any other mechanism for that, I see no reason to continue working on flowtext. In other words, the choice we have is between completing the draft spec where it's most obviously incomplete, or just giving up and not having flowtext at all.

1 0

inkscape.svg vs plain.svg
by unknown＠example.com 06 Feb '05

06 Feb '05

Hi, I have been going through the openclipart.org flag collection yesterday, cleaning up metadata etc. There is a couple of issues I would like to bring up which I noticed in this process. The first thing is that images saved in sodipodi.svg/inkscape svg do not always render correctly with librsvg. I filed a bug with librsvg on this, but the reply I got is that this is caused by sodipodi/inkscape svg not being fully SVG compliant. Saving the flags with prolems as plain.svg made them all render correctly. Now the question is wether I should file these flags towards Inkscape as bugs, I assume so, as I think if we generate a file with .svg it should render nicely in all other SVG renderers? For some testfiles all the pirate flags in openclipart 0.10 misrender until resaved as plain svg. librsvg bug with some details here: http://bugzilla.gnome.org/show_bug.cgi?id=166385 The second thing which I have brought up with Jon Cruz and Bryce already is that there is some difference in metadata handling between svg_annotate/svg_validate and Inkscape. Inkscape do not recognize keywords set by svg_annotate and svg_validate do not recognize titles set by Inkscape for instance. Apart from these items, keep up the great work, Inkscape is really rocking! Christian

2 2

Bug 1114714
by Jon A. Cruz 06 Feb '05

06 Feb '05

To try to see if bug 1114714 is fixed, can someone on Win32 add some asserts and test things? Just go into src/dialogs/export.cpp and before each call to *_set_text add warnings just before each? if (!g_utf8_validate(variableAboutToCallSetWith, -1, NULL)) { g_warning( "variableAboutToCallSetWith IS NOT UTF-8" ); } Then try some file/directories with umlauts in them? Thanks.

1 0

0.41pre1 tarball is up
by Kees Cook 06 Feb '05

06 Feb '05

Ted and are both having harddrive and filesystem problems tonight, it seems. I've managed to get the 0.41pre1 tarball up on sourceforge, emulating the prior prerelease notes, etc. -- Kees Cook @outflux.net

1 0

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

06 Feb '05

They were actually listed under libinkpre_a_SOURCES. Just removing them from there fixed the issue. Thanks for the help on this! 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, February 05, 2005 1:27 PM To: Montgomery, Steven S Cc: inkscape-devel(a)lists.sourceforge.net Subject: RE: [Inkscape-devel] Inkboard linking/dependencies On Sat, 5 Feb 2005, Montgomery, Steven S wrote: > I've went ahead and included the extern lines: however, that's a > different issue than what we were having. The undefined reference we > have is to functions we wrote in inkboard.cpp. Here they are from the > most recent attempt: > dialogs/libspdialogs.a(InkboardMsg.o)(.text+0xa7a): In function > `sp_inkBMsg_ObjectAddedChild': > dialogs/InkboardMsg.cpp:436: undefined reference to `sendChange(char*)' > dialogs/libspdialogs.a(InkboardMsg.o)(.text+0xc92): In function > `sp_inkBMsg_ObjectRemovedChild': > dialogs/InkboardMsg.cpp:519: undefined reference to `sendChange(char*)' > dialogs/libspdialogs.a(InkboardMsg.o)(.text+0xe4d): In function > `sp_inkBMsg_ObjectChanged': > dialogs/InkboardMsg.cpp:624: undefined reference to `sendChange(char*)' > dialogs/libspdialogs.a(inkboard-connect.o)(.text+0xa97): In function > `sp_inkboardConnect_dialog_inkboardConnect(_GObject*, _GObject*)': > dialogs/inkboard-connect.cpp:228: undefined reference to > `connect_and_auth(char*, char*, char*)' > dialogs/libspdialogs.a(inkboard-connect.o)(.text+0xacf):dialogs/inkboard > -connect.cpp:238: undefined reference to `setRecipient(char const*)' > dialogs/libspdialogs.a(inkboard-connect.o)(.text+0x138f): In function > `sp_inkboardConnect_dialog_inkboardShareUser(_GObject*, _GObject*)': > dialogs/inkboard-connect.cpp:393: undefined reference to > `send_connect_request_to_user(char const*, char*)' > > I suspect you didn't get that error when you checked out of the CVS. > Line 8 of inkboard.cpp should be #include "dialogs/InkboardMsg.h" > instead of #include "dialogs/InkboardMsg.cpp". I hesitate to upload > that change since we've been following the convention of only committing > changes after we ensure that it at least compiles. > > For a reason I don't fully understand, including that .cpp somehow > informs the linker of where our new functions are defined. Well, by including the .cpp you essentially are pasting the contents of that file in, so it's getting the full definition of all the functions. However, having multiple definitions of functions in your binary will cause trouble later, so we should solve the problem more directly... Try this. Move your two main files to the inkpost.a section, i.e.: libinkpost_a_SOURCES = \ ... inkboard.cpp inkboard.h \ This forces those objects to be compiled last in the link chain, so if link ordering is the issue, this might fix it. 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

1 0

g_file_test
by Kees Cook 06 Feb '05

06 Feb '05

I've been playing with Jon Cruz's updates to the profile_path and mkdir stuff. Short story: it works. Long story: g_file_test isn't utf sane. *bang head* So, the test for the directory fails, but making it works just fine. -- Kees Cook @outflux.net

5 8

[0.41] Fix link: Move functions from splivarot.cpp to xml/
by Peter Moulder 06 Feb '05

06 Feb '05

A couple of utility functions in splivarot.cpp have become used by xml/repr-util.cpp. The attached patch moves these two functions (LCA and AncetreFils) to new files xml/repr-sorting.{cpp,h} in xml/libspxml.a. This is appropriate for cleanliness, and also fixes a link problem with `make check'. Since we're in hard freeze, I haven't renamed these functions. (N.B. Remember to do `cvs add -ko xml/repr-sorting.{cpp,h}' after applying this patch.) The patch (like the gc one, I should have mentioned in the previous message) is from the src directory. pjrm.

2 2

[0/5]: patches for clean "make check"
by Kees Cook 05 Feb '05

05 Feb '05

Following this email are five patch sets (whose apply order matters). This is a full roll-up of changes Peter and I worked on last night with some additional updates to get "make check" to fully pass. 1/5: compile cleanups only This is makefile goo for getting "make check" to compile correctly. 2/5: test code changes only This is test-code changes only. No core code changes are needed to make these tests pass "make check". 3/5: core code changes for repr-action-test compiling This is a change to the way core code is layed out in the tree, to help compile repr-action-test more easily. The functions are unchanged. 4/5: core code changes for repr-action-test behavior This changes when an undo session is released, down in simple-session. This lets repr-action-test pass its tests. The only caller to sp_repr_rollback is sp_document_cancel. sp_document_cancel isn't easily callable, since the three calls to it currently would only happen during repr tree breakage in the XML editor. I think this is safe. 5/5: win32 file list updates This is just a final sync of all the above file changes, as seen by the win32 file list building tools. "make check" finished, but "make distcheck" does not, as streamtest depends on files local to its directory, which is against build rules for "distcheck". I will fix it later, since I made it relocatable in patch #2. -- Kees Cook @outflux.net

4 4

[4/5]: core code changes for repr-action-test behavior
by Kees Cook 05 Feb '05

05 Feb '05