- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Powerstroke requests
by Valerie 18 Jan '12

18 Jan '12

If I may add a few words about interface... Inkscape now has several pretty fun options for path shapes: - Simple line - Pattern along path - Powerstroke - Sketch brush - [anything I might have missed. There will probably be future options too] Now, for the "shape" drop-down I rarely use the presets because they are rarely the exact width I need them at, it's easier to create the right shape and copy it. So, how about the following? Shape: - Line - Thick stroke (<- powerstroke) - Sketch brush - Clipboard - Custom (insert drop-down of shapes you've saved for Pattern along Path) It's rather unfortunate that Inkscape's tool control bar is static, otherwise I'd recommend for common options (like width and repeat options in Pattern Along Path) to appear depending on the shape you've selected. (though in the meantime, can someone please add dashes and markers to the tool option bar? Having to hunt through two layersof Fill & Stroke dialogue each time is a bit annoying... also, a button to match marker colors to stroke color rather than hunting through the menus, please? Some of us do a lot of graphs in Inkscape...) More generally, I'd like to see some proper of sorting of LPEs eventually: - Path shapes can be integrated into pen and other tools - Effects like Gears seem like they belong in Extension -> Render - I'd also Really like easier and on-canvas access to some transformations that would probably be used more often if access were easier (not only LPE): Envelope, Perspective, and Envelope deformation. Couldn't we include them as a drop-down options (like with pen and Shape) in the Select and Transform tool? I can do mock-ups.

5 10

cannot compile rev 10891 (Windows XP)
by alvinpenner 17 Jan '12

17 Jan '12

attempting to compile rev 10891 I get the following error message: Make error line 289: problem compiling: src/2geom/conicsec.cpp:1491:20: error: prototype for 'std::vector<Geom::Point> Geom::xAx::allNearestPoints(const Geom::Point&) const' does not match any in class 'Geom::xAx' src/2geom/conicsec.h:477:24: error: candidate is: std::vector<Geom::Point> Geom::xAx::allNearestPoints(Geom::Point) const - Alvin -- View this message in context: http://inkscape.13.n6.nabble.com/cannot-compile-rev-10891-Windows-XP-tp3677… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

3 2

Traversing nodes of a path in order
by Maximilian Albert 17 Jan '12

17 Jan '12

Hi all! After a long break I just had a quick play-around with some of the Inkscape code. At some point I needed to traverse the nodes of the selected path in the order in which they appar along the path, but I couldn't find out how to do it in the limited time I was able to spend. What's the correct/recommended way of doing this? Are there some examples on the wiki or somewhere else? Cheers, Max

5 8

Writing an extension
by Trever L. Adams 16 Jan '12

16 Jan '12

This relates to https://bugs.launchpad.net/inkscape/+bug/247463 and comment 37 in particular. I would like to be able to attach information to objects that are needed for high quality digitization. This includes stitch length and stitch direction. I am thinking of displaying the direction as gradient, although direction may be very complex. I am just learning about SVG so, I do not know if there are smart ways of doing this. (For example, think of a leaf, where you may have 20 different direction changes.) I also do not know XML very well (creating schema, etc). So, is there a standard way to extend SVG or embed such codes in SVG for a given object? How would I go about attaching buttons, etc. in the GUI? Can I have Inkscape view the direction code as a gradient for display (if an option is set)? Or, show the fill as lines going in that direction? (Again, this wouldn't be done in printing/export/etc., only in viewing with an option set.) I would like to do this in SVG and Inkscape since I believe both are scriptable and both can be used for print as well. (This is a project for both print and embroidery.) Additional request for information: Is it possible to define a custom color table? Embroidery machines usually have a fixed color table (which can be converted to various thread vendor product/color numbers). Is it possible to turn an outline on for an object and give it a different color than the object, or easily create an outline? Finally, is there a way to do "Ungroup repeatedly until there are no groups left, and convert objects to paths." as part of an extension (http://www.jonh.net/~jonh/inkscape-embroidery/) without modifying the original (as part of an export, etc.)? Thank you, Trever

2 1

nigthlies ppa
by Alexandre Prokoudine 14 Jan '12

14 Jan '12

Hi, Apparently https://launchpad.net/~inkscape-nightly/+archive/ppa turns up first in google for "Inkscape nightly", even though it's an outdated PPA. Could we please somehow redirect people to the real one? Alexandre Prokoudine http://libregraphicsworld.org

1 0

Extended input issues with later GTK2
by Jon Cruz 13 Jan '12

13 Jan '12

Just wanted to toss out a note that I think I've found a main problem with how Inkscape deals with extended input devices. The issue where they give no extended pressure, etc. on later GTK2, including that in Ubuntu 11.10, is due to missing event initialization. I'm trying to narrow it down a bit. Of course, there are still some other bugs that appear to give random garbage in the middle of extended input. There's a good chance that a simple work-around could even filter those out. So, the main thing now is to know if anyone is trying to use tablets currently and is tripping over GTK2 extended input problems. Speak on up and we might be able to get things at least passible soon. Thanks.

6 10

regression in current trunk (r10873) when zooming in/out
by ~suv 12 Jan '12

12 Jan '12

A recent commit (one of r10870-10873) has changed how the canvas gets redrawn (prior build r10869 is still ok): with my latest builds of r10873 [1], the canvas is not properly cleared when zooming in/out. Steps to reproduce: 1) open the attached file in Inkscape 2) zoom in closer and then zoom back out several times --> result: <http://imgh.us/regression-test-r10873-2-screenshot.png> (compare to <http://imgh.us/regression-test-r10873-2.svg>) ~suv [1] tested on Leopard and Lion: - Gtk+/X11 with cairo 1.10.2 (32bit, 64bit), debug + optimized - Gtk+/Quartz with cairo 1.11.2 (32bit), optimized

2 2

Re: [Inkscape-devel] Extended input issues with later GTK2
by Jasper van de Gronde 11 Jan '12

11 Jan '12

On 11-01-12 16:22, jbc.engelen@...2731... wrote: > ---- Jasper van de Gronde <th.v.d.gronde@...528...> wrote: >> I usually just download the latest TDM GCC from this site: >> http://tdm-gcc.tdragon.net/download >> I would recommend taking the 32 bit bundle installer. >> >> Any objections if I update the Wiki page to point to the site above >> instead of the direct download? > > Not at all. We should always be able to build with latest TDM GCC. > Done.

1 0

Re: [Inkscape-devel] NULL vs. 0
by Jon Cruz 09 Jan '12

09 Jan '12

On Jan 7, 2012, at 11:39 AM, Tomaz Canabrava wrote: > Stroustrup answer to that: > > Should I use NULL or 0? > > In C++, the definition of NULL is 0, so there is only an aesthetic > difference. I prefer to avoid macros, so I use 0. Another problem with > NULL is that people sometimes mistakenly believe that it is different > from 0 and/or not an integer. Actually, for a modern compiler NULL is not an integer. C++ did a bit of a change, and 0 gained special meaning. I believe that most of the systems where it made an actual difference are now gone, but it did. However... the main reason I made the code change is that when I updated to gcc 4.5.2, it started warning on that constructor. It complained that we were setting a pointer value into a non-pointer variable. So we probably have NULL defined as some pointerish macro or value and which should not be assigned to integer variables, while '0' is a magical constant that the compiler knows to just do the right thing with for both pointers and integers. '0' by the C++ language definition works in all cases, but NULL does not. This and the associated warning start to become very important for 64-bit code. Mixing integers and pointers leads to major problems. Bottom line, though, is that we need to remove warnings by fixing the code. The pointer assignments in that initializer could be changed to "NULL", but the integer ones need to stay changed to zero.

5 5

Janitorial tasks
by Kris De Gussem 08 Jan '12

08 Jan '12

Hi all I like to go on with the replacement of the deprecated wrapper functions in src/xml/repr.h with direct calls to their respective functions (as listed in the first section on http://wiki.inkscape.org/wiki/index.php/Janitorial_tasks). Any objections? Kind regards Kris

4 8