- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Powerstroke presentation at LGM 2012
by Valerie 21 May '12

21 May '12

> So... how do other programs draw thick stroked lines? Well, Synfig also has thick line drawing: http://wiki.synfig.org/wiki/Outline_Layer Illustrator 5 also has a line thickness feature: http://www.video2brain.com/en/lessons/variable-width-strokes I'm not sure about the algorithms they use though. By the way, more feedback on Powerstrokes: - Closed-paths powerstrokes will often render strangely until you fiddle a bit with them. - Is it possible to either: a. Save the relative positions of the widths controls (to save the shape of the powerstroke) or b. Define the starting distance between the control point and the line center at least (basically when drawing very thin powerstrokes, the starting thickness can be a bit distracting)? I'm trying to come up with a mock-up for line style management, to easily save and access all sorts of presets collections: - Powerstrokes - Pattern along Path (I'm finishing a mock-up proposal for on-canvas Pattern along Path editing) - Graph lines (a few arrowed and dotted lines. They're such a pain to set and unset right now) - Calligraphy (save presets as now, but with visual previews!) - [insert custom collections. Maybe presets from other tools] They'll be accessed just like brush presets in MyPaint and Krita from a dialogue, except with longer previews. For Powerstrokes, presets would allow the user to access various settings easily. But I'm hoping that it would also be possible to save and access preset Powerstrokes shapes, or at least of varying widths. For example, suppose you're drawing eyelashes or hair highlights. You don't need to control the exact width of every line, but they do all need to be thin. See?

1 0

Re: [Inkscape-devel] Recursive Drawing
by Valerie 21 May '12

21 May '12

> Yes, there are always things that will take "too much" time, but > initially it's usually a good idea to think about what you'd really > want. If you start thinking too early about performance you often end up > with something that might(!) be fast, but isn't really what you want... > So ideally you start to think about what you want, then identify where > the performance problems might lie and try to fix that. That's true. In any case, I'll explore the UI concept of on-canvas templates some more, and see where it leads. > Have a look at laidout (http://laidout.org/). Of course! :)

1 0

SVG Path contains vertical bar |
by Ogla Sungutay 20 May '12

20 May '12

Hi guys, The path d attribute in Inkscape often contains a | character followed by one or two point coordinates. Does anyone know what this is used for? -- V. Ogla Sungutay, GUI Programmer www.lyciasoft.com *gtalk:* ogla@...2470... *g+:* g <http://plus.google.com/110038181712863996630>plus.to/Proclus *skype:* oglasungutay *twitter: *@proclus

2 2

Re: [Inkscape-devel] Recursive Drawing
by Valerie 18 May '12

18 May '12

> Don't let that worry you too much :) First of all, rendering a bunch of > shapes isn't necessarily that slow, and secondly, there are usually some > tricks to make the speed acceptable when it is. True, though I wonder if you'll still be saying that once people start stacking symmetry templates on top of tiling templates on top of perspective templates, with extrude templates in-between. What am I talking about? - A person draws half a window, then uses a symmetry template to make the other half. - Then drops that group onto a tiling template to make a whole bunch of windows. - Then drops That group onto a perspective template to make a wall full of windows. - And somewhere in-between, uses an extrude template to extrude windows, balconies etc. - He also drops an L-system templates to create vine-looking objects on-canvas. Then drops that onto the perspective template as well (vines along the wall). - On another side, he drops a whole picture (a poster) onto a deform template (for slightly wavy paper), and drops that onto another perspective template. (this is just an example, in case you're asking why the user isn't learning how to use a 3D program instead) All the while, every function in-between can still be edited: he can change the number of windows on-canvas (tiling), can change the perspective on-canvas, can change the extrude values on-canvas, can edit the vines on-canvas too. He can turn templates on and off, for example turning off the perspective template temporarily to edit the poster. There's been a lot of head-scratching regarding the proper interface for LPE-stacking. The current interface is not on-canvas enough, and the lack of reusability is a pity (for perspective, for example, or custom wavy flags). There's been another proposal for connecting function boxes, and I'm not sure users would like that either. On-canvas templates may be a new approach, but seems to open up a lot of possibilities. Are there any other programs where you drop all sorts of functions to be accessed on-canvas? (previously I was also thinking about adding functions to guides for various effects, but now I think some of those could be snap modes: snap to parallel i.e. straight lines snap into directions parallel to guides-, snap to orthogonal, snap towards guide points) > (Frankly, it's more the "sounds stupid, but involves a whole lot > of code refactoring" tasks that usually don't get done.) Yeah... there are a few fundamental operations that Inkscape can't do yet, like a number of group operations: - You can't perform boolean operations like substract or cut on a group - You can't cycle through color hue for a group (like you do with hue/saturation in Gimp) - You can't perform perspective deform on a group, nevermind make perspective templates... I'm also trying to think for a proper GUI proposal for on-canvas Pattern Along Path editing combined with line shape presets management (the presets could probably be accessed from a separate dialogue, like brush presets in MyPaint and Krita). This means Inkscape could ship with custom line shapes like chains, zippers etc., and then the user would be able to modify their size etc. without accessing a scary LPE dialogue. Presets won't just apply to Pattern Along Path, users can save their own powerstroke settings and dotted lines + markers settings for quick access. I don't suppose someone could bring this layer clip extension into the main branch, by the way? Layer masks (or just clipping) happens to be quite high on many people's wishlist: http://www.pernsteiner.org/inkscape/layerclip/ I really got off-topic. Oops?

2 1

Powerstroke presentation at LGM 2012
by unknown＠example.com 18 May '12

18 May '12

Hi all, Quick note to tell that I uploaded my presentation about Powerstroke on our wiki. http://wiki.inkscape.org/wiki/index.php/PowerStroke#LGM_2012_Presentation I'm sad I had to leave so early and had no time for the party :'( :'( Ciao, Johan

6 9

Re: [Inkscape-devel] Mockup for Improvement of Fill and Stroke Dialog
by John Smith 17 May '12

17 May '12

> You can see my findings and my suggestion on the Wiki, but to entice you > to read it, the mockup is here :) > > http://wiki.inkscape.org/wiki/index.php/Fill_and_Stroke_Dialog_Re-Design > http://wiki.inkscape.org/wiki/index.php/File:Solution-fillandstrokedialog.p… > > Thanks and I would love to hear your comments! > Created a patch and screenshot for this in https://bugs.launchpad.net/inkscape/+bug/1000023

1 0

Recursive Drawing
by daniele rossi 16 May '12

16 May '12

really interesting, thanks for sharing. Daniele Il giorno 16/mag/2012, alle ore 20.18, inkscape-devel-request@...349...orge.net ha scritto: > I just saw the video for a recursive drawing tool and thought you might find it interesting: http://recursivedrawing.com/ It seems like a very natural way for designing L-systems.

1 0

Re: [Inkscape-devel] Recursive Drawing
by Valerie 16 May '12

16 May '12

That's pretty interesting. In fact, this and working on the GUI for tiling have made me think more about on-canvas templates in general. There's quite a bit of potential for just dropping stuff onto the canvas for various outcomes (you can turn them on and off). Possibilities include: 1. Clone/iteration templates: the render frame for the tiling tool is kind of like an on-canvas clone template, right? The link you provided could be an iteration template. Drop an iteration area, drop an object inside it, then manipulate the whole to activate iteration within the area. 2. Kinematic templates: "improves freehand drawing by altering the cursor's movements." More info at http://hci.uwaterloo.ca/research/kinematic (really cool stuff). 3. Deform templates An idea I've had recently: create a perspective grid (for example, over the side of a building), and if you grab and hover any object over it for a few seconds (example: a 2D window design), the object will have an automatic perspective deform applied to it. Moving the object along the grid behaves a bit like what happens with the 3D box tool. Also, when you draw straight lines within the area, they snap to the direction of the grid's vanishing points. Another deform template could be a mesh grid that you can edit before dropping some object onto it (example: a mesh grid to simulate a wavy flag. You can then drop the 2D design of any country flag onto it) Although some of it sounds more suited to 3D programs, a user could very well want to make a wavy flag in Inkscape, or some simple box icons with decorations on the side for example. 4. Render templates Basically things you would currently find under extensions -> Render in Inkscape (L-systems, trees etc.), except once they are on-canvas you can edit them there. Of course, although the ideas sound cool, programming would be another issue. And all that real-time rendering would totally kill a few CPUs.

2 1

Ellipse text change in 11365
by Jon Cruz 16 May '12

16 May '12

Hi John, The change in 11365 to shorten text when it gets too long looks great. Quite a handy feature, and very good to pull it out to its own function. What would make it even nicer would be to use C++ strings instead of C ones. In this case that could change the function declaration to be Glib::ustring gr_ellipsize_text(Glib::ustring const &src, size_t maxlen); Overall I thought this is also a good chance for us to call out a few specifics to the rest of the devs out there, as they might not know all the points you and I are already familiar with. For everyone out there, some reasoning for a few of those differences: * Glib::ustring and std::string manage their memory automatically, can share internal buffers, etc. Solves the huge issue of memory management with C strings. * Using Glib::ustring instead of std::string denotes the intent that the string contents have been standardized into UTF-8. Good to use Glib::ustring wherever applicable. * Passing in a reference to a constant Glib::ustring allows things to work, with automatic conversion even happening with gchar*'s being passed in. It also allows one to use .size() or .length() on the passed in parameter and not have to resort to strlen(). * Using size_t for sizes instead of guint. This is mainly a minor clarity point, but can matter for certain overloads, etc. And when we get to dealing with 32-bit vs. 64-bit code, using size_t for all sizes avoids a lot of problems. * Renaming to 'gr_ellipsize_text' (from 'gr_ellipse_text') changes it from a set of nouns to a verb. It's better to name methods and functions as verbs, and variables as nouns.

1 0

Recursive Drawing
by Veronika 15 May '12

15 May '12

I just saw the video for a recursive drawing tool and thought you might find it interesting: http://recursivedrawing.com/ It seems like a very natural way for designing L-systems. Veronika

1 0