- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Proposal for inkscape-testers
by Douglas Neale 13 Aug '05

13 Aug '05

As a very new person in these lists, may I make a comment from my background of writing software for the printing and publishing industry over a period of nearly 40 years.. In the early days, programmers were expected to debug their own code, and usually didn't till it got on site. The customers were then exposed to the nasty underside of software development ie debugging! As the software industry grew in size it also developed its own professionals and with them came improved testing. Even today, although I will document my code, I hate testing it! I always, always insist that part of every contract includes adequate provision for testing with real customer data, but NOT by me. You should always test software with a third party. That way you get accuracy, thoroughness and impartiality. My 2p Douglas Neale

2 1

Save preferences also when they are created from the skeleton
by Nicklas Lindgren 13 Aug '05

13 Aug '05

Hi, As a precautionary measure the preferences apparently aren't saved if there was an error loading them. This also applies if they are initialized from the skeleton. This makes no sense, since in that case any old file would have been overwritten anyway. It only causes you to lose any preference-changes from any session started without an existing preferences file (like the first one). I've made a patch for this. It also includes a few gboolean->bool changes. Preferences are still prevented from being saved in case creating the file from the skeleton should fail. The patch can be found at http://www.lysator.liu.se/~nili/inkscape/ . --Nicklas

3 2

Cairo 1.0 coming soon
by Bryce Harrington 13 Aug '05

13 Aug '05

Note the following email describing Cairo as "very close" to a 1.0 release. Bryce ----- Forwarded message from Carl Worth <cworth@...573...> ----- Date: Mon, 08 Aug 2005 17:10:49 -0700 From: Carl Worth <cworth@...573...> To: cairo@...278... Subject: [cairo] Advertising the version of cairo Up until about now, we haven't been offering any guarantees about API stability. That's changing right now as we are getting very close to a 1.0 release. As such, I think it's time to start advertising the version of cairo that is available. Here's what I think I would like to see in cairo.h for this, (assuming a fictitious, future cairo 1.0.1 release): #define CAIRO_VERSION_MAJOR 1 #define CAIRO_VERSION_MINOR 0 #define CAIRO_VERSION_MICRO 1 #define CAIRO_VERSION_ENCODE(major, minor, micro) ( \ ((major) * 10000) \ + ((minor) * 100) \ + ((micro) * 1)) #define CAIRO_VERSION CAIRO_VERSION_ENCODE( \ CAIRO_VERSION_MAJOR, \ CAIRO_VERSION_MINOR, \ CAIRO_VERSION_MICRO) #define CAIRO_VERSION_STRING "1.0.1" int cairo_version (void); const char* cairo_version_string (void); The goal here is to provide easy compile-time and run-time checks of the cairo version. Here's a fabricated example that shows how one might conditionally compile and run against a cairo_solve_world_hunger function that exists only in cairo 1.0.1 or later: int has_solve_world_hunger; if (cairo_version () >- CAIRO_VERSION_ENCODE (1, 0, 1)) has_solve_world_hunger = 1; else has_solve_world_hunger = 0; #if CAIRO_VERSION >- CAIRO_VERSION_ENCODE (1, 0, 1) if (has_solve_world_hunger) return cairo_solve_world_hunger (); #endif return feed_everyone_myself (); I don't know what the right autofoo is to make this reasonable to work with. We do already have one generated header file, (cairo-features.h), so we could lodge this stuff in there. Suggestions, (and implementation), would be quite welcome. -Carl _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo ----- End forwarded message -----

1 0

Re: [Inkscape-user] Re: [Inkscape-devel] Proposal for inkscape-testers
by Jon Phillips 12 Aug '05

12 Aug '05

On Thu, 2005-08-04 at 17:38 -0700, frank gaude' wrote: > Bryce Harrington wrote: > > >[...] > >Anyway, it's too bad that the three responses so far have not been > >supportive to the idea. I feel very strongly that this change would > >benefit Inkscape, just as adopting a bug tracker helped stability, > >establishing open development processes helped usability, and > >establishing a release process helped installability. Am I the only > >person that thinks we could benefit from an organized testing community? > > > It seems to me, and I've been around computers since 1970 and using > Linux since 1996, that testing software independent of developers, > programmers and coders is fundamental to the process. As Linux gets more > mature we should see more of that. Each package should have, in my > opinion, a set of testers using a wide variety of hardware and distros > to find and point out problems. > > Linux as a whole needs more structure to guide its progress if it is > ever to be a player on the desktop, versus Apple and Microsoft. The > whole thing right now reminds me of what was happening in the early > '80s. Unix had a good chance of being a desktop player but for the > unbelievable problems of getting everyone to pull in the same direction. > Enough said about that. > > Let's have a testing group with its mail list. While my initial reaction is to be conservative on the creation of more infrastructure, I think you have a great idea Bryce. Also, I think that it is no skin off the rest of the developers' collective backs for you to set this up and drive it. Testing is very important, and even if this list is not that active, a focus around this subject will really help the project. I think also that a testing list would help encourage people to transition from user, to tester, to developer...enabling this type of transition is so necessary in OSS. Go for it! Jon > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Inkscape-user mailing list > Inkscape-user(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-user > -- Jon Phillips San Francisco, CA USA PH 510.499.0894 jon@...235... http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: rejon@...896... IRC: rejon@...897... Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org)

3 3

Re: [Rosegarden-devel] Re: new icons
by unknown＠example.com 12 Aug '05

12 Aug '05

Quoting Guillaume Laurent <glaurent@...959...>: > Or ex-gtkmm developpers. Dude, gtkmm would be a step up for us. Much of the codebase is still C-style GTK/GObject code[1]. With occasional lingering GTK 1.x-isms. Ick. > > We do plan to replace it with Cairo when that's ready, but > > realistically that probably can't happen at least until Cairo's > > 1.0 release. > > Now you know why we went for Qt :-). Serious question: would Qt help us in that regard? QCanvas' imaging model doesn't look very rich, and we need an offline renderer too. -mental [1] We're working on this, mind. It's just a long, hard, refactoring slog.

1 0

Build report - inkscape-20050810-0340
by Bryce Harrington 12 Aug '05

12 Aug '05

Build system is a couple days behind, but here's the latest completed report: = Analysis Report for inkscape = Platform Unpack Config Build Install WRNS ERRS ------------------------------------------------------------------------ debian x86 0 0 0 0 5 0 == Errors == none == Warnings == display/canvas-arena.cpp:91: warning: invalid access to non-static data member display/canvas-arena.cpp:91: warning: (perhaps the `offsetof' macro was used display/sp-canvas.cpp:127: warning: invalid access to non-static data member ` display/sp-canvas.cpp:127: warning: (perhaps the `offsetof' macro was used libnrtype/Layout-TNG-Output.cpp:226: warning: enumeration value `

1 0

clip art navigator 0.3
by Greg Steffensen 11 Aug '05

11 Aug '05

Hi- sorry for the huge time I've been incommunicado (my family is moving tomorrow, and as a consequence, I've been busy and largely net-less for two weeks... I should have a good connection as of Sunday though). But I've uploaded a new release of the OCAL browser for Inkscape- now called the Clip Art Navigator- to Berlios ( http://download.berlios.de/ocalhelper/clipartnav.tar.gz ). I've included install instructions in the package, but they seemed unwieldly, so I've setup the default config file so that you can use it in its raw unpacked form too- just run "python clipartnav.py". So you can skip the second paragraph of the install instructions in the readme if you want. Dependencies are currently Python 2.4, sqlite, the pysqlite2 python bindings for sqlite, gtk 2.6, pygtk, and the python bindings for libxml2 (I'm very keen on switching to pyxml, but its documentation is horrible, and because of my crappy internet situation, I haven't been able to figure out how to do namespace-based xpath queries with it yet). I believe it can be used on Windows, if you meet the dependencies and set the "repodir", "dbfile", "inkscapecmd", and "inkviewcmd" settings in the config file appropriately, but I haven't tested this (at the very least, GTK's lack of svg support on windows won't be the stumbling block). The major design decision I've had to make is in deciding how to deal with multiple repositories. Basically, it takes an ordered list of repository modules from the config file, queries each of them in sequence, and then while retrieving individual images, skips images that have already been returned by a previous repository. How does it uniquely identify images? By the md5 hash of their svg xml contents. OCAL currently doesn't have any facility for returning hashes, of course, but that part's optional... the repositories can return None instead and the image will just be fetched. So hopefully, There are quite a few missing features, of course, the biggest of which is, uh, OCAL connectivity. I'm still having problems with SOAP, and decided to work on the GTK stuff for awhile just to keep productive. I'll write an OCAL module using another web forms hack in the next couple days. The only repository module included currently is "localocal" (sorry, couldn't resist), which just searches a local directory of svg images, a la the OCAL packages. The "localocal.py" file in the modules dir, in addition to being a repository module, is also a command-line program for indexing the contents of such a directory. I'm going to revamp that command-line interface, but for now, run python localocal.py -r DIR index where DIR is the absolute path to that root directory. Then set the "repodir" setting in the "clipartnav.conf" file accordingly, and set the "dbfile" setting to the absolute path to the new "index.dat" file in that directory. All of this will be automated as much as possible soon. Other missing features are copy-paste (this one is really bugging me... I can copy-paste fine into text editors, but not into Inkscape... and before you suggest it, I've looked at the GTK clipboard action target types extensively), a more dynamic caching system (I describe my plans for that in the DESIGN.txt file), actual insertion of clipart into existing Inkscape documents (this works when invoke the program from the command line yourself and drag-and-drop into Inkscape, but in traditional Effects-menu use, the clipart just replaces the current document... I'll fix this as soon as I switch to pyxml), documentation, and easier installation. I'll try very hard to check email frequently over the next few days, so please let me know if you can't get it to work, or have absolutely any questions or feedback whatsoever. Two issues in particular I'd appreciate ideas on are what could be wrong with copy-paste, and (silly as it is), why I can't get the "forward" button in the interface to have the same arrow style as the back button via glade. Thanks, Greg

2 1

sp_selection_tile() and clones
by Nicklas Lindgren 11 Aug '05

11 Aug '05

In src/selection-chemistry.cpp, sp_selection_tile() line 1957 and on: // delete objects so that their clones don't get alerted; this object will be restored shortly for (GSList *i = items; i != NULL; i = i->next) { SPObject *item = SP_OBJECT (i->data); item->deleteObject (false); } Here's the cause of bug 1238314. If a clone-original is incorporated into a pattern, it's clones are orphaned (because the version in the template is a renamed duplicate). By replacing the code above with a call to sp_selection_delete_impl(), the bug is fixed, but the clones become regular duplicates. Is this desirable? Or should it be fixed in a way that preserves clone-relations? (The comment seems to indicate that this is the plan.) --Nicklas

3 5

Re: [Inkscape-devel] Re: [Fwd: planet.inkscape.org issue]
by Jonathan Leighton 10 Aug '05

10 Aug '05

Bryce Harrington wrote: >Btw, please don't forget to trim down your replies. > > Sorry! : ) -- Jonathan Leighton aka. Turnip http://turnipspatch.com/ | http://digital-proof.org/

1 0

[Fwd: planet.inkscape.org issue]
by Jon Phillips 10 Aug '05

10 Aug '05

-------- Forwarded Message -------- > From: rejon.org feedback form <noreply@...235...> > Reply-To: jon@...235... > To: jon@...235... > Subject: planet.inkscape.org issue > Date: Mon, 8 Aug 2005 09:05:32 -0500 > > Name: Nate > E-mail: cheelay@...400... > > > Hi Jon, I'm not sure who to send this to, but planet.inkscape.org > isn't including updates from inkscape.org's main announcement/news > page. I think it used to but it no longer does. Can that be changed > back? Or is there a reason behind this? > > Thanks, you guys are doing great work.... > nate > > -- Jon Phillips San Francisco, CA Mission District USA PH 510.499.0894 jon@...235... http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: rejon@...896... IRC: rejon@...897... Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org)

3 6