April 2006 - Inkscape Devel - Inkscape Mailman

win32 build working again
by Bob Jamison 08 Apr '24

08 Apr '24

The win32 build, which was broken for the weekend, is working again. I just made a "manual autobuild" again, so that we can see how it looks on Windows: http://troi.titan-aeu.com/~rjamison/inkscape/builds/ Bob

2 1

0.44 development status
by Bryce Harrington 22 Oct '06

22 Oct '06

Hi all, I've compiled the status for the 0.44 development checklist. I'm sure this is already out of date, so please email me updates and I'll update next weekend. Luckily, most everything people are working on sound like they could be wrapped up by the end of the month, however the quantity of things going on suggests that at least some efforts may require longer. Thus, I would like to propose the following schedule for getting to Feature Freeze mode: Now - Development continues on the ~24 items identified For non-0.44 feature work, please use branches May 1st - Achieve completion of at least 50% of the items. Work continues on the remaining 12. Work ceases on any other features. Notification to translators Begin focusing on bugfixes. Identify preliminary "must-fix" buglist May 15th - Feature Freeze All feature development work ends Finalize the "must-fix" buglist Issue pre-release packages for testing Focus on bug fixes, translations, & docs TBD - Hard Freeze Translation work finishes Final resolution on all "must-fix" bugs Issue one or more release candidates TBD - 0.44 Release How does this plan sound? Has anything been missed? ------------------------------------------------------------------------ Inkscape 0.44 Development Checklist ICC Preview =========== Jon Cruz is working on this. Plans to have feature to a finished point for the release. * Update Release Notes CMYK support ============ Jon Cruz is working on this. Plans to have feature to a finished point for the release. * Update Release Notes ArtLibre named icon and cursor loading ====================================== Jon Cruz is working on this. Plans to have feature to a finished point for the release. * Update Release Notes Palette editing and per-file color sets ======================================= Jon Cruz is working on this. Plans to have feature to a finished point for the release. * Update Release Notes Tablet Bugs =========== MentalGuy is working on this. Says for the release he wants to get these resolved. Brush size adjustment on zoom toggle for calligraphic pen ========================================================= MentalGuy is working on this and plans to have it to a finished point for the release. Layer dialog ============ This is an important feature for the release, and on MentalGuy's todo list. However, work has been stuck getting Inkscape::LayerManager to compile due to a subtle detail with sigc::mem_fun(), and it's uncertain if there is sufficient time to unstick it and finish the feature prior to the release. Additional people's help may be needed here. [Beyond the memory issue, are there other aspects to the layer dialog that others could help with, such as UI work or coding helper features or whatever? --bh] * Update Release Notes Fit Canvas to Selection ======================= This is a feature ACSpike has been working on, and plans to complete for the release. The patch is here: http://www.ekips.org/comp/inkscape/inx/current.diff ODG Format Support ================== Ishmal is working on this currently. It basically works and is 90% done; the one issue at the moment that needs to be fixed for the release is that image rotations are backwards. [I think this might be fixed now. -- bh] DOM Support =========== Ishmal has been working on this. The newest code is all imported and builds. [Is there anything else needing to be done prior to release?] SIOX Support ============ Ishmal has this over half done. The code is all imported and building, and the selection mechanism is about done. Getting Inkscape and SIOX intercommunication working, but this can be built as a filter to potrace, which simplifies things. There are some transformation issues that need to be sorted out. Extensions ========== Ted is focusing on cleaning up extension parameters and felt he'd have this wrapped up by the end of the month. The plan is to have longer text (tool tips) available, and a few more widgets. More spacing in the autogui will be added to make it look nicer. * Ted reports there is an unverified bug in the ordering of the effects in the menu, to be investigated. The Extension Editor is further off, and not being planned for this release. Snapping ======== !!! More info needed - Carl and Mathieu (and maybe Ralf?) !!! * Need to fix the freeze when dragging multiple selected objects: http://sourceforge.net/tracker/index.php?func=detail&aid=1429049&group_id=9… * Update Release Notes Rendering Performance Speedup ============================= Andrius has a very interesting rendering speedup patch. The feature is complete and accepted for the release. There is one known issue to address with scrolling, but Andrius feels this can be fixed. * Additional testing needs to be performed Screenshots =========== Scislac has taken this task on, and plans to have it done for the release. Two screenshots are done currently, and one more is in the works. There will be a call for more screenshots on the Deviant Art site. Tutorials ========= Calligraphy is mostly done, and a few of the other updates to the other tutorials have been drafted but that stuff definitely needs more work. Should be possible to have them done by the end of April. Calligraphic interface tweak ============================ Bulia is working on this change requested by MentalGuy, and feels they are minor and should have no trouble completing for the release. Windows font handling bugfixes (DONE) ============================== Richard (cyreve) has completed these bug fixes and updated the release notes. * Update ReleaseNotes Python Extensions on Windows ============================ !!! No owner has been identified for this task !!! Bulia reports that extensions that rely on PyXML still do not work on Windows. Due to the number of python extensions, this would be a major missing feature for Windows users. Text/Fonts UI ============= deadchip (aka Milosz Derezynski <internalerror at gmail dot com>) has written a font lister Gtkmm class, to enable re-use of the font list. He is planning to write a font picker dialog, and rewrite the current font picker to use the font _listing_ class. This enables using normal Gtk components (ListStore, etc.) for accessing the font info. He plans to have this work done by May 1st, or May 15th at the latest. Windows "dialogs on top" Patch for GTK ====================================== !!! No owner has been identified for this task !!! This is not exactly an Inkscape-specific problem, since the code changes wouldn't be to Inkscape, but it would be nice to have it finally fixed. This 0.44 release effort may be a good vehicle to tie it to, but we won't hold up the release if it doesn't get done. Scislac had contacted the author previously. * Send a reminder email to the author to find status on this Undo/Redo Dialog ================ !!! No owner has been identified for this task !!! We have a patch for this, but the author has not been reachable. Also needed is undo annotations. * Unless the author or another developer takes ownership of this patch within a week or so, perhaps the wise thing to do would be to incorporate it right after the release, to give maximum debugging time for 0.55. New File Chooser in Export ========================== We have a patch for this, but there were some thoughts of embedding it in the export dialog directly. In the spirit of "patch first, discuss later", the best approach may be to stick in the current patch for 0.44, see what folks think, and do the embedding later. Additional Release Tasks ======================== The following tasks will need to be done for the release, but are not required to be done prior to the Feature Freeze: * Identify the list of must-fix bugs. To keep the freeze phase from dragging out, we will need to be very choosy in what we allow to be must-fix bugs. * Set up a ReleaseChecklist wiki page or similar to keep track of The List. * Designate 2 release maintainers. * Keep and update the above list and encourage people to achieve completion of the items. * Notify translators to complete translation work * Wiki updates + Update Roadmap + Review/Update FAQ + Update InkscapeFeatures * PR / marketing efforts + Plan efforts + Draft press release + Finalize press release + Send out press release [rejon] * Packaging Bryce

15 29

SVG Element/Attribute Support List
by Joshua A. Andler 28 Aug '06

28 Aug '06

I saw this handy dandy list over at Opera's site and thought that we may want to think about doing something similar... what do others think? http://opera.com/docs/specs/opera9/svg/ -Josh

3 2

NEW: Zommed in rendering speedup
by Andrius Ramanauskas 15 May '06

15 May '06

As mentioned in some previous mail, I have finished rendering optimisation, which gives best results for zoomed in drawings with complex (multi-node) paths. Optimisation focus - eliminating cubicTo and LineTo nodes outside of visible area, so no unneeded calculations is needed and less memory is consumed (this avoids crashes which were occurring previously if zooming into a complex drawing). This can be improved even more (for example ArcTo nodes are not affected and is still slow if zoomed in; etc). This might affect all the rendering, so please report any broken rendering issues. Andrius

3 3

Tangofied inkscape icon
by Andreas Nilsson 14 May '06

14 May '06

Hello everyone! Hope this is the right place to send this stuff. Here is a tangofied Inkscape-icon in the sizes scalable, 22 and 16. Been on my harddrive for quite a while now, but I figure you might have use for it. http://ramnet.se/~nisse/diverse/temp/inkscape-icon.tar.gz - Andreas

3 4

WEBFORM live bookmarks / rss
by pbhj 10 May '06

10 May '06

Message from Inkscape submission form Please note, that the submitter may not read this list. CC your answer to the submitter name: pbhj email: inkscape@...1029...%0Acc:pbhj@...19... submitted the following: RSS feed, great! No <link> in page header makes it v.hard for Firefox users to add a livemark though. <link rel=\"alternate\" type=\"application/rss+xml\" title=\"inkscape news\" href=\"/inkscape.rss\" /> Cheers pbhj

4 4

RSS feed not synced with website news
by Luca Bruno 10 May '06

10 May '06

Hi all, I've just noticed that the RSS feed for inkscape.org[1] isn't synced with latest news on the website. It's currently missing at least latest post by rejon. Can anyone please check why and fix it? I remember the feed-generator script is called from a cron (which?), maybe the problem is there or in the switch between CVS and SVN repo... Greetings, Luca [1] http://www.inkscape.org/inkscape.rss -- .''`. ** Debian GNU/Linux ** | Luca Bruno : :' : The Universal O.S. | luca.br(AT)uno.it `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Proud Debian GNU/Linux User

2 2

Problem with verbs
by Jon A. Cruz 06 May '06

06 May '06

Before I did some other changes that would require adding a new verb, I setup a unit test on verbs explicitly. In doing so, I discovered that Verb::getbyid() fails if the id has any dots in it. To see the problem, just update and do a 'make check'. You should then see the warning come up for that (I made it a warning for the moment, instead of a failure). So, does anyone have ideas about this and how to fix it?

4 4

Flash Export
by unknown＠example.com 05 May '06

05 May '06

Hello everyone. I've been playing with Inkscape for a while now, keep up the good work. I am interested in Flash export functionality for Inkscape. Are any developers working on this? I would be interested in helping out. Brian

5 8

SoC and automatic kerning
by juraj sukop 05 May '06

05 May '06

Dear Inkscapers, I greatly welcomed that Summer of Code is going to happen this year again, since I would like to participate this time. I would like to develop a tool for automatic kerning -- this should adjust the position of the letters in a text to correct the spacing irregularities, to ease the reading flow and to improve readability. This is also called optical kerning. To me, this is very helpful feature and I can imagine it could be of use for other open source software as well. Unfortunately, this is not listed on your Project Ideas page. What do you think? Would such a thing make sense for Inkscape and in the same time applicable for Summer of Code? Thanks a lot for any feedback and good night! Juraj Sukop

5 7

snapping update?
by bulia byak 02 May '06

02 May '06

One thing that we can't release without is workable snapping. Since more and more people start talking about releasing, I thought I'd ask for an update. Overall, it seems to me that this area, which was actively worked upon a few months ago, has been abandoned since and is now in some semi-working state. At the very least, the freeze-when-dragging-many-objects bug MUST be fixed. There are many other snapping bugs and RFEs, and there's probably some work that was left unfinished. Carl, is there any chance you will address the freeze bug in the near future? What about other bugs? Mathieu, I know you were working on some features that were conditional on Carl's work. Can you please give us an update of the current status? What is required to enable your features? Do you think you could help us with the bugs and general cleanup in absence of Carl? Of course, any insights on the situation, or better yet, help with coding will be much appreciated from anyone. Thanks! -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 1

path effect grammar
by Aaron Spike 02 May '06

02 May '06

I'm still rather hating the way I'm currently implementing attributes for storing live effects parameters. <path path-effect="sample" path-effect-param1="0.0" path-effect-param2="0.0" path-effect-param3="0.0" path-effect-param4="0.0" /> My problems with this are: 1) Anytime a new effect is implemented that uses n+1 parameters, another parameter attribute needs to be added in a few code places. 2) It is not possible to layer multiple effects. 3) It is not possible to order the effects that cannot be layered. 4) The meaning of the parameters is unknown in the SVG file. The structure used by SVG's style attribute deals with 1 and 4. The structure used by SVG's transform attribute deals with 2 and 3. We could combine them into something like: <path path-effect="sample1(param1:0.0;param2:loopy;) sample2(paramA:45;)" /> I of course don't know how to begin doing something like this in C++. I'd like to hear what you think would be more appropriate and how it would be implemented. Aaron Spike

7 24

finalizer logging
by MenTaLguY 01 May '06

01 May '06

I've just added another debugging category to the debug logging code, so now object finalization is reported in the log. Finalization is a special step taken before freeing those objects which the collector cannot automatically clean up (e.g. because they need to release non-collector-managed resources). Classes with finalizers include SPDocument and SPDesktop. Try it out with latest SVN: INKSCAPE_DEBUG_LOG=debug.xml INKSCAPE_DEBUG_FILTER=REFCOUNT,FINALIZERS src/inkscape Open some documents, close them, and before closing the last one, go to the "About Memory" dialog and click "recalculate" a few times to make sure that a garbage collection pass gets run. Then look at debug.xml. You can see not only when the finalization of an object happened, but also what debugging events (in this case refs/unrefs) happened during its finalizer. -mental

2 3

[Fwd: Invitation to Participate in Summer of Code 2006]
by Bryce Harrington 01 May '06

01 May '06

Hi All, I've gone ahead and indicated our interest in participating in this year's Google Summer of Code. Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better! Bryce ----- Forwarded message from Leslie Hawthorn <lhawthorn@...819...> ----- Date: Fri, 14 Apr 2006 12:43:36 -0700 From: Leslie Hawthorn <lhawthorn@...819...> To: bryce@...961... Reply-To: lhawthorn@...819... Subject: Invitation to Participate in Summer of Code 2006 Hello Bryce, *ahem* Sorry about that - we'd like to invite Inkscape to sign up! Google is launching the Summer of Code program again this year and we would like to invite Inkscape to sign up to participate. You can peruse our [1]Mentor FAQ and [2]Terms of Service on the [3]Summer of Code site for more information on this year's instance of the program. If you would like to participate in Summer of Code 2006, please email back with your [4]Google Account information and we will use this information to create the first administrator account on the SoC site for Inkscape and send you instructions for accessing and updating the site. We look forward to working with you again during this year's Summer of Code! Cheers, LH -- Leslie Hawthorn Open Source Program Coordinator Google Inc. References 1. http://code.google.com/soc/mentorfaq.html 2. http://code.google.com/soc/tos.html 3. http://code.google.com/soc/ 4. https://www.google.com/accounts/ManageAccount ----- End forwarded message -----

22 66

Background Image and Drag to Install (was Re: [Inkscape-devel] new packaging for OS X)
by Ben Fowler 30 Apr '06

30 Apr '06

On 24/04/06, jiho <jo.irisson@...400...> wrote: > On 24 Apr 2006, at 13:59 , Ben Fowler wrote: > > On 24/04/06, jiho <jo.irisson@...400...> wrote: > >> Hi all, > >> > >> [ snip ] > > > > Could I underline that this is more than eye-candy: It is best > > practice to have a background image, showing that > > the way to install the application is to drag it to the folder of > > your choice. It is also advisable to somehow indicate > > where the application now is, to wit that the user will have to open > > the Applications folder (perhaps with Cmd-Shift-A) > > to see where they put it. ... > > so you advise not to use the symlink to Apllications but rather to > make the user open Applications (or anything else) and put inkscape > there? Well, I didn't mean to go into quite such a detail, but if you did want an opinion from me, I would be a little against it. (Does anybody else do this?). Some people (most people) want to put apps in the System wide Applications folder, some people put apps in their ~/Applications folder - necessary if you do not have write permission to the System wide Applications folder, and some people plonk new apps onto their Desktop to try out, and then transfer to the proper place when they have checked them out. I wouldn't expect a naive user to understand dropping an icon from part of a disk image to another. The problem is making the instructions brief and multi-lingual. My guide is this page which has aged very well: http://www.g2meyer.com/usablehelp/dmggfx.html , > >> I'll be unavailable for the next two months so I won't be able to > >> produce Inkscape dev builds for the testing phase of the release, nor > >> will I be able to package 0.44. I guess people will be available to > >> do it. If this new packaging is ok to everybody and worth bothering, > >> I'll modify the wiki to explain how to do it and somebody (Michael? > >> Ted?) could take over the builds. > > > > I think that they key to this is that there should be one person > > nominated to produced 'blessed' builds. FWIW, I have had to make a > > few modifications to the methods on the wiki, and I > > doubt that many people are producing Mac builds. This does not matter > > provided that one person can produce official builds - interested > > parties can download and test those. > > I agree with you. I'll be happy to be the one to produce the > "blessed" builds ;-) I just cannot do this for a while and I just > need someone with a 10.4 machine to take over for two months (BTW, I > mixed up the names and wrote Ted instead of Ben earlier. Even if you > work on 10.3, do you have a 10.4 machine somewhere?). Sure, if you can give brief instructions, on how to produce stripped builds, how to smoke test and how to upload, I will do this, but it is possible that there are people here who could do a better job, and I won't be offended to be relieved of this duty, if necessary! Ben

6 12

Google Summer of Code projects - update!
by Bryce Harrington 30 Apr '06

30 Apr '06

Hi all, I've cleaned up the list of ideas for summer of code projects, to elaborate on what the task is, why it's important, and how (in general) it should be done. I also took a stab at identifying mentors for many of them. http://wiki.inkscape.org/wiki/index.php/Googles_Summer_Of_Code Please take a look and make sure I haven't completely misrepresented the ideas (I had to make guesses about a lot of stuff). There's also a few ideas listed at the bottom that I didn't understand well enough to flesh out; feel free to write those up in more detail. Also, if you would be willing to be a mentor for one of the ideas with a TBD mentor, please feel free to add yourself to the idea. Bryce

1 0

Developers: Refcounting
by MenTaLguY 30 Apr '06

30 Apr '06

I've finally gotten around to writing some developer documentation about memory management. Since nearly all of the memory leaks I have ever had to fix were related to refcounting in some way, I decided to start with an article about refcounting. The latest version of this article is available in SVN as doc/refcounting.txt. Please let me know if anything is unclear or incomplete. Hwæt! --- INTRODUCTION Many objects in Inkscape have lifecycles which are managed by "reference counting". Each such object has a counter associated with it, which is supposed to reflect the number of outstanding references to it. When that counter falls to zero, the object can be freed. This releases the programmer from worrying about having freed an object while somebody else is still using it (or someone else freeing while you're using it!). Simply "ref" the object (increment the counter) to stake your claim, and then "unref" it (decrement the counter) when you don't need it anymore. The ultimate decision to free the object is made safely behind the scenes. You should "ref" an object whenever you plan to hold onto it while transferring control to another part of the code (which might otherwise end up freeing the object out from under you). REFCOUNTING FUNCTIONS Ref and unref functions are provided to manipulate object counter (and make the final decision to free the object for you), but their names will vary depending on the type of object. Examples include g_object_ref()/g_object_unref() (for most GObject-based types), sp_object_ref()/sp_object_unref() (for SPObject-derived classes), and GC::anchor()/GC::release (for garbage-collector managed objects deriving from GC::Anchored -- more on that later). [ note: for code underneath the Inkscape namespace, you need only write GC::anchor(), but in other code you will need to write Inkscape::GC::anchor(), or import the GC namespace to your .cpp file with: namespace GC = Inkscape::GC; Consider this encouragement to start writing new code in the Inkscape namespace. ] REFCOUNTING POLICY Refcounted objects start with a reference count of one when they are created. This means that you do not need to manually ref one that you've just created. However, you will still be responsible for unreffing it when you're done with it. This means that during the lifetime of an object, there should be N refs and N+1 unrefs on it. If these become unbalanced, then you are likely to experience either transient crashing bugs (the object gets freed while someone is still using it) or memory leaks (the object never gets freed). As a rule, an object should be unreffed by the same class or compilation unit that reffed it. Reffing or unreffing an object on someone else's behalf is usually a recipe for confusion (and defeats the point of refcounting, really). If you pass someone a pointer, they should be the ones responsible for reffing it if they need to hold onto it. Similarly, you shouldn't try to make the decision to unref it for them. When you've unreffed the last ref you know about, you should generally assume that the object is now gone. CIRCULAR REFERENCES One disadvantage of reference counting is that a naive application of it breaks down in the presence of objects that reference each other. Common examples are elements in a doubly-linked list with "prev" and "next" pointers, and nodes in a tree, where a parent keeps a list of children, and children keep a pointer to their parent. If both cases, if there is a "ref" in both directions, neither parent nor children can ever get freed. Because of this, circular data structures should be avoided when possible. When they are necessary, try only "reffing" in one direction (e.g. parent -> child) but not the other (e.g. child -> parent). This can sometimes be trickier than it sounds -- circular references don't have to be direct to cause problems. A simple example of an indirect circular reference would be a circular singly-linked list, where the "last" element in the list points back to the "first". In that case, unidirectional reffing isn't sufficient; you'd have no choice but to delegate ref handling to some object which encapsuled the circular list, reffing and unreffing entries as it added and removed them. ANCHORED OBJECTS The garbage collector cannot know about references from some types of objects: * Gtk/gtkmm widgets * SPObjects * other GObject-derived types * Glib data structures * STL data structures that don't use GC::Alloc To accomodate this, I've provided the GC::Anchored class from which garbage-collector managed classes can be derived if they need to be referenced from such places. As noted earlier, ref and unref functions are GC::anchor() and GC::release(), respectively. For most refcounted objects, a nonzero refcount means "this object is in use", and a zero refcount means "this object is no longer in use, you can free it now". For GC::Anchored objects, refcounting is merely an override to the normal operation of the garbage collector, so the rules are relaxed somewhat: a nonzero refcount merely means "the object is in use in places that the garbage collector can't see", and a zero refcount asserts that "the garbage collector can now see every use that matters". While GC::Anchored objects start with an initial refcount of one like any other refcounted type, in most cases it's safe (and convenient) to GC::release the object immediately upon creating it. This is because the garbage collector can see references to the object from parameters or local variables. Trust the collector. One final note: when code is converted from pure refcounting to garbage collection with GC::Anchored, refs and unrefs between GC::Anchored objects should be removed. Refs are no longer necessary, and when circular references are present, reffing will lead to memory leaks. Normally (unlike pure refcounting) the collector has no problem with freeing circular references, but GC::anchor()ing a reference the collector can already see overrides the collector's judgement.

3 6

[Fwd: Re: [Inkscape-devel] Added CREATE support for gradient, pattern, swatches directories]
by Jon Phillips 30 Apr '06

30 Apr '06

-------- Forwarded Message -------- > From: Jon Phillips <jon@...235...> > To: Joshua Blocher <verbalshadow@...400...> > Cc: inkscape-devel(a)lists.sourceforge.net, create@...626... > <create@...626...> > Subject: Re: [Inkscape-devel] Added CREATE support for gradient, > pattern, swatches directories > Date: Sat, 29 Apr 2006 15:13:39 -0700 > > On Thu, 2006-04-27 at 22:43 -0600, Joshua Blocher wrote: > > I add support for the above directories for Linux and Win32, no Mac > > support yet as the directories are not final yet( according to the > > wiki), but as soon as it is i will add it. > > > > This needs some testing to make sure it works as expected. They are > > setup as fallback directories to the normal Inkscape directories. > > > > Any Problems please let me know. > > > > verbalshadow > > Joshua L. Blocher > > > > Heya Josh, could you add to the CREATE wiki the level of support you > added to Inkscape: > http://create.freedesktop.org/wiki/index.php/Shared_resources_spec_support_… > > Also, please add any other level of support here: > http://create.freedesktop.org/wiki/index.php/Shared_resources > > I also updated the latest spec with the suggestion for where to look on > MAC OS X: > http://create.freedesktop.org/wiki/index.php/Shared_resources#Proposed_chan… > > Jon > -- 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) Creative Commons (www.creativecommons.org) San Francisco Art Institute (www.sfai.edu)

1 0

PATCH: Export dialog improvements
by Jonathon Jongsma 30 Apr '06

30 Apr '06

Hi all, I've attached a patch to improve the look of the Export dialog window (mostly following the guidelines of the GNOME HIG and somewhat inspired by this article: http://www.gnomejournal.org/article/44/three-simple-tips-for-interface-desi…). While I was modifying the layout of the window, I couldn't help but move some of the widgets to gtkmm since I find it so much easier to write and to understand than GTK+. I know Inkscape uses some gtkmm, but I know you also use a lot of plain GTK+. I don't know if the goal / policy is to move more toward gtkmm, so I'm not sure whether you'll appreciate my gtkmm-ification or not :) Of course, this was by no means a complete gtkmm-ification, it's very incremental. In any case, if this sort of patch is welcomed, I may work on a couple other dialogs that could use a bit of improvement as well. A couple of notes about the patch: Most of the GTK+ widgets that I replaced with gtkmm widgets were being allocated with gtk_*_new() but I didn't notice them being freed anywhere. So my code follows the same pattern. I'm not particularly familiar with the code-base of Inkscape, but from what I was able to tell, these kinds of dialogs are basically singletons that are managed by some sort of dialog factory. So while we aren't really keeping track of these widgets that are getting allocated, there's not much danger since they'll only be instantiated once and live for the life of the application (??). Am I understanding this more-or-less correctly? Or am I way off? I should also add that this patch changes some translatable strings by adding some Pango markup to the 'section headers'. Is this the accepted way to do this or is there a better way (i.e. just marking the words between the markup as translatable)? BTW, I'm not subscribed to Inkscape-devel, so please cc me on replies. Jonner

2 2

[elliott.bignell@...1255...: Re: [Clipart] Use of ClipArt in HeadCase]
by Bryce Harrington 29 Apr '06

29 Apr '06

----- Forwarded message from Elliott Bignell <elliott.bignell@...1255...> ----- Date: Sat, 29 Apr 2006 10:54:25 +0200 From: Elliott Bignell <elliott.bignell@...1255...> To: clipart@...626... Subject: Re: [Clipart] Use of ClipArt in HeadCase Couple of mails that should have gone to the group and I sent to Bryce instead. (Duh.) : 1) FYI this is an example of evolved shapes from the HeadCase gallery: http://www.loanedgenius.com/evolution.gif /////////////////////////////// 2) Yes, I couldn't just drop it in fully-formed right now. Firstly, conversion to SVG is a new area for me and I suspect the learning curve is fairly steep. The components in question render to a Windows DC. Secondly, they are COM components and will need some adaptation if they are to run cross-platform. I've set the mutation rates to levels that are really macromutations, which would offend an evolutionary purist, but that's a trivial thing to alter. Also, I deliberately used COM components with a common interface which can be loaded from a list in the registry, in order for third parties to be able to create their own components. I think that feature would be well worth retaining. The evolutionary aspect works on the same principle as Richard Dawkins' "biomorphs" - the component itself generates a set of 25 "descendants" which are displayed in a gallery exactly like all the other ClipArt. When a descendant is selected, the component is notified of the choice of a numbered descendant and adopts its properties then renders itself AND a new set of descendants. Not rocket science, really. What remains to be done is to convert the primitives such as flower and eye to a composite pattern that can be aggregated into whole faces and plants, or whatever. Then it will be really powerful. I'll start working out what is needed in a public release for people to be able to work with the components. Best wishes... Elliott ----- Original Message ----- > > Presently, Inkscape is getting ready to do a release, and it'll be a > month or two before it's back to a state where brand new features can be > added, but I'm guessing you'd want a bit of time to rework things > anyway? > > Bryce > /////////////////////////////// I'll seek the lists out and participate. Now that I know someone appreciates the work, I feel a bit more motivated! The evolutionary side is pretty standard stuff - Dawkins described the pattern in The Selfish Gene, which just had its 30th anniversary. For a more in-depth discussion of evolutionary software, the standard work appears to be "Genetic Programming", by Banzhaf, Nordin, Keller and Francone. The flower shapes I came up with myself and coded by hand. There are a set of numeric parameters that are tweaked up and down within limits in the "Mutate" method, and these specify the number of whorls, the way the spacing of whorls changes and a set of numbers that define how the Bezier curves that form the petals are formed. Basically it draws two symmetrical Bezier curves to form a petal, rotates a little around the axis and moves inward either immediately or after a whorl has been completed and then does it again after applying the appropriate transformations.I was hoping to get quite complex results, but the orchid and ammonite shapes were a pleasant surprise. There's another aspect that would be worth retaining, and that is that the shapes can take Decorators. Everything in HeadCase is basically assembled out of decorators, and these include fills and outlines, so one can apply colour schemes to the pictures produced by the evolutionary process. Also, HeadCase inherits properties down the tree structure and is intended eventualy to support parameterised XML templates, whch has interesting implications for using SVG. Okay, I'll get thinking on how to publish this stuff. Cheers... Elliott ----- Original Message ----- > > Wow, these actually look surprisingly good. You should send this url to > the openclipart and inkscape mailing lists, I think folks would be > impressed by them. > > Btw, how did you come up with the algorithm to do these? Looks > extremely cool. > > Bryce > _______________________________________________ clipart mailing list clipart@...626... http://lists.freedesktop.org/mailman/listinfo/clipart ----- End forwarded message -----

1 0

New translators mailing list for Inkscape
by Bryce Harrington 29 Apr '06

29 Apr '06

Heya all, We've set up a brand new mailing list for Inkscape translators. You can subscribe to it here: https://lists.sourceforge.net/lists/listinfo/inkscape-translator The purpose of this list is to discuss localization and translation issues of Inkscape and its documentation. Here's a sampling of specific topics the translators have proposed discussing on the list: - where are we ? (what are the translation status ? Which languages need some more commitment...) - where do we (translators) usually face some issues ? (specific vocabulary, synchronization with development...) - get some best practices from the ML and then, write them down on the wiki - share experiences on specific blocking points - take a look at the various tasks, on different levels : (core software strings, tutorials, text docs, web pages...) Bryce

3 2

refcount bugs: one down...
by MenTaLguY 29 Apr '06

29 Apr '06

I've just fixed one refcount bug in UI::View::View, so we don't appear to leave dangling refs on SPDocuments anymore. However, someone's still leaving a dangling ref on SPRoot, so we're still leaking quite a bit of memory after a document's closed. I'll stab at it further tomorrow. -mental

1 0

Re: [Inkscape-user] Question regarding draw mode
by bulia byak 29 Apr '06

29 Apr '06

On 4/28/06, Jon A. Cruz <jon@...18...> wrote: > Except there's no visual feedback to tell what's going on... We discussed the way to give such feedback long ago, and I had an idea, but was too lazy to file a RFE, so now I just implemented it so it's not forgotten :) Now each object-creating tool has a standard style widget at the right end of its controls bar, reflecting the style that the next created object will have. This gives you an idea of your "brush" before you start drawing, and it updates when you click on the palette with nothing selected. Both last-set and tool-fixed styles are correctly shown, and the widget is updated when you switch between the two. Now, this thing also needs a text label before it, but I think this could wait until our toolbars are not fixed-width and thus adding stuff does not blow up the window. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

Re: [Clipart] Use of ClipArt in HeadCase
by Bryce Harrington 29 Apr '06

29 Apr '06

On Fri, Apr 28, 2006 at 06:10:54PM +0200, Elliott Bignell wrote: > Hello, Nicu, > > Thanks for the clarification. My feeling is that even if nothing is > expected, something is due. I closed the company due to limited sales and am > now only developing HeadCase as a hobby and marginal source of income, but > it is still technically a commercial app. I may in fact go Open Source to > breathe some life into the project, but I invested a great deal of > perspiration in it and effectively admitting that it will never make me a > living is a painful step! Still, I feel that it is unique enough to be worth > saving and Open Source could be the way. Just for your information, it is a > Windows-only app written 98% in C++ using ATL COM with a thin VB wrapper, is > largely undocumented and in a few areas in need of serious refactoring, and > was created with the best of object-oriented intentions but has in a few > places sprawled! It will need tidying up. > > What I could perhaps do is open the evolutionary algorithm and associated > picture-creation objects for re-use, perhaps in Inkscape, and perhaps with > help adapt it to write SVG files for the archive? That'd be a wonderful way to make a contribution. There's a couple different ways it could be integrated into Inkscape: One is to add the code to inkscape itself, which would make it fairly easy to create GUI dialogs and so forth for the user to set options. The other is to implement it as an extension program, in which case it distinct from Inkscape itself, but can be used with Inkscape. In either case, I think this would be quite handy in Inkscape, and I'd encourage you to investigate it further. Presently, Inkscape is getting ready to do a release, and it'll be a month or two before it's back to a state where brand new features can be added, but I'm guessing you'd want a bit of time to rework things anyway? Bryce

1 0

Would a translator mailing list be an appropriate tool ?
by Matiphas 28 Apr '06

28 Apr '06

Hi Inkscape developpers sorry for polluting the dev-ML, especially in the beginning of a release cycle, but i'd like to ask you a question : would a translator mailing list be an appropriate tool ? I guess it may help a little bit, but I'm not sure it would be a decisive tool. My main issue with translations is the fact that the software, strings and docs undergo the most important changes only a few days before the release and this does not give a lot of time to translators. Updating strings is quite ok, as strings evolve parallely to feature development. But docs (such as tutorials and keys) can become a very heavy workload to be dealt in a very few days. I have been very sorry not being able to bring an update of the keys for last release, and i would be very disappointed not being able to offer this for 0.44 release (especially because this release looks like the very best one up to now). I'm very happy to see that - developpers bring lots of nice features and a stable/portable software - translation is taken care of in the release cycle - documentation is taken care of during the same release cycle I'd be even happier the doc translation was also integrated in the release cycle so that users can get a huge package (software + translation of the software + doc + translated doc + extensions + doc for extensions ...). Regards, matiphas

9 16