Whoops, sorry Tom and Ted, for some reason I parsed 'T' as 'Ted' instead of 'Tom'. Obviously I shouldn't write email without having at least one cup of coffee in my system. ;-)

Please ignore my previous response in its entirety. I'll try again...

On Sat, 22 Nov 2003, Bryce Harrington wrote:

On Sat, 22 Nov 2003, T Ingham wrote:

...

On Nov 22, 2003, at 2:04 PM, Bryce Harrington wrote:

...

Hi all,

Looking at the planned tasks for this release it seems we're quite close. Plus, a lot of work has been done, so I think the codebase is getting ripe for a release within a week or two.

For those working on things to go into 0.36, could you reply and let us know your status?

Thanks, Bryce

Lo',

I apologize for not being around lately, but I got a couple of new contracts and really want to make sure christmas is taken care of. Next week should be fairly light for me up till wed. ( at which point I'm driving to NY for 3 days )

Please let me know if there's anything I can help with mon/tues/wed.

-t

If you feel like doing work in the codebase, then fixing one or two of the issues Bulia identified are the best application of your effort. (Or fixing any bug in the bug tracker that looks critical.)

If you would rather focus on non-coding tasks, then helping with the verification and copying of Sodipodi bugs to the Inkscape tracker would help us get that task squared away.

While not required for 0.36, another highly beneficial task that will help us out in coming releases is to add explanations for various functions. Select a subdirectory or set of files in the codebase and for each function write a definition like this:

/** my_function(arg1, arg2) * * This routine blah blah... * On failure, the routine will yada yada... */ void my_function(int arg1, int arg2) ...

These comments will get picked up and parsed by Doxygen, and so will make the online documentation of the codebase useful.

I'm doing the above for sp-root.* and sp-path.* as part of my arrowhead work.

Bryce

On Mon, 2003-11-24 at 09:51, Kees Cook wrote:

How does doxygen parse those kinds of comments? Or rather, what format is required so that they'll get picked up correctly?

Probably best to just show.

Code: http://cvs.sourceforge.net/viewcvs.py/inkscape/inkscape/src/module.c?rev=1.5...

Doxygen: http://www.inkscape.org/doc/doxygen/html/module_8c.php

Basically it just pulls the text out and makes it look like a document.

--Ted

Bryce Harrington wrote:

The two asterisks starting the comment are what clues it in that it's a comment. Technically the first line isn't needed since the function name and params automatically get picked up.

That's also the norm in the Java world with Javadoc.

Start a comment with two asterisks "/**" and then space or newline. Next have a single sentence summary of the class or method, terminated with a period and then a space or a newline. Follow with a more detailed description. close the comment.

I definitely recommend against including the function name and args, since classically that's a major point to get out of sync with the code, so it's best left to autodetection.

On Tue, 25 Nov 2003, vellum wrote:

Ted wrote:

...

Let's play this by ear. Is it time to choose a release date? Here's the things that I see as pending for the release (in no order):

...

1. Modules stuff above
2. SDI Interface changes
3. Arrowhead stuff
4. Keybindings/mousewheel

Does this mean that the Win32 stuff is all complete?

Erik

No, Mael identified the changes necessary to get it to work on Win32 but no one is working on reviewing them and integrating them into the codebase. We could really use some help with that.

I posted Mael's comments to a ticket in the patch tracker in hopes someone will take this item.

Bryce

Ted Gould wrote:

2. Action/Verb - I want to remove the UI code and use actions/verbs.

This is about 50% done right now. This should mean that if people want to play with the UI they shouldn't have to understand modules at all.

This sounds good. Separating the GUI code from the execution is extremely important for several reasons. We have done this for a couple of our projects to far, making a module called an ActionManager, to provide a single point for configuration. It allows:

o Scriptability -- If this is to fully implement SVG, it needs to be scriptable via DOM, such as plugging in Javascript. o Accessibility -- Input/output aids can be integrated in a single location o Multi-user (future?) -- User events could be intercepted and sent to more than one copy of Inkscape for collaborative work, like a shared whiteboard

On a different note, I am still working on some code for thinning nodes along a subpath, but it is not done yet.

A general-purpose utility method for reversing the direction of a node path or subpath would be helpful, too.

Bob

T Ingham wrote:

On Nov 24, 2003, at 3:38 PM, Bob Jamison wrote:

...

Ted Gould wrote:

On a different note, I am still working on some code for thinning nodes along a subpath, but it is not done yet.

Bob

Perhaps if not and or until we can see some sort of pressure sensitivity in Inkscape/X11 we could have a timer running on painting operations ( in ink/brush ) modes that defines the size of a node. Lingering longer in one place would create a node with a thick width, quickly moving away from that area would thin the path.

-t

What I have been considering has been to provide a tool or dialog that could thin out the number of nodes along an -existing- subpath, while keeping the rendered line as close an approximation as possible to the original.

For example, on a continuous chain of bezier segments, it is required that adjacent segments not only have a pair of co-located endpoints, but also that the control handles connected to those endpoints be parallel.

Here is what I mean: http://troi.lincom-asg.com/~rjamison/files/thin.png

For (A), we have a subpath with 3 nodes, consisting of two Bezier segments of degree 3 meeting continuously at the center point.

What I would like to do, is for each candidate pair, ignore the center point and consider the path to be a single 4th degree curve. This curve would then be reduced in degree to make the 3rd degree approximation at (B).

This page has an excellent description of degree reduction which I would like to use: http://anziamj.austms.org.au/V36/part4/Park.html

The tool or dialog would only allow this replacement to occur if it is possible within the bounds of a specified error level. (least square, maybe?)

For non-continuous joints between segments, and for straight line segments, this can be ignored. (Or maybe approximated with new bezier segments?)

Such a tool would be good for reducing the number of points resulting from freehanding, or maybe the results of some autotrace tool. Imagine reducing a drawing cluttered with 128 points to 64 with a single click.

Anyway, this is just what I have been looking at.

Bob

Nathan Hurst wrote:

Bob Jamison wrote:

...

What I would like to do, is for each candidate pair, ignore the center point and consider the path to be a single 4th degree curve. This curve would then be reduced in degree to make the 3rd degree approximation at (B).

I can't help but think that this is a solved problem with a much more elegant solution. I think bezier's are essentially bernstein polynomials, so there is undoubtably lots of work on adjusting approximations. Having said that, I haven't been able to find anything remotely helpful.

Conceptually it seems that you could replace 3 segments with 2 with a smaller error term, or 128 with 127. There may be a MDL type algorithm for it too.

Keep looking though :)

njh

Another way, I think, would be to map each curve segment to approximating line segments using the Douglas-Peucker algorithm, and then redraw the subpath of Beziers from scratch. This might work, but it just -seems- to be messier.

Yes, the proportion of deleted nodes might be adjustable, with a spinner or slider. Either by floating point percentage, or an integer scaling using Bresenham's scaling algorithm.

Bob

p.s. -- List Admin: Is it possible to add the list's address as a Reply-to: addee on outgoing messages? It would make responding to the list a bit easier.