Hi Alexander,

The normal way to submit patches is via our bug tracker [1]. Look at the top right of the page for the link to submit a report. Since this appears to be documentation, don't waste too much time looking to see if this is a duplicate report.

As for developing new features, yes, it has become somewhat common practice for people to do their work in a branch and then push that to Launchpad for testing and eventually proposing the changes for a merge.

Others will need to speak up about status of German translations.

[1] https://bugs.launchpad.net/inkscape

Welcome to the community!

Cheers, Josh

On Fri, Nov 14, 2014 at 4:17 PM, Alexander Brock <a.brock@...2965...> wrote:

Hi,

I started reading parts of the source code and added some comments, see the attached patch file. Somebody who actually knows what all the code is doing should check if I got everything right before this is used, though.

What's the preferred way for developing new features? Should I create a local branch or something like that?

Is there need for German translators? I'm a native speaker.

Alexander

---

Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Wed, 2014-12-03 at 21:59 +0100, Alexander Brock wrote:

Path->All Objects to Path This recursively convertes strokes to paths. If the object has a fill and a stroke it is duplicated for one copy the stroke is converted to a path, for the other the stroke ist set to none. Therefore the visual appearance doesn't (shouldn't) change.

I don't think this is the right menu item name.

Firstly, wouldn't it be Path->All Strokes to Paths, not objects.

Secondly, I'd think about making some of our functions do the right or expected thing with multiple selections and groups. There's no reason not to convert every object to path or stroke to path. Our code is just hyper restrictive about it's inputs sometimes.

I'd obviously like to see fewer menu items overall :-D as it would mean we're getting closer to optimal design instead of adding items when features go in.

Martin,

Hi Alexander.

Please have in mind this: http://tavmjong.free.fr/blog/?p=1090 Also, +1 to unlink clones recursive.

Regards, Jabier.

On Thu, 2014-12-04 at 16:21 +0100, Alexander Brock wrote:

On 04/12/14 05:55, Martin Owens wrote:

...

I don't think this is the right menu item name.

[...]

I'd obviously like to see fewer menu items overall :-D as it would mean we're getting closer to optimal design instead of adding items when features go in.

I agree, I just added the menu so I have something distinct I can play with without breaking the existing feature. I'd like to make it the default behaviour of "Stroke to Path" to recurse into groups and duplicate objects which are filled and stroked, if there are no objections.

I'd also like to make "Clone->Unlink Clone" recurse into groups if there are no objections.

Alexander

---

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

You can find this property -paint-order- on doxygen in the SPStyle. You need a special flag at compile time to allow paint order CPPFLAGS='-DWITH_SVG2', and for the moment you need to put this paint-order value in the XML editor, no GUI.

About the markers... not sure your question but none and normal - no special case, rest in the order of appear from bottom to top, no apper over as normal. ej: paint-order:marker stroke ->marker bottom, stroke middle and fill top paint-order:marker -> marker bottom, fill middle as normal(bottom) and stroke top as normal (over fill)

Regards, Jabier.

On Thu, 2014-12-04 at 17:14 +0100, Alexander Brock wrote:

On 04/12/14 16:40, Jabier Arraiza wrote:

...

Hi Alexander.

Please have in mind this: http://tavmjong.free.fr/blog/?p=1090

Can you tell me how to find out if the fill is painted on top of the stroke in Inkscape? Also I'll need to figure out if I handle markers correctly.

Alexander

---

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Actually, it is already enabled in 0.91. No need to set a flag.

Thanks for the info.

About this, you know wath features need flags for 0.91 and if still there is for 0.92?

Thanks in advance, Jabier.

Thanks!

On Fri, 2014-12-05 at 09:57 +0100, Tavmjong Bah wrote:

On Thu, 2014-12-04 at 23:31 +0100, Jabiertxo Arraiza Cenoz wrote:

...

...

Actually, it is already enabled in 0.91. No need to set a flag.

Thanks for the info.

About this, you know wath features need flags for 0.91 and if still there is for 0.92?

At the moment there is nothing enabled by -DWITH_SVG2.

There are new filter effects blend modes and compositing modes that need the flags:

-DWITH_CSSBLEND -DWITH_CSSCOMPOSITE

And the GUI for meshes requires:

-DWITH_MESH

Note: there is a small syntax change to meshes that I haven't made yet.

Tav

On 04/12/14 17:10, Martin Owens wrote:

If it's possible to add the feature to the selection code such that the code for navigating and selecting appropriate objects isn't duplicated, that would be great.

ok.

Maybe something like:

selection->forEachSelectedObjects(callable_method); selection->forEachSelectedChildren(callable_method);

We need to define which parameters the callable_method should take and if it should be called for the entire selection at once or on individual objects etc. I'm new to Inkscape so probably somebody else should figure that out, I'm likely to forget corner cases or something.

Alexander

On 04/12/14 18:27, Ryan Lerch wrote:

On 12/03/2014 03:59 PM, Alexander Brock wrote:

...

New features: Path->All Objects to Path

This would be an awesome feature.

It's already implemented, you can try it if you check out my experimental branch and compile it.

Maybe a name like "Fill and Stroke to Paths" might work? I assume that the resulting "fill" object doesn't include the 50% of the fill that is under the stroke?

Currently the resulting filled object does include these 50%. If that's not desired I would need to duplicate the "stroke" (which was converted to a path) and subtract it from the "fill". I don't want to do that (at least not by default), because the difference operation tends to create (very small) gaps between the objects. For example, create two ellipses, duplicate the top ellipse, subtract it from the lower ellipse, take the union of the resulting two objects and break the path appart => I ended up with four objects, the union of two ellipses and two very small objects.

These small objects interfer with my applications, so I want to avoid them.

If you want to get rid of the overlap just use the "remove overlap" function as soon as it works :-)

...

Object->Clip->Intersect This recursively replaces clipped paths by the path intersected with the clip path.

IMHO, This might make more sense to make Path > Intersect work on multiple objects. i.e. the top object is duplicated and intersected with each object individually underneath.

The intersection method already works with multiple objects, the result ist the intersection of all selected paths which makes perfect sense to me and I wouldn't change that.

The reason i suggest this is that clipping also works on bitmaps, so having an option to intersect a clip path might be a bit odd when it doesn't work. Also, this same working on multiples behavior would work for Path > Difference too -- so you can "punch a hole" in multiple objects, and Path > Division, where you can cut multiple paths up with a single action.

I currently don't need difference / division / cut for more than two objects and I'd like to fix the "remove overlap" function first but I can implement more of these (more complex) boolean operations later.

Alexander