Segment Division

Originator: NO

Create nodes by doubleclick or by Ins, then break at these nodes if
necessary

Updated the add nodes extension to allow this for equal segments. See attached .py and .inx files for implementation.

So inductive, do we just need to replace the two addnodes files, or is there something else that needs to be done?

I installed them in the /share/extensions/ directory, and couldn't see a change in the menus when adding alongside the originals (as the default addnodes2). I also didn't see any change in the function of add nodes when I renamed all the references to addnodes2 to addnodes (both file names and contents) to directly replace the original files. I've even tried changing the <_name>Add Nodes</_name> to <_name>Add Nodes 2</_name> and various other similar tricks. No joy.

It's probably just me being dumb, but how do I get this to work? Using latest SVN trunk. Win XP SP2.

You should just be able to paste into the /share/extensions directory. I don't know what's going on there. I have two "Add Nodes..." entries in my "Modify Path" submenu, using those exact files. The second one for me is the new one. You did restart Inkscape, right?

if that isn't it, it look like the .inx file is incorrect, as Inkscape won't show it in the menu if that is wrong. I was going to reupload, but they are identical, and the uploaded copy works on my machine, so it cant be that. Same goes for the .py file.

All the .inx files in SVN were recently modified to use namespaces, and I think that's now a requirement for them to work in recent builds of Inkscape. But inductiveload's .inx file is modified from one in 0.46, and has no namespaces, which is probably why Rygle couldn't get it to work.

I've added the namespace stuff, changed "addnodes2" to "addnodes", and attached the result as a patch to SVN trunk. It appears to work, though I haven't tried doing much with it yet.

The patch for the .inx file really just adds a couple of parameters, but inductiveload also changed the tabs to spaces, so the patch is fairly large. Getting rid of the tabs seems a good idea, so I've left it like that.

Assigning to Aaron Spike, as he's the author of addnodes.py.

Added to trunk @ revision 18484. Marking fix committed as this hasn't been publicly released.

We use "Fix Released" as soon as a patch has been committed to SVN, so I'm adjusting the status. BTW, should Aaron still have a look at this or is it already approved?

I didn't commit it yet. But it is fine with me if someone else does.

Hi guys, just trying to get my head around all this.

I committed this and milestoned for release in 0.47, but I assumed that Aaron and/or a release warden would check it out before the proper release. I was trying to flag somehow that this is new and needs to be approved. That's why I set it as Wish List and Fix Committed, not Fix Released. Should I have instead marked it as Fix Released and nominated it for release 0.47? Or just leave any milestoning/nomination because it's automatically in? Seems like it won't get noticed by release wardens then.

I'm also unsure, but based on Maximillian's comments, but do some people feel that applying patches treads on toes if the bug is assigned to someone else? I merely wanted to get it into trunk so that people would find any problems with it. I've seen some good patches that didn't make it into 0.46 because they didn't get attention. Should I not commit patches when the bug is assigned to someone else? Please be frank, because I don't want to offend others.

Rygle wrote:
> Hi guys, just trying to get my head around all this.

No problem.

> I committed this and milestoned for release in 0.47, but I assumed that
> Aaron and/or a release warden would check it out before the proper
> release. I was trying to flag somehow that this is new and needs to be
> approved. That's why I set it as Wish List and Fix Committed, not Fix
> Released. Should I have instead marked it as Fix Released and nominated
> it for release 0.47? Or just leave any milestoning/nomination because
> it's automatically in? Seems like it won't get noticed by release
> wardens then.

There are no release wardens for 0.47 yet. Release wardens impose
marshal law during release times to make sure things get out the door in
a reasonable amount of time and without any avoidable nasty bugs. During
the normal development cycle we average contributors are in charge. If
you've been granted commit access the Inkscape community trusts you to
decide what goes into the tree.

> I'm also unsure, but based on Maximillian's comments, but do some people
> feel that applying patches treads on toes if the bug is assigned to
> someone else? I merely wanted to get it into trunk so that people would
> find any problems with it. I've seen some good patches that didn't make
> it into 0.46 because they didn't get attention. Should I not commit
> patches when the bug is assigned to someone else? Please be frank,
> because I don't want to offend others.

I think sometimes applying a patch assigned to another person could
possibly maybe tread on another person's toes perhaps. This time it
didn't. I grabbed this patch because the author had written me
individually about the change and because there doesn't seem like a lot
of people who want to deal with python patches. But I knew that I wasn't
going to get around to committing it until the weekend and it is very
important to have quick turn around on patches. This shows that we value
the work being done and encourages repeat contribution. Just think how
discouraging it is when I sit on a two line python patch that is
obviously fine. You're timing was excellent.

Feel free to commit a patch. As long as you do due diligence. Meaning:
You understand the issue it addresses. You test it locally to see that
it does address that issue. You do not notice any major regressions as a
result of it. Otherwise ask for a little clarification and help. And if
you feel comfortable, go ahead and assign bugs to yourself. :-) And,
yeah, it probably doesn't hurt to ask if the bug is assigned to someone
else. I know in my situation sometimes I don't comment everything I know
on the bug because I don't think of it. There might be some issue I want
to check into. So if you ask I'd be more likely to write that in the bug
comments. Not trying to hide info; I just don't think of these things
all the time.

Thanks for applying this patch!

Aaron

P.S. I'm copying Inkscape-devel to give people a chance to disagree with
me. :-)

Removed "Live Preview" option from Add Nodes, as it didn't work anyway. Revision # 18490.