- Inkscape Devel - Inkscape Mailman

Mesh tool added to trunk
by Tavmjong Bah 23 May '12

23 May '12

Hi, My Mesh branch suffered from serious bit rot. This is good as it shows how fast Inkscape code is progressing. But it also required several days of work to get the mesh branch in sync... not so good. I have thus merged the branch with trunk so I won't have to go through this pain again. One major change I made was to create a separate Mesh tool. The editing mode for meshes is significantly different from that for linear and radial gradients that I think this makes the most sense. By default, the Mesh tool is not shown. You can enable it at compile time by editing the file widgets/toolbox.cpp to define WITH_MESH. To actually see meshes, you must have compiled and linked to a version of Cairo greater to or equal to 1.11.4. Cairo version 12.0 would be preferred as 1.11.4 has bugs that cause frequent Inkscape crashes. Note, meshes are to be considered experimental. The SVG working group has endorsed their inclusion in SVG2 but the exact syntax has not been fixed. Inkscape is the only program/browser/renderer that supports the proposed SVG mesh syntax. Also, the UI for meshes is rather primitive at the moment. Please play with the meshes and give your feedback. Bug fixes and interface improvements will be greatly appreciated! Tav

4 4

Re: [Inkscape-devel] Mesh tool added to trunk
by Valerie 23 May '12

23 May '12

> What would be your recommendation regarding PPA builds? Enable or > disable the feature? Please enable it! Those of us using the PPA already know that it's an unstable build, and many of us look forward to testing this feature! :D

1 0

Re: [Inkscape-devel] Powerstroke presentation at LGM 2012
by jbc.engelen＠swissonline.ch 21 May '12

21 May '12

What I meant is: how do other programs draw sharp joins on thick paths? Ugly with a standard miter, or perhaps nicer? -Johan ----- Reply message ----- Van: "Valerie" <valerie_vk@...36...> Datum: ma, mei 21, 2012 10:56 Onderwerp: [Inkscape-devel] Powerstroke presentation at LGM 2012 Aan: "inkscape-devel(a)lists.sourceforge.net" <inkscape-devel(a)lists.sourceforge.net> > 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? ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

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

Fwd: Re : Fw: Menu refresh
by Susan Spencer 14 May '12

14 May '12

It would also be helpful to add command line options: inkscape --preferences=mydefault_preferences.xml --template=mydefault_template.svg - Susan On Mon, May 14, 2012 at 2:46 AM, John Smith <john.smith7545@...36...>wrote: > Re: [Inkscape-devel] Re : Fw: Menu refresh

1 0

Fw: Menu refresh
by John Smith 14 May '12

14 May '12

Any thoughts on changes to the main menu layout ? 1. Move "File->Inkscape Preferences" to "Edit->Preferences" This seems to be the preferred location in the Gnome HIG http://developer.gnome.org/hig-book/3.4/menus-standard.html.en 2. Move "Edit->Clone" to "Object->Clone" Does this make more sense, since we are really cloning objects ? 3. Split View menu (including Show/Hide submenu) into 2 menus - View (UI "decorating" the main view) and Window (dockable dialogs) View->Grid View->Snap View->Commands Bar View->Toolbox View->Rulers View->Scrollbars View->Palette View->Status Bar ... etc Window->Icon Preview Window->Input Devices Window->Memory Window->Messages Window->Swatches Window->Show/Hide dialogs 4. Merge "File->Document Metadata" into "File->Document Properties"

13 14

Active guides proposals
by Valerie 14 May '12

14 May '12

The fact that guide improvement is one of the projects accepted by Google Summer of Code projects is really good news! Guides are particularly helpful features in illustration programs. I thought it'd be a good time to write up some of the possibilities of guides. I doubt anyone can implement any of it anytime soon (certainly not before the current GSOC project is finished), but it might be helpful to keep these in mind to not close off future possibilities in the definitions or the GUI. Write-up here: http://wiki.inkscape.org/wiki/index.php/Active_guide_proposals As you can see, features I think will can be particularly useful are: - Symmetry guides: by simply toggling them on and off, you can enter an improved "mirror" mode. Helpful for everything from complicated technical illustrations to just drawing some vases in some corner. - Convergence points: this could be a mere feature of a more general "guide point". When drawing straight lines, the lines would "snap" to the direction of one of the active convergence points. Anyone who's ever tried to illustrate a building in 2D or 3D should know how helpful this would be (because the vanishing points can be so far away from the rest of the drawing that it's really no fun to look for them every time). - More generally, guide points and guidelines could have various properties activated. Guidelines with "orthogonal" and "parallel" properties activated, for example, would cause straight lines drawn to snap in a direction orthogonal/parallel to said guidelines. Very helpful for geometric drawing. - Then there are kinematic templates (by Richard Fung). I don't know why this still hasn't been ported to any of the major open source image programs, but in Inkscape, they would be great fun when combined with the calligraphy tool. I can work more on the GUI proposal in the meantime, but I'm not sure where to go from here, so comments are welcome.

1 0

Menu and keyboard shortcuts
by John Smith 12 May '12

12 May '12

Is there a reason Inkscape doesn't show the keyboard shortcuts in the main menu on Linux ? Keyboard shortcuts show up in the * Inkscape menus on Windows * Inkscape context menus on Linux * GIMP main menu on Linux ... so i'm guessing its not a GTK issue ?

4 7

Re: [Inkscape-devel] Circular Arrangement
by Valerie 07 May '12

07 May '12

Nice proposal! I just find the use of arrows for "bounding box" confusing. For me, arrows refer to a Direction, so my first impression is that you're choosing the direction for a transformation, except that doesn't make sense here. There's a really nice existing blueprint for anchor points here: https://blueprints.launchpad.net/inkscape/+spec/transformation-anchors For the sake of the future interface consistency, I'm wondering if that arrow-less grid shouldn't be used instead, though maybe in a bigger version. A mouse-over will pop up descriptions like "Use objects' lower-left bound." Another question is... how does this feature handle it if you want all the objects to Just touch the guide edge, but you don't rotate the objects? Basically, for an object on the upper-right, the lower-left bound should be used, while for an object on the lower-left, the upper-right bound should be used (which isn't quite an accurate way of putting it either, since the object doesn't necessarily touch the circle that way). See what I mean? Something like "Objects to touch circle's inner edge" (or just "Touch inner edge") and "Objects to touch circle's outer edge." Then again, if anybody needs that, they could submit it as a feature proposal later. I really look forward to the feature, rotational arrangements are a pain to do right now (I can never remember how to use that tiling interface). So thanks in advance!

3 4

affine/transform question
by mathog 03 May '12

03 May '12

In the emf print virtual methods the current transform is pulled out with: Geom::Affine tf = m_tr_stack.top(); Is the stack supposed to hold the final transform, or just the stack of partial transforms? For instance, for this bug: https://bugs.launchpad.net/inkscape/+bug/965594 the text SVG has a set of nested transforms, and the top only returns the inner one. The problem can be worked around by ungrouping everything, which seems to replace the serial transformations with a single one for each object. Otherwise it seems the proper action is to multiply down the transform stack to find the final complete transform operation. It looks like the stack is "fed" by the ::bind method, but that just moves the question out a bit, as that method has a call argument which is itself a transform. (Unfortunately "bind" is a common string in this code, so grep was not very helpful in locating whatever it is that calls the [virtual] ::bind method.) Thank you, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

5 8

javick2
by Ivano Arrighetta 30 Apr '12

30 Apr '12

signal processing and JAVICK in theory - draft 2 -https://docs.google.com/document/d/19EP2CgK6_EqsZ_nU6YSHcWsmC8ciFs7y1WWmTQw8J2c/edit Inviato da iPhone

1 0

Possible bug: ruler meters leaving trails
by Joachim 30 Apr '12

30 Apr '12

Hello all, Have found a possible bug. When using Inkscape on my Sony Vaio VGN-NS11Z traces are left by the ruler indicators on the edges of my 'design screen'. Running Debian Squeeze here. See attachment for a screenshot. Regards, Joachim de Koning - Metasync.info

2 1

javick
by Ivano Arrighetta 30 Apr '12

30 Apr '12

Someone pointed me to videojack, it's almost the same thing Inviato da iPhone

1 0

javick
by Ivano Arrighetta 30 Apr '12

30 Apr '12

sorry, i posted a wrong url. right one: https://docs.google.com/document/d/1Lut6Y6Xe-4ScR9G4Fg6EorTuSp0JKuTP6QRRzrk… Inviato da iPhone

1 0

javick
by Ivano Arrighetta 29 Apr '12

29 Apr '12

please see: https://docs.google.com/document/d/1Lut6Y6Xe-4ScR9G4Fg6EorTuSp0JKuTP6QRRzrk… and comment here Inviato da iPhone

1 0

Trunk PPA
by Josh Andler 28 Apr '12

28 Apr '12

Hey All, I just wanted to let people know that I've included the Quantal (Ubuntu 12.10) series in the PPA builds, so they should start showing up soon. Cheers, Josh

1 0

Re: [Inkscape-devel] New dynamics interface proposal
by Valerie 28 Apr '12

28 Apr '12

> http://www.tomlechner.com/randompics/finishing.png Ni... whoa, transparency on dark background is hard to read. xD But it's okay once you've downloaded the image. So anyway, it does look nice! I did end up thinking about what Josh said about what's "something you'd find in Inkscape and what you don't", and about implementation issues though. I'm wondering if it isn't too hard to code those visual elements (maybe it's not though, I can't tell). The part I totally agree with is the gradient and the "extrude" view for dynamics. A few thoughts on the rest: 1. Color dynamics In fact, the existing tiling mechanism is quite far from the ideal solution. Right now: To have color dynamics, you have to: - Start with unset fill and stroke colors - All objects in group must have and end up with the same color properties - You can only define a start value and %changes (though by defining a start and end value instead, it should be possible to have those then converted into %values) Ideally: - You can start with any fill and stroke - You can have objects of different color/opacity/blur properties - You can define multiple stops, just like a gradient Basically, for color/opacity/blur dynamics, your proposed interface works well if there's only a start node and an end node. For the user to be able to add intermediate nodes, the code for the color dynamics mechanism needs to be changed. This does not prevent us from defining the ideal end interface from the start, I just mean I'll have to note this in the wiki later, so I'm telling you first. Also, on the group color change, the following feature basically would help a lot (just like "cut operation on groups" is necessary for the "fuse tile" mode): Group colour/color changes, brightness, contrast, HSV, more: https://bugs.launchpad.net/inkscape/+bug/171181 Instead of starting with an object with no fill or stroke, you could start with anything you want, even groups of objects with different colors etc. Inkscape would modify the hue of the whole group like when you use the hue slider in Gimp for example. 2. Jitters There are two things that worry me a bit about the jitters presentation: - Interface clutter: I like the wub-wubs, but it may get messy with more than 2 or 3 of them. Maybe a single static round wub-wub could be displayed around the node if there's - any- jitter (just to warn you that it's there). The user can them see which ones are available by bringing up the whole thing. - Ease of programming. There aren't that many GUI features in Inkscape, and I don't know how how easy it would be to create a widget like the one you're proposing. Maybe clicking on nodes could instead just pop up a more usual dialogue with different jitter options and sliders: X-Jitters [x] Position : |----|--| [ 80 ]% [ ] Width : ||------| [ 10 ]% [x] Opacity : |------|| [ 90 ]% [ ] Hue : |---|---| [ 50 ]% (logarithmic sliders could be nice...) I wonder if trace properties could also be stuffed somewhere... Since there is a "preview" button in the wiki proposal, the user can just toggle it on then off and tweak values until he's happy. Though... the preview feature itself is something that needs some work...

1 0

Re: [Inkscape-devel] New dynamics interface proposal
by Valerie 28 Apr '12

28 Apr '12

Thanks for uploading the file Veronika! http://wiki.inkscape.org/wiki/index.php/Tiling_tool I've edited the wiki page some more: - Added a table of UI design status, so feel free to add your own input of what seems OK already and what isn't - Added description for radial tiling - Added description for line tiling - Re-added proposal for symmetrical dynamics around base tile, but also noting that the current tiling mechanism does not support it - Added current discussion on on-canvas Dynamics. Also added a proposal: "preview mode for dynamics" (click a checkbox next to wherever the toolbar item for dynamics is located). Inkscape will render a preview of the dynamics by applying it to the frame's different tiles, also adding blur, color, opacity. You cannot edit transformations or jitters in this mode. Uncheck to return to "edit" mode. I've also finally added a blueprint link: https://blueprints.launchpad.net/inkscape/+spec/tiling-tool Although work still needs to be done, especially concerning on- canvas dynamics, I doubt on-canvas dynamics editing will be implemented anytime soon, first because Inkscape is currently more focused on clean-up, second because the tiling tool itself isn't likely that high priority, third because even then, many other features need to be coded first before reaching that particular feature... By the way, am I the only one for whom the text tool now crashes every time I try to start a new text box? (I can copy existing text boxes and change the content though) inkscape: /usr/include/boost/optional/optional.hpp:641: boost::optional<T>::pointer_type boost::optional<T>::operator->() [with T = Geom::Rect, boost::optional<T>::pointer_type = Geom::Rect*]: Assertion `this->is_initialized()' failed. (kind of annoying while making the mock-ups)

3 3

Re: [Inkscape-devel] Powerstroke: adding/deleting width nodes
by Valerie 27 Apr '12

27 Apr '12

> Just fixed a big problem with thick paths, see if this fixes your > rendering issues. > (https://bugs.launchpad.net/inkscape/+bug/986394) Oh dear. It does fix my rendering issues, but unfortunately it seems to crash sometimes now: (Inkscape r11297) terminate called after throwing an instance of 'Geom::LogicalError' what(): lib2geom exception: rx2 < 0, while computing 'rx' coefficient (2geom/ellipse.cpp:87) Also, this showed up in the console several times as well: ** (inkscape:8834): WARNING **: Exception during LPE [Unstable!] Power stroke execution. lib2geom exception: Invariants violation (./2geom/piecewise.h:144) Thanks for your hard work by the way! :D

2 1

Snapping
by Johan Engelen 27 Apr '12

27 Apr '12

Hi all, Am I the only one who finds it annoying that I have to specifically enable snapping *to* cusp nodes, in order for them to snap to the grid? In other words: I don't like the recent changes to the snapping UI. ;-) Suggestion: "snap nodes, paths, and handles" enables snapping OF all those things; and is completely unrelated for snapping TO those thingies. Then the buttons below that are decoupled from it, and mean snapping TO the things their tooltip says. Cheers, Johan

11 37

Re: [Inkscape-devel] Powerstroke: adding/deleting width nodes
by Valerie 26 Apr '12

26 Apr '12

> The inside of joins should look better now. Thanks! And actually, I think I found the reason for my "hard to make points appear" issue. And I think it might have been resolved since. See the attachment. I made that example in a version of Inkscape on Windows. As you can see, if the control point was on one side, the pointy edges would not appear. But moving them to the other side somehow fixed the problem. So it had nothing to do with miter limit! However, I wanted to make sure, so I took that example home where I use Linux. By then the Linux version had been updated, and somehow the points render correctly now regardless of the position of the control point (did you fix something in the meantime?) Apart from that there's some rendering issues for large lines, but those are extreme cases. It's definitely quite nice to use now! Now my main wish-item involves quickly accessing settings. The most accessible way may be to have a drop-down option for "Last powerstroke settings" (shorter name needed...) Being able to save each settings and access them from the toolbar drop-downs would be even better, but that doesn't seem to be trivial to do right now. Amazing work by the way!

2 2

Retinex color operation
by Michael Grosberg 24 Apr '12

24 Apr '12

I'd like to Discuss Retinex. I decided to do it here before submitting a bug report. In theory the retinex operation is very useful in fixing badly lit images. In practice, I've had little success with it. So I decided to fiddle around with it. My test picture was a chinese temple on a background of blue sky. usually you want to just brighten up some darker areas or bring detail in an area that's too brightly lit, without changing the rest of the image. In my test case, The sky's color was ruined when retinex was applied and most of the well-lit areas lost most of their color. I'll break down what happened: 1. The properties that can be changed by the sliders in the retinex dialog are not clear at all. The documentation doesn't explain the first two in terms understandable to a non-mathematician. Whatever it is they are doing, they are not helping in correcting images. 2. The result is too strong. I find I have to do a "fade" every time I use it. My suggestion: add a multiplier slider that would do an internal fade. The default should be about 0.5. 3. The algorithm is indiscriminate: it is used to fix bad lighting but it also works on well-lit areas. I believe it should have less effect on pixels (or areas) whose average luminosity value is 0.5, and more effect on pixels with values closer to 0 or 1. I managed to achieve a selective retinex using the following method: 1. copy the layer 2. paste into quick mask 3. blur the mask using gaussian blur (8.0 radius) 4. invert the colors (only if you want to affect just the darker areas) 5. use levels or contrast to mask out the mid values 6. Perform Retinex The above procedure can probably be turned into an integral part of retinex so that retinex only works on those parts. Perhaps adding another slider that controls the luminosity / strength ratio. Photoshop's "lighting/shadow" algorithm has two sliders. One for choosing the strength of the effect on lighter parts of the image, and one for choosing the strength of the effect on darker parts of the image. This seems like a desirable thing to have. Comments?

3 3

Export without premultiplied alpha?
by Tobias Oelgarte 23 Apr '12

23 Apr '12

Hello, I used Inkscape in the recent years for great works and it keeps better and better. So at first big thanks to all developers that made it possible. But now to my question. ;-) Does Inkscape support image export (export to PNG) without premultiplied alpha? In a recent project I needed images with fairly high transparency, but with premultiplied alpha the colors inside this image regions are really suffering. As an example you could try to export a highly transparent rainbow open it with Gimp and remove the alpha channel. It should be clearly visible the the colors are strongly quantized. As long the image is just composited 1:1 over another image this is no problem, but in other scenarios it starts to give problems, since the color information is missing. Are there any plans to enable true RGBA (all seperated channels) for at least the export? Currently i have to export two images. RGB for the colors and a duplicate in graytones for alpha that i then combine to true RGBA to avoid the problem. Best Wishes Tobias Oelgarte

2 1

Re: [Inkscape-devel] Powerstroke: adding/deleting width nodes
by Valerie 21 Apr '12

21 Apr '12

Strange, I seem to be having rendering problems now. See first attached file: sometimes (once every few renders) the render doesn't update after moving nodes or the width control. It takes moving things around a bit more before it renders again. I'm not sure if it's a Powerstroke problem or some other render problem, though I don't seem to have the same issue with normal paths or Pattern along Paths. The inside of strokes looks great for the most part now! It still renders "inside" for sharp angles. Also, it seems hard to make very sharp Extrapolated edges again. See second attachment. I've increased the miter limit to 400, and the edge does render under Miter mode, but not under Extrapolated mode. You're right about the UI, some discussion is needed. And then it needs to be coded (I can't code, unfortunately). It's a pity, because this is a feature that's bound to be very popular, and UI issues would slow down the workflow. Message: 6 Date: Fri, 20 Apr 2012 21:41:17 +0200 From: Johan Engelen <jbc.engelen@...2592...> Subject: Re: [Inkscape-devel] Powerstroke: adding/deleting width nodes To: inkscape-devel(a)lists.sourceforge.net Message-ID: <4F91BBDD.4080701@...2592...> Content-Type: text/plain; charset="iso-8859-1" On 16-4-2012 4:03, Valerie wrote: > > The inside of joins should look better now. > > Thanks! And actually, I think I found the reason for my "hard to > make points appear" issue. And I think it might have been > resolved since. See the attachment. > > I made that example in a version of Inkscape on Windows. As > you can see, if the control point was on one side, the pointy edges > would not appear. But moving them to the other side somehow > fixed the problem. So it had nothing to do with miter limit! > Yep you found the reason, and yep I had it already fixed :) > Apart from that there's some rendering issues for large lines, > but those are extreme cases. It's definitely quite nice to use > now! > Struggling with thick lines too... but I think it will be hard to fix as I think the 'bug' is actually 'correct' mathematical behavior. > Now my main wish-item involves quickly accessing settings. > The most accessible way may be to have a drop-down option > for "Last powerstroke settings" (shorter name needed...) > Being able to save each settings and access them from the > toolbar drop-downs would be even better, but that doesn't seem > to be trivial to do right now. All ideas are welcome. Help would be nice: UI stuff is generally not particularly difficult to code, but time consuming (and of course you need to decide what you want). I recently did quite a big "mathematical" change, so perhaps new bugs popped up... but it was supposed to fix the "instable" rendering stuff (where you see flickering joins for example). Cheers, Johan

1 0

Parallel build on Windows
by Johan Engelen 18 Apr '12

18 Apr '12

Hi all, For parallel builds on Windows, update to >= rev11088, recompile buildtool: "g++ buildtool.cpp -o btool.exe -fopenmp" and run "btool -j" (or "btool -j x", x=number of threads to use) I fixed the bug, and with virusscanner disabled, I can build Inkscape clean in 5 mins and 2 seconds. (i7 2600) Cheers, Johan

2 1

Re: [Inkscape-devel] Snapping
by gespertino＠...400... 17 Apr '12

17 Apr '12

2012/4/17 Vladimir Savic <vladimir.firefly.savic@...400...>: > Why not even setting it to zero? I do it almost immediately upon new > install. Although, I admit that even having an option for delay is great, > especially as drawing gets more complex. > > If you choose to change it (but not zero it) - half way down from default > will work, I guess. There was something witn zero delay, I can't remember what (and it probably was fixed already). I think it was something related with performance, but I'm not sure. I should check my bug reports and see what was the problem (and if it still exists), but I remember having to use a small delay to avoid it. Anyway, If snapping with zero delay doesn't conflict with other tools or something, I can agree that it's a much pleasing default, so +1. Gez

3 2

Re: [Inkscape-devel] Powerstroke: adding/deleting width nodes
by Valerie 15 Apr '12

15 Apr '12

> By now, I have forgotten all feature requests and bugs. I think all big > issues are solved now, so it's ready for some proper beta testing (alert > me and the maillist if you think otherwise! :P) Yay! Looking great! In fact, I've noticed that the Windows Inkscape development version hasn't been updated in a while: http://www.oss-marketplace.com/index.php/downloads-mainmenu-63/Inkscape/Ent… So, I haven't been able to test it on Windows. Could those folks be prodded a bit? Right now the issues I've encountered are: - Adding a stroke to the rendered path will show extra bits of lines "inside" the stroke where at cusp corners. - Does "miter" limit only work with "miter" cusp nodes and not with "interpolate" cusp nodes? Because even when I increase that value a lot, the "pointy" edge still stubbornly remains beveled no matter what I do (more generally, I sometimes have a really hard time getting that edge to show up). - Rendering bugs sometimes. Yes, I'll try to make some proper example files over the weekend. Apart from that, extra features I hope for are: - Powerstroke for Ellipse shape (I know, non-trivial, but it's one of the most commonly used shapes) - More options in the toolbar drop-down corresponding to different cusp node settings (smooth nodes and either interpolate or miter nodes): "smooth" vs "sharp" lines. I favor "pointy" lines and it's awkward to have to open the LPE dialogue each time to switch things over. It'd be even better if Inkscape could just save settings automatically and add them to the shapes drop-down, but I'm not sure if that's easy to do right now. I've also looked at the "Apply LPE to clone" interface. It's one I can get used to, but I do admit it's a bit confusing: - It took me a while to understand what "clone original LPE" is supposed to be, and I don't think I'd have ever figured it out if it weren't for the mailing lists. How about "Clone LPE skeleton"? - How about just making this fill behavior a checkbox option for powerstroke? "Clone skeleton for fill." So, with just an extra checkbox, you can create both that complicated stroke and the fill in one go.

3 2

Example for Inkscape extension in Java?
by Gerrit Karius 15 Apr '12

15 Apr '12

Dear Inkscape devs, Can anyone point me to a working example of an Inkscape effect extension written in Java, running on Windows? I've read the Script_extensions and INX_extension_descriptor_format wiki pages. I thought, theoretically I might just replace the command tag in the inx file with something like this: <command reldir="extensions" interpreter="java">Hello</command> And then I could call a Hello World program like this one: class Hello { public static void main(String[] args) { for( String arg : args) System.err.println("Hello error: "+arg); }} The program wouldn't return any document, but the error message would be displayed by Inkscape. However, when I test this, nothing gets displayed. When I change the program to write a file, that file doesn't appear either, so I guess the program isn't called. I can change the command text to any other value, but there is no notification that a script couldn't be found. I have written several Python extensions, but those hook up into the existing Inkscape Python extension framework, with inkex.py and everything. Maybe there's some hidden magic in there that I missed? Can someone point me to a working Java example, or tell me what I did wrong here? Many thanks in advance!Gerrit

2 2

GTK+ 3 build option
by Alex Valavanis 14 Apr '12

14 Apr '12

Hi All, I've added a new configuration option in r11244 to allow building against GTK+ 3. configure --enable-gtk3-experimental Note that this is only useful for people who want to get involved with the migration project... at present, all builds with this option enabled will fail! The option also automatically searches for a compatible external GDL library (>= 3.3.4), and uses that instead of our fork. Cheers, AV

1 0

Inkscape Translations
by Josh Andler 12 Apr '12

12 Apr '12

Hey All, It's been quite a while since we've called on the translators to do your magic. There have been over 800 string changes (last number mentioned to me) since 0.48. This is in no way announcing a string freeze or anything along those lines. It's purely just a friendly reminder that you can probably safely do your greatly appreciated work at this point and you will probably be 90-95% done come the actual string freeze. No release plan at the moment, but as soon as we have one, you will obviously be notified. Cheers, Josh

2 1

Inkscape 0.49 Release Notes up to date?
by Josh Andler 11 Apr '12

11 Apr '12

Hey All, I think the release notes probably need to be looked over by everyone who has contributed significant code during this dev cycle. http://wiki.inkscape.org/wiki/index.php/Release_notes/0.49 I don't see mention of the "remembering" opened dialogs between sessions or the improvements to the gradient tool controls bar for example. This is just a call to make sure things are documented, not in any way reflective of an impending release (although I will request people take another look again prior to the next major release). Also, do we really not have more notable bug fixes in this release that weren't backported? Cheers, Josh

1 0

Drawing speedup
by Jon Cruz 11 Apr '12

11 Apr '12

Hi, Just wanted to drop a quick note to point out that in the last month or so I've noticed drawing with the calligraphy tool feels a lot faster. I'm using a build with optimizations turned off on OS X. I'm not quite ambitious to try a source control bisection to pinpoint when things got better. I wanted to be sure to say "good job" to all who keep helping.

1 0

Powerstroke: adding/deleting width nodes
by Johan Engelen 10 Apr '12

10 Apr '12

Hi all, I just fixed the biggest UI issue with powerstroke: adding and deleting control nodes. Now, you no longer have to unselect>select the path again. By now, I have forgotten all feature requests and bugs. I think all big issues are solved now, so it's ready for some proper beta testing (alert me and the maillist if you think otherwise! :P) If you find a bug or have a request, please add it to the bugtracker and assign to me. Do add a test SVG file if you report a bug! Cheers, Johan

1 0

Remaining GTK+ deprecation issues
by Alex Valavanis 10 Apr '12

10 Apr '12

Hi All, We're very nearly clear of deprecated symbols now, but the last few are maybe a bit tricky. Can anyone see an easy way to deal with these three remaining issues? * Stop using GtkObject in SPCanvas hierarchy. See bug #813232 * Stop using GtkCList/GtkCTree in sp-xmlview-tree.cpp. See bug #903676 * Draw images from data with Cairo in sp-cursor and sp-color-slider. See bug #943207 Would be good to iron out these final creases, so we can start work on the actual GTK+3 migration Cheers, AV

4 4

GSoC 2012 application
by jan pulmann 10 Apr '12

10 Apr '12

Hi, I sent a GSoC proposal about CAD features described at http://wiki.inkscape.org/wiki/index.php/CAD , (proposal https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2012/jam… ). I didn't contact with you before this proposal, because I forgot about the deadline, but I have been thinking about submitting proposal to inkscape for a while. Reading the mailing list, I see that you are more inclined to agree with internal structure refactoring project, and not my feature adding one. I would like to ask about my chances on this proposal. I don't know how far is it possible to bend the proposal, but I am much more confident with my math skills that software engineering skills, which is partly reason I chose this subject. I also have a technical question. Getting comfortable with inkscape source, I was trying to find a source of bug https://bugs.launchpad.net/inkscape/+bug/953593 and I found out that poppler is returning wrong unicode codes (at least I think). What should I do next? I can write workaround (it won't be very nice, just swapping the two unicode values), or will just reporting to poppler suffice? Thank you. Best regards Jan Pulmann

3 2

Apply LPE to clone
by Johan Engelen 08 Apr '12

08 Apr '12

Hi all, I have added functionality to the LPE dialog. When you select a clone, the "add effect" button is enabled and when clicked will convert the clone to a normal path and add the clone original path LPE (without showing the LPE selection dialog) . Please see for yourself what I mean :) My question is: is this desired behavior? Or... do we want to pop-up the LPE selection dialog, and then afterwards apply the *stack* of LPEs: clone original LPE + selected LPE. This option is more work so I did not do it yet. But there is a better reason not to do this: perhaps the user does not want to apply an (extra) LPE on top of the clone original LPE at all! Why? Because using the clone original LPE, you can get clones that have a different style than its original path :-) :-) I hope someone with more UI awareness can change the LPE dialog text when a clone is selected. It now reads: "Click add button to convert clone", and I guess that can be improved. Cheers, Johan

1 0

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 04 Apr '12

04 Apr '12

Thanks a lot! Would I be correct to interpret it this way: 1. Basically, the current code would not allow "multiple stops." 2. But it'd still be possible to have a one-stop on-canvas handle (maybe two, for rows and columns), that basically converts the end values into percentage values to feed into the current system 3. Since Inkscape doesn't store tiling values right now, changing the tiling mechanism completely (to allow interpolations) would not break any backward compatibility or something like that (not that changing the mechanism is an easy task) So, the possible way to implement the tiling tool is: 1. First create a separate a "render frame" object (with a central tile), and make it output values (to feed into the tiling system). It'd basically be a separate file that can be tested independently. Also, you can't add or delete tiles individually at this point, just rows and columns, since the tiling system only handles a "rows and column" entry at this point. 2. Once it is considered "stable", it is made to call upon the tiling system, to which it inputs appropriate values. On-canvas dynamics would require adding to the code for the render frame object, not the current tiling system. What it'd do is generate percentage values that are then fed into the tiling system as well. So, for a "basic" tiling tool, the tiling system would not need to be changed much. However, adding both the fuse mode and multi- node interpolation tiling would requiring significant changes to the system. Is that more or less correct? ________________________________ From: Jasper van de Gronde <th.v.d.gronde@...528...> To: Valerie <valerie_vk@...36...> Sent: Wednesday, April 4, 2012 1:24 AM Subject: Re: [Inkscape-devel] New tiling interface proposal On 2012-03-31 16:20, Valerie wrote: Now, I know nothing about programming. Has anyone looked at >the tiling dialogue code yet to see how hard it'd be to mess around >a bit with it? Possibilities to add extra stops etc. even? Replacing >the opacity/blur/color mechanism with a gradient-like approach? > I'm afraid I haven't been able to keep up over the last few days, but I have had a look at the code. For those interested, all the code is in src/ui/dialog/clonetiler.cpp. The main function is CloneTiler::clonetiler_get_transform. This function essentially gets all info, as well as a row and column index. It then computes all the transforms required for that position and combines them. As far as I can tell it combines them in such a way that first a scaling is applied, then a rotation and finally a translation. If you select a different symmetry group then the translation can become a more complicated transform. The scheme we talked about earlier that would interpolate transforms is not necessarily compatible. This is because in the latter the case the entire transform would be interpolated, while what Inkscape does is essentially interpolating per kind of transform. That this is not the same can be seen by realizing that rotate(50)translate(1)rotate(50)translate(1) is not the same as rotate(100)translate(2). The former is more or less what we talked about (or at least what I had in mind during that discussion), the latter is what Inkscape does. However, Inkscape currently seems to store almost nothing about the tiling in the file. So it would be relatively benign to change behaviour. Existing files would not be affected in any way, users would only be affected when trying to change a tiling or create a new one. (This is not to say that it's necessarily a good idea to make it impossible to achieve the current behaviour, just that if we cannot reconcile the two, there is some room for change.) Note that it would be possible to emulate Inkscape's current behaviour through interpolation of transforms, but only if we would allow "stacking" transforms. I'm not sure how this would have to be supported UI-wise though.

1 0

GSoC 2012 Student Application Deadline approaching
by Josh Andler 03 Apr '12

03 Apr '12

Hi, If you're a student who is going to be applying for Summer of Code with Inkscape, this is a reminder that your applications/proposals should be submitted as soon as possible. The deadline is April 6 19:00 UTC. It is recommended to submit sooner rather than later so we can try to help refine your proposals if necessary. Good luck! Cheers, Josh

1 0

Re: [Inkscape-devel] Google Summer of Code 2012
by Yevgeny Lezhnin 03 Apr '12

03 Apr '12

On 03.04.2012 20:12, Tavmjong Bah wrote: > Your background information looks good. It seems that you have lots of > experience. I would like to see the proposal developed a little more. > For example, what bugs are users suffering from? What features could > you add (some people would kill for underlining). I found one bug #960046, that has opinion about whole text realization in inkscape, it has idea of merging text function. Also searching bugs with 'text' tag in it gives 229 results. I've listed this features: hyphens, indentation, underlining and merging. > How would you treat flowed text? Have you looked at the draft CSS > exclusions and regions specifications to see how they could be applied > to Inkscape? (An Inkscape implementation would really help push this > forward for SVG2.) Time is short. How deeply should I understand css specification at the moment? From what should I start? > Note, Firefox is known to be bad at rendering SVG text. This is > something they are working on. Yes, I see it now. Then I was working with diagram, there was bad support of svg text in firefox. So it is not inkscape's fault.

1 0

Inkscape-docs list admin
by unknown＠example.com 03 Apr '12

03 Apr '12

Hello inkscape-docs list has been silent for months and it appears that message are pending. I'm one of the admin but we all (poor admins) can't log to the admin panel of the list. Does anyone have the rights to do that and reset the configuration ? pygmee

2 1

extract node subset??
by Bric 03 Apr '12

03 Apr '12

If I have a path with, say, 100 nodes, 30 of which constitute a separate, continuous "subpath" -- discontinous from the other 70, and I can easily highlight these 30 nodes -- how can I extract/cut or copy these nodes and "paste" them as a separate path?? Or, in other words, "break away" this part of the big path and convert it into a distinct path. It's already possible to DELETE these 30 nodes (or whatever nodes one has selected, discretely or not). This seems like it should be relatively trivial for inkscape (given the powers it already has), but I can't find a way to do this. Is it perhaps in the filters? In the extensions? It's like there should be an extensions submenu called "selected nodes..." with options in that submenu including: extract selected nodes as distinct path (to be pasted) rotate selected nodes scale selected nodes.. ... etc., etc.

3 3

Re: [Inkscape-devel] extract node subset??
by Valerie 03 Apr '12

03 Apr '12

You'll probably have to duplicate everything and delete the parts you don't need... On this occasion, I realized that "inverting" the selection won't select nodes on other, non-joined segments, so you'll have to select them the hard way. I see what you mean though. Right now, if you have a combined path and select+copy one part, pasting would paste the whole combined path rather than that one section. I guess the issue here is that nodes aren't free-floating objects to copy/paste, so if you copy/paste non-continuous nodes then it wouldn't make sense. It could be an interesting feature though: - If you select several nodes on a continuous path and copy/paste them, you get a new continuous path with those same nodes (but without the uncopied nodes) and the same handle values (?) as those nodes. - The process repeats for all segments of paths selected - If for one continuous path, only a single node is selected, then nothing happens. It could be called "paste segment" or the likes.

2 1

pdf importing
by Alexandre Prokoudine 02 Apr '12

02 Apr '12

Hi, Just FYI, poppler 0.19.x supports color management via LittleCMS v2. Didn't we want color managed PDF importing at some point? :) Alexandre Prokoudine http://libregraphicsworld.org

6 8

GSoC Mentors
by Josh Andler 02 Apr '12

02 Apr '12

Hey All, Anyone wishing to be a mentor for this year's GSoC should either login to melange or sign up and request to be a mentor. Note, if you do not have familiarity with the codebase and are not a code contributor, you do not qualify. http://google-melange.appspot.com/gsoc/org/google/gsoc2012/inkscape Cheers, Josh

1 0

Re: [Inkscape-devel] Google Summer of Code 2012
by Yevgeny Lezhnin 02 Apr '12

02 Apr '12

Hello, I'm Yevgeny Lezhnin. I wish to submit to inkscape in gsoc 2012. I know c++ and can work with gtk+. I think I know how to make 'new from template' dialog: I can change menu entries in menus-skeleton.h verbs.cpp gdl-dock-bar.c gdl-switcher.c , and add new dialog source to dialogs folder. But I'm also interested in better svg standard coverage. I used inkscape for drawing diagrams in svg format, but there was some compatibility problems in firefox browser. And another thing: is there any good bug for gtk+ interface developer?

3 8

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 01 Apr '12

01 Apr '12

> For me, this is beginning to feel natural. Sounds like a start, at least! > I think to some degree Josh's comment still applies. There are at least > two different toolbars and some dialogs. As a start I think it should be > possible to eliminate the edit mode toolbar. True, now that I look at it, my current toolbar is empty enough to combine the two. Previously I had separate toolbars because each guide type had guide-specific options (like arc guides for radial tiling, and numerical fields). And yes, I should add an unclump. As things stand I think I'll just leave all the numericals inputs to the Transform and Edit Paths tools. And snapping. Users can just snap to something if they need. Instead, here's how I propose the tiling tool to work. On-canvas, by default you will have a render frame with a base tile: - When using the tiling mode, you can click on the center tile to make handles appear, and from there, modify the handles (who become invisible when not using the tiling tool). - Clicking and dragging the corners of the frame with the tiling tool will add frames to it. You can also shift-drag so new tiles will be created on edges you drag over, or ctrl-shift-drag to delete. - You cannot resize, rotate or move the center tile or the render frame with the tiling tool, but you Can do so with the Transform tool. You can't do those operations from the circle or spiral tools either, so interface-wise the users should be able to get used to it. - As with circles and spirals, double-clicking a center tile or render frame opens up the tiling tool anyway. I was also thinking of imposing some limitations: 1. No skewing for the center tile, even though P1 and P2 allows for those. The reason is that this would allow users to more easily switch to other symmetries with rectangular tiles. Even if the user's tile design is a skewed rectangle, it's not like they need the base tile to be one anyway. 2. I'm thinking of eliminating the rotation centers and force the users to directly choose say... a P3 guide if that's what he wants. Some handle options may still be available outside of the rectangle guides, but the general shape cannot be changed. The reasoning is: just how desperately does one need to change from P1 to P3 anyway? It may be fun to experiment but it will get confusing fast, and designs for very differently shaped tiles will probably be different too. > This sounds like a good idea. If I understand correctly your idea is to > allow transforming a single tile and then "propagating" that transform > to other tiles in such a way that starting from the original/central tile > there is a gradual change in the transformation. I had typed a long list of questions regarding interpolation with some cluttered thoughts regarding the interface, then I saw Veronika's suggestion: > I wonder if the dynamics could be considered as something separate > from cloned tiles and could be applied to any selection of objects. Somehow I think this is simpler too. :S Any objections to treating the features separately? > Oh, btw, make sure that "in the end", there is a blueprint or something > on your proposal (which can link to the Wiki page for example), as it > might take some time to come to an implementation, and it would > be ashame if it was "forgotten". No problem. I always did intend to make one. But I wanted to make sure that I got to a point where people browsing the blueprints section wouldn't be wondering why said blueprint is redone from scratch every few weeks (as in, at the very least, the general concept should be stable). And yes, I'm thinking of implementation order too. The pity about the current design is that it isn't as modular as my previous one, but oh well. > Tenacity is worth ten times more than smarts, we can get to the > best practical design through discussion and the great critiques. It also feels like it's taking ten times longer, and I'm starting to miss my other hobbies, but thanks for the encouragement. x)

7 12

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 31 Mar '12

31 Mar '12

I'm a bit confused about the title now... Are the "New dynamics interface proposal" discussions about a completely different tool, or about the dynamics for the tiling tool? By the way, Veronika, I keep losing the link to your list of tilings picture (because I delete nearly everything and copy entire new chunks of description each time I update with a completely new version) Could you perhaps upload it to the Inkscape wiki? Anyway, I updated the wiki with the latest iteration for the tiling tool: http://wiki.inkscape.org/wiki/index.php/Tiling_tool I've also added the "implementation steps." At this point, can everybody take a look and see if they agree with the "core" interface (meaning base tile + render frame at least, dynamics are still wip)? If so, I can already put up the page as a blueprint so anybody interested can get started (a lot of steps are still needed before reaching on-canvas dynamics editing...) Should I add a table to note what parts of the feature are accepted designs, what parts are still under discussion? Back to dynamics: > http://www.tomlechner.com/randompics/finishing.png I was confused for a while, but after a better look I do really like the interface! The term "wubwub" made me laugh. There should be a way to choose and see which wubwub does what, and a way to set the value back to zero. Double-click to add a corresponding wub-wub? (since users are unlikely to need jittering Everything at the same time) Of course the problem is still how all this will be programmed. Since you made that awesome alignment tool, I've no doubt that someone like you can pull off a tool like this, but I'm not sure the average volunteer student for inkscape could program this type of interface. And we also face the problem of how to integrate this with the existing mechanism. Now, I know nothing about programming. Has anyone looked at the tiling dialogue code yet to see how hard it'd be to mess around a bit with it? Possibilities to add extra stops etc. even? Replacing the opacity/blur/color mechanism with a gradient-like approach? Right now the two possibilities for on-canvas tile editing are still: 1. Drag a tile, all the other tiles get updated dynamically 2. Drag a tile, a ghost copy gets created, but the other tiles stay in place (Tom's proposal, and probably easier to handle than an interface where All the tiles are jumping around, preview value or not) I'd kind of like it if we can decided once and for all whether to use the first or second approach though. So, any opinions?

1 0

Google Summer of Code 2012 [C++ification]
by zcgucas 30 Mar '12

30 Mar '12

Hi, guys, I am Cheng Zhang, a student from graduate university of Chinese Academy of Sciences. I'd like to apply inkscape's project for GSOC 2012. I have been do some works following the instruction of inkscape's wiki page for GSOC 2012. And I have fixed two easy-fix bugs and attached my patches to the comment(Bug #561503 , Bug #941597 ). I am very glad one of them is already been applied. I am interesting in doing the C++ification job as my proposal for GSOC 2012. Actually I have already understand how important this work is deeply during these days' work on bug fixing. At first, I downloaded some very old codes of inkscape from sourceforge which may stop maintain for one year or more. Though I managed to compile and get it run on my system, I find it too hard to understand. That's why I have spent almost two days to locate lines that lead Bug #941597. In that version of source code, those lines lead the bug are in a file named "nr-arena-glyph.cpp" which is a c/c++ mixed style code file. Though it is easy to know those lines are in this file, I totally lost my direction while I want to understand how those "render"/"update" stuffs work. What's worse, if I want to know how they work, I need to know how the "arena item's" parent to get rendered or updated. But these codes are written mostly in C style and use a tricky way to enable code could work just like C++ codes do. I have to say the tricky is very hard to understand even I have already understand it now. Later on, I learned to download the newest code from bzr and found "nr-arena-glyph.cpp" already disappeared and turned into "drawing-text.cpp" which is a standard C++ code file that is very easy to understand. That is also the reason why I could fix the second bug in half a day. This experience makes me understand that to make code more easy to understand is one of those important reasons to do C++ification work. I have went through the whole code files of the project and made a rough list about those files are still in c style which could do c++ification work. This is such a long list. As a gsoc proposal, I see it couldn't be to big especially for a guy who get in touch with inkscape for less than a week. So I may choose to do the SP context related C++ification work as my proposal. I know there may be something I don't see here in do C++ification work. So I am very glad to here any advice from you guys! Thanks! zcgucas

1 0

gsoc2012, Designing SVG fonts using styles
by Mikalaj Parafeniuk 30 Mar '12

30 Mar '12

Hello! My name is Mikalaj Parafeniuk. I'm a third-year computer science student of Belarussian State University of Informatics and Radioelectronics and I am rather confident with C++. I am interested in applying to google summer of code with project, which can be found here: https://blueprints.launchpad.net/inkscape/+spec/designing-svg-fonts-using-s…. But I have a set of questions: 1) Is the idea still actual and what priority does it has? 2) The proposed idea is rather raw, could someone give me more details? 3) Could you give me some starting points? I'm going to checkout inkscape sources. To what part of code should i pay attention?

2 1

clean development surroundings
by Drechsel Wolf 30 Mar '12

30 Mar '12

Hi everybody I tried again compiling inkscape aqua on Mac OS X - one minor goal was to update the wiki on that topic. I made some mistakes which led to compiling errors. Now I wanted to give it a new go - but ended up with errors again allthough the environment should be o.k. I made a 'make clean' in the sources dir - but that seems not to clean up the environment enough. What elso should I do a ensure that I really have a fresh set of sources which will do the job? Thanks and greetings, Wolf

2 1

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 30 Mar '12

30 Mar '12

> I'm not sure that it makes sense to have the transformations symmetrical > around the base tile. The reason is because it's easy to just extend the frame in just one direction, but a pain to have to have to make identical handles in all directions. It's for designs where the user wants something to fade in all directions, for example. ... tiling of gradients? D: > As for the interface for actually adjusting the transforms (as well > as opacity and such). Is it necessary to do it with "tiles" shown > on screen, or would it suffice to allow transforming actual tiled > clones? Hm... actually, live preview of just the tiles could work? In that case, the handle will have to be the tiles themselves. (option 1 of my three suggestions). You have a point about jitters. I don't think small amount of jitters would affect things much, but it's true that some users may want to make larger amounts of jitters. > In general, I think the system is very interesting, but I would be > interested in making it a bit "leaner". After all, someone has to > implement it, and (more importantly), a lot of someone's have to learn > it. So the more we can leverage existing tools/infrastructure/concepts, > the better. True. Adding handles and having the transformation fan out in all directions are also features not allowed by the current interface, but that doesn't mean I can't leave them in there as features that could be implemented eventually. I do plan to decompose this into smaller tasks once everyone agrees on the general interface. For example, the bare-bones version of this feature would only feature normal clones (no fuse mode) with wallpaper tiling (no radial, no lines). Instead of on-canvas dynamics control, users just click on defined target tiles to pop-up a modified version of the current interface, and input values manually. etc. To be honest, I'm not even completely sure how Inkscape's current interface works. That's why I started a re-design. Once you've looked into the current design, it'd be helpful if you could tell us what's actually going on...

1 0

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 30 Mar '12

30 Mar '12

It's the guy who made the fancy alignment tool! :D I hope it gets ported over one day! In fact, it turns out that Jasper's suggestion of an "interpolation gradient" was genius! Here's the current setup: http://postimage.org/image/velcy91a9/ You can add linear, grid or radial interpolation gradients. The example shown here is a grid gradient. This interpolation tool can eventually be ported to be applied to just about any group of objects (but let's just stick to tiling for now...) Veronika, I didn't see your mail before I finished the current mock-ups. I do think what you're proposing could be quite useful for a general interpolation tool. :) We could start thinking about it separately from the tiling tool. Anyway, here's how the interpolation gradient would work with tiling (grid example): - Here, you have to define a Row stop and a Column stop. - By default, applying a grid interpolation gradient will place the stops on the tiles neighbouring the base tile. - You can drag that extremity to other tiles. - You can add Multiple stops! Just like a gradient! The other tiles aren't updated, this saves some processing power and avoids some clutter. Now the handle form is where it gets a bit trickier. I think the best would be to have a specialized handle of some sort. Anybody can think of a design? For blur and opacity, now that we have a few free controllers (maybe), we could maybe assign Ctrl to Opacity and Shift to Blur. The user just drags over the frame. Also hold down Alt to add/remove jitter values. For HLS interpolation: by default the ghost tile or handle is without fill, but fill etc. can be added like with any normal object to launch HLS interpolation. In fact, the user can switch to the eyedropper tool and take the values of a target object. Alt-click with the eyedropper to take a second set of values as jitter reference? So, the "optimal" work flow is to create sets of two coloured dots beforehand to set select color interpolation and jitter values. Of course you can also open up the full editor. To answer a few questions by Tom: 1. Yes, I've also decided that just Normal and Fuse modes are enough. 2. I want a separate Radial tiling because it's more intuitive for angle control. In the case of the render frames, you can manually set a start and end point, and snap to full circle (and maybe specify if you want more than 1 circle). When it's snapped to full circle: when editing the angle of the base tile, it will automatically take values to make a full circle. Small stuff like that. 3. The thing about guide points and guide segments is that others have noted the usefulness of placing them elsewhere than on the tile sides. 4. Skew will be allowed for P1 and P2. If you drag the handles in certains ways, they will automatically become upright. 5. The problem with live preview is that these tiles take potentially a long time to render. :S Since you're here, I don't suppose you'd have an idea as to the form of the handle for interpolation gradients, would you? :)

2 1

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 29 Mar '12

29 Mar '12

> The unclump option is already in the align and distribute dialog. So... should I add it or not? > This might give some problems when used with the fuse cut method > (with or without borders). In principle the user can obviously create a > design based on a rectangular tile, but this might not be the most natural. You mean edge scenarios right? It shouldn't be a problem for inner tiles, since you can just duplicate the pattern to fill the missing part, and Inkscape will still cut it more or less correctly. How about this? You can skew, but if you mess with the handles, the tile snaps to 90 degrees angle again. It becomes skewed again if you go back to P1 or P2. (I don't envy the person who wants to try to program the tiles...) > This reasoning is partly correct, and I agree that this would definitely not > be a "must". On the other hand, I think that some changes might be quite > logical, so at some point it might be nice to have the option. Hmm... I'll leave it in the design as a "really low priority feature", and we can just wait and see if anybody actually requests the feature one day. > Partially. One of the things that would make interpolation work really > well with tiled clones is that they are conceptually laid out in a grid True. Leaving dynamics out made the design conception much easier, but I realized that having to go back and add dynamics separately would be annoying in the end. Here's what I propose: http://postimage.org/image/4235075wd/ The solution is that little dot thing in the corner of each frame. Initially I was worried that it'd get in the way, but then I realized that until rendering is done, those frames are empty anyway. They're also invisible outside of the render mode. Each dot offers a visual representation of opacity, blur and HLS. Mouse-over gives exact values. Double-click to define exact values. At this point I hope the programing folks can answer a few questions about interpolation: 1. It is possible to define interpolation over both rows And columns using just a start tile and a reference tile (example: a base tile at the upper-left and a reference tile and the bottom-right). The current tiling dialogue forces you to define changes for both Rows and Columns. Though, in that scenario, maybe Inkscape just divides the values over Rows and Columns (I still need to make sure though that users don't need to choose two reference tiles besides the base tile). 2. Could each render tile in fact be considered more or less like an independent tile? Like, should we have the option to allows the user to break a tile apart and drag it around independently? (internally, Inkscape would still keep track of their row and column value, so users could still use some mechanism to select a whole row for example)

3 3

Re: [Inkscape-devel] Circular Arrangement
by Valerie 29 Mar '12

29 Mar '12

> You're right, the arrows are indeed a little bit confusing. As an > alternative I could use the iconless buttons like in the blueprint. As > an alternative I could put icons that somewhat resemble a bounding box. > Example: http://www.pasteall.org/pic/show.php?id=28549 Personally I really like your alternative icons! I wonder if the others agree? Don't worry about those other possible features I mentioned, they're just questions I happened to have on my mind. I wasn't trying to imply that you actually had to code them. Good luck with the project!

4 5

tracing bitmap images using bucket tool
by francesco fantoni 29 Mar '12

29 Mar '12

hi everyone, I used to selectively trace bitmap images using bucket tool, and I think it is a great feature and a wonderful trick in my workflow. Now I've compiled a fresh source from bzr, and tracing bitmaps this way seems not working anymore, I get only a message of non-closed surface or something similar. has this feature been removed on purpose, or am I somehow facing a bug? best to all, francesco

2 1

Re: [Inkscape-devel] Google Summer of Code 2012
by Yevgeny Lezhnin 29 Mar '12

29 Mar '12

Josh Andler писал 28.03.2012 02:44: > One thing to take into account when coming up with a proposal is if > you have many other plans for the summer. Are there other work or > travel plans that will be time consuming? Chances are that GSoC will > be much more time consuming than you may be expecting (especially if > you have not participated before). > > Cheers, >Josh I have a programming job in my university, but it should not take too much time in summer (0-5 hours per day), I'm not participated to gsoc before. I'm only participated to co.de-in 2010

2 1

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 28 Mar '12

28 Mar '12

You guys are killing me. D: Hopefully this... 7th iteration or so is the lucky one (at least approach-wise)? It still needs a lot of work, but the Youtube video and the extra comment on guides were eye-openers, so thanks for that! Alright, here's the deal: so far the design has either concentrated on dialogue, or on the "base tile", and such. This new design changes the approach (again): this new tiling tool proposal is centered directly on a render frame (with one tile serving as "base" tile). http://postimage.org/image/vinwmlp6d/ http://postimage.org/image/81v4l35p3/ Now as you can see, it should be somehow possible to fit the Dynamics onto the top-level as well. Unfortunately, I'm not as smart as the guy who made that Youtube video, so right now I can't think of a fancy approach to handle it all. The basic idea is that for some dynamics at least, (namely involving position, angle, skew, size and maybe opacity and blur), it should be possible to define them on-canvas through some trick involving the distribution or interpolation of the various frames. Suggestions please?

3 2

Libraries for 0.49
by john Culleton 28 Mar '12

28 Mar '12

Are the library requirements for compiling 0.49 the same as for 0.48.2? I have just gone through the agony of adding all the Inkscape libraries needed for compiling/running 48.2 on Slackware Linux. -- John Culleton Free list of books for self-publishers: http://wexfordpress.net/shortlist.html Police Procedural and Expose: "Death Wore Black" "Create Book Covers with Scribus" http://www.booklocker.com/books/4055.html

3 3

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 28 Mar '12

28 Mar '12

And another iteration: http://wiki.inkscape.org/wiki/index.php/Tiling_tool Is it me, or is the mail-archive not showing all mails in a timely manner? It took two days for one of mine to show up. Anyway, to answer a few questions: > Changing the selected wallpaper group is something the user will do a few > times and there are a fixed, small number of choices. Yes it would be very > nice to show the user that many of the groups are similar and to make the > user aware of the differences. However, I think there may be other ways to > do this and they may even be more clear. Yes, that's why there's a drop-down there. If you want to choose a tiling type immediately, then you use the drop-down. Also, the tile type can only be changed in tile edit mode. Users probably won't spend a lot of time in that mode. > In contrast, changing the size, orientation, in some cases angle of the base > tile with respect to the group being tiled is something the user will need > fine control over. The tiles behave like objects, so you can transform them with the F1 transform tool, and you can snap them to other guides. For radial and line tiling guides, you can also input numerical values in tile edit mode. I'm not sure what to do with the wallpaper tile though, since there are so many different shapes. A possibility is to define the coordinate of the first center of rotation + the length of 2 sides (only one is used if all sides are equal length). Now to answer Jasper: > 1. Inkscape's current tiling approach doesn't actually generate the > tilings it says it does. It /can/, but by default it doesn't (you need > to tweak the parameters to make sure the tiling actually matches the > chosen tiling group). Ah yes, I noticed the hard way that P2 tilings behaved weirdly... (i.e. I was trying to understand what it does by actually trying to render it) > Forget about tiles. Seriously. The problem with focusing on the > actual base tile are two-fold. First of all, if you define the base tile > together with what rotation centers/reflection axes are on its edges and > at what positions, then it is often non-obvious what the actual base > tile is. But the base tile is still the most intuitive guidelines one has for wallpaper tilings... Also, you need to know where the edges are to create seamless tiles. Or do you mean that the extra stuff gets in the way? The handles etc. aren't visible outside tile edit mode. Since the default tile is a simple P1 tile, and you need to bother double-clicking the tile to enter the tile edit mode and change what it does, I think we can assume that the user won't be too surprised if the output is no longer a simple P1. > Even worse, take a p2 tiling and put a 180-degree rotation > center on its "translational" edges (I'm referring to the diagram drawn > by veronika(?)), what you end up with is another p2 tiling with a > different base tile... Huh? It's still the same tile, just flipped. That's how wallpaper tilings work. > Another reason is that users might want to put guide points somewhere > else than on a tile boundary. So I think it is more important to focus on > the transformations involved, rather than on the base tile, and I think > this can even help to make things make MORE sense. I'm not sure what interface you're proposing. I know nothing about tilings, and the only thing I care about for tiling is that when I click the "apply" button, I get a pretty result (and a seamless output would qualify for the "pretty" factor). The specific transformations don't actually matter at all to users like me. :S

3 2

freehand tool in Python for comparison to Inkscape tool?
by lloyd konneker 27 Mar '12

27 Mar '12

This *might* be of interest to some. I am not familiar with the Inkscape freehand tool. I wrote a freehand drawing tool using Qt, PySide, Python. See https://github.com/bootchk/freehandTool Uses algorithms from potrace. Its readable, understandable, easy to prototype, and FOSS.

1 0

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 26 Mar '12

26 Mar '12

Alright, I haven't made a full diagram of guide transformations using handles, but looking at the different tiling types, I am now convinced at least that it is at least possible. So, with that in mind, I bring you YATTIP (Yet Another Tiling Tool Interface Proposal): http://postimage.org/image/nhwdn9x29/ http://postimage.org/image/m1lvj06sn/ By popular (?) demand, this is now a tool again! (with a possible extra dialogue for extra options). The "handles" approach actually resolves a number of things. In fact, when choosing a guide, you now simple start with the following defaults: - P1 for wallpaper - Simple-rotation and scaling for radial tiling - Simple translation for line tiling (but all Frieze types are available) Double-clicking a "tile" changes the toolbar into the tile edit mode. Using either the handle or a drop-down in the toolbar, you can then change the tiling type. Since for wallpapers, most people will be using P1 anyway, this approach should be satisfactory. Other features I had proposed are still there: - Guide points and other guide types - Excluding parts of a tile's exterior and fusing all the tiles - Tile stacking should be still possible from a dialogue Any major comments before I completely redo the wiki content again?

2 1

Some clipboard functions
by Romain de Bossoreille 24 Mar '12

24 Mar '12

Hi, A 200% code question, thanks to the one (or two, or three... !) who will give me an answer! I'm looking very closely to the clipboard implementation to follow understanding its behaviour (cf. http://wiki.inkscape.org/wiki/index.php/Clipboard), an amazing work have been done but I've a question (in src/ui/clipboard.cpp): Inkscape::XML::Node *ClipboardManagerImpl::_copyNode(Inkscape::XML::Node *node, Inkscape::XML::Document *target_doc, Inkscape::XML::Node *parent) void ClipboardManagerImpl::_pasteDocument(SPDesktop *desktop, SPDocument *clipdoc, bool in_place) void ClipboardManagerImpl::_pasteDefs(SPDesktop *desktop, SPDocument *clipdoc) SPCSSAttr *ClipboardManagerImpl::_parseColor(const Glib::ustring &text) On my understanding, those functions should not be implemented in the Clipboard class because 1) they are not using any functions dedicated to the Clipboard and so 2) they are codes that could be needed for other puposes than clipboard (and I wonder whether some are duplicated elsewhere in the project). If my opinion/understanding is confirmed, implementing them in a more global namespace should be a better way to avoid dupplicated functions (now or in the future) and provide better code hierarchy ('util' functions?). Or at least setting them as static to show they are not dedicated only to the clipboard management. Does any "Inkscape developper expert" have an opinion on it? -- *Romain de Bossoreille*

2 2

Powerstroke rounded joins
by Johan Engelen 24 Mar '12

24 Mar '12

Hi all, After busting my brain for two evenings, I've succeeded in creating properly rounded joins for powerstroked paths... The quick explanation: - for constant stroke width paths: looks like SVG rounded joins (circular arc) - for non-constant width paths, it is not possible to round with a circle and keep the curve smooth (tangents will not match). So the rounding is done with an elliptical arc, for which the tangents *do* match. There are many possible ellipses, and I decided for the one with minimum eccentricity. This converges to a circle for constant stroke width. Please test and tell me if it is bugged. (bzr rev 11111) Cheers, Johan

2 4

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 24 Mar '12

24 Mar '12

Alright, I've had the time to take a better look at Veronika's diagrams. They're really well-done, I feel like I finally understand what's going on! (quite a feat considering the headaches I've amassed from trying to figure out what's happening from several other sites) It's easier to see how handles would work thanks to those. Here's an example toggling between P1, P2, PM and PMM. http://www.freeimagehosting.net/kouh5 (hopefully you can tell the pair, symmetry and rotation handles) With an additional handle for glide reflection, it should be possible to connect all shapes with rectangular base tiles. I'm not sure how to fit in P3 and P4 though. What's more, it may be possible to convert between most of the triangle tiles by clicking on a corner, and dragging around to choose the number of tiles in that corner (3, 4, 6, 8 or 12). The shape of the tile would have to be updated automatically. The problem is that the users may then be tempted to drag other handles around to convert between pair, symmetry and rotate to play around, but the resulting output may not correspond to a tillable symmetry. There should be a method of warning in that case. Also, to make things less confusing, it may be possible to force one corner to be a "primary rotation corner" (the corner with the largest amount of tiles touching it) and a "secondary rotation corner." Does anyone feel up to trying to make a diagram with all 17 tilings as well as conversion methods between them? If you somehow manage to do that, I'll try to make a new tiling GUI proposal around it.

1 0

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 24 Mar '12

24 Mar '12

Ah-hah! People keep telling me about draggable handles, but I never was able to figure out what they meant (it's just me being clueless, not other people's faults). I think I'm beginning to see what people are talking about. Simple example: - Base tile: Rectangle for P1. At the side of each edge, you see a handle. The ones on the left and right are the same, the ones on the top and bottom are the same. Maybe parallel arrows. They symbolize "translation" (though I am going to go with another name, like "pair handle", because one side forms a pair with another) - By either dragging the handle or doing some other operation, the "pair" handle becomes say... a symmetry handle. So now the default behavior of that side is symmetry (also breaking the "pair" behavior of the other side). It can also be changed into anti- symmetry (using the center of the side). In the same way, there are edge handles. By manipulating it, the rectangle corner can become say... a triangle corner (and this is why I used "pair" rather than "translation": a pair behavior can be maintained). Alright, the main "issue" here is that I'm the one who doesn't know how to handle such behavior (since, as I've already explained, I'm pretty clueless about wallpaper tiling actually). Can someone more familiar with wallpaper tiling look into how feasible it is to transform from one tiling to another without erratic behavior? Is it possible to transform from one type to any other? If it's feasible, then I'll have to redo the whole thing proposal again. xD This time probably re-integrating guides and the actual tiling into one interface... ----- Original Message ----- From: Mark Schafer <mschafer@...2596...> To: Valerie <valerie_vk@...36...> Cc: Sent: Saturday, March 24, 2012 6:05 AM Subject: Re: [Inkscape-devel] New tiling interface proposal I can see that a set of thumbnail pics showing the principle tiling layouts is useful for initial selection of a specific tiling. And your approach looks very good. But ideally that would create the interactive draggable handles on the canvas for users to interact with - and ideally modifiable to create all tilings simply from these widgets. That way a new user can select a tiling style to being to operate with (or see many choices) - and an advanced user can simply begin and manipulate the tiling to their desired outcome. This approach would argue for a simple UI where initial selection (or toggling of selection) can start/modify the current tiling on canvas. So not taking up alot of room on the UI seems preferable. Perhaps a drop down image selection ? I would add that the initial tile and its handles could be in 'bold' and the reflections etc be drawn 'weaker' and so the effect of handle manipulation can be more clearly adjusted interactively. A weaker 'reflection' also allows you an excuse to operate with simpler proxy copies of the original - which could be replaced with proper curves etc on handle release. To further control the amount of drawing, a "preview generations" numeric field could indicate how many of the tiling 'reflections' to actually draw. E.g. 1 would show only the first level 'reflections' of the tile, and a 2 would show a further level. 1 or 2 would probably suffice in most cases to visually see the effect of the tiling at a useful scale for design. Then - similar to the preview button on existing extensions - making it could then extend out to some kind of boundary. As you say a rectangle, or perhaps a clipping region of some kind, or a defined number of 'reflections' of the tile operator. Ideally the tile generator would be a widget which could be modified at any time - similar to existing tools like the box. Just my 2 cents. Thanks for having a go at this - its coming along very well - I'm very much looking forward to the result. Mark... On 3/24/2012 6:10 AM, Valerie wrote: >> http://i.imgur.com/DMCvU.png > Oh phew, thank you so much for making that! I was trying to make something like that too but a bit different, and some of those symmetries were starting to make me feel Very cross-eyed. > > Basically I was thinking that a table for all the tiling types > (both wallpaper and Frieze) with the following visual guides would > be useful: > 1. The base tile guide with no transformation indicators > 2. The base tile guide with indicators (use can toggle indicators > on and off) > 3. The preview when creating the guide (either what you did here, > or Thorsten's previews) > 4. An outline preview of extra tiles (can be toggled on and off, > shows basically the outline of those extra tiles as you've made here) > 5. My idea was to also make base tile guides that show you which > tile side ends up reflected on which side. This is meant to help > a person who wants to program the "guide points" feature: > - Two "corresponding" sides will be represented by dotted lines of > the same colours. (example: for simple translation, the left and > right sides would be dotted lines of one colour, and the up and > down sides of another colour). An arrow marks the "direction" of > each side. > - Each side that transforms onto itself is represented by a full > line. It is marked either by a single arrow (if the transformation > is in the same direction) or two arrows in opposite directions (if the tile is flipped) > 6. Base tiles again, this time with examples of guide points > and guide segments. > > (yeah, that makes a lot...) > >> I do have to throw out there at this point, the proposed UI >> for tiling at http://wiki.inkscape.org/wiki/index.php/Tiling_tool is incredibly complex. One of the benefits to a dedicated tool is actually being able to manipulate parameters on-canvas. > Are you reading the latest version (there were many versions...)? > Because all the things that can be manipulated on canvas Are manipulated on-canvas... The dialogue is only choosing options > (there are a lot of options... much more than your average LPE, > even), the number of copies, and hitting "apply" (none of which > are really on-canvas interactions). > > I've thought of the use of tile shadow outlines to help users see > what will be rendered. The problem is dynamics. They make the > tile outlines unpredictable in the first place... That's why I came up > with extra render "target" options, so users can choose to render > over a specific, non-rectangular area, or even better, to render > as a target's pattern (if .svg allows that), so users can then > manually control any offsets with the pattern tool. > > Now, I was actually thinking about on-canvas handles for > manipulating dynamics, but that's a whole other can of worms... > (and given the time needed to render dynamic tiles, I'm not so > sure it's such a good idea to have them updated live...) > > I'm open to suggestions though. I've made a number of mock-ups > proposals for tilings until now, and this is just the latest iteration > (the... fifth I think? If I count the few ideas I first had a few years > ago). If someone has a general direction in mind (beyond "it has > to be a tool"), I can try to see if I can work out something. > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

1 0

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 23 Mar '12

23 Mar '12

> http://i.imgur.com/DMCvU.png Oh phew, thank you so much for making that! I was trying to make something like that too but a bit different, and some of those symmetries were starting to make me feel Very cross-eyed. Basically I was thinking that a table for all the tiling types (both wallpaper and Frieze) with the following visual guides would be useful: 1. The base tile guide with no transformation indicators 2. The base tile guide with indicators (use can toggle indicators on and off) 3. The preview when creating the guide (either what you did here, or Thorsten's previews) 4. An outline preview of extra tiles (can be toggled on and off, shows basically the outline of those extra tiles as you've made here) 5. My idea was to also make base tile guides that show you which tile side ends up reflected on which side. This is meant to help a person who wants to program the "guide points" feature: - Two "corresponding" sides will be represented by dotted lines of the same colours. (example: for simple translation, the left and right sides would be dotted lines of one colour, and the up and down sides of another colour). An arrow marks the "direction" of each side. - Each side that transforms onto itself is represented by a full line. It is marked either by a single arrow (if the transformation is in the same direction) or two arrows in opposite directions (if the tile is flipped) 6. Base tiles again, this time with examples of guide points and guide segments. (yeah, that makes a lot...) > I do have to throw out there at this point, the proposed UI > for tiling at http://wiki.inkscape.org/wiki/index.php/Tiling_tool > is incredibly complex. One of the benefits to a dedicated tool > is actually being able to manipulate parameters on-canvas. Are you reading the latest version (there were many versions...)? Because all the things that can be manipulated on canvas Are manipulated on-canvas... The dialogue is only choosing options (there are a lot of options... much more than your average LPE, even), the number of copies, and hitting "apply" (none of which are really on-canvas interactions). I've thought of the use of tile shadow outlines to help users see what will be rendered. The problem is dynamics. They make the tile outlines unpredictable in the first place... That's why I came up with extra render "target" options, so users can choose to render over a specific, non-rectangular area, or even better, to render as a target's pattern (if .svg allows that), so users can then manually control any offsets with the pattern tool. Now, I was actually thinking about on-canvas handles for manipulating dynamics, but that's a whole other can of worms... (and given the time needed to render dynamic tiles, I'm not so sure it's such a good idea to have them updated live...) I'm open to suggestions though. I've made a number of mock-ups proposals for tilings until now, and this is just the latest iteration (the... fifth I think? If I count the few ideas I first had a few years ago). If someone has a general direction in mind (beyond "it has to be a tool"), I can try to see if I can work out something.

2 1

Release of binaries
by Johan Engelen 23 Mar '12

23 Mar '12

Hi all, Apparently, there is a policy to release binaries at the same time, instead of simply uploading them to Sourceforge whenever they become available. I would like to see this changed to the latter option. I see no point in why people on one platform would have to wait for binaries becoming available on the other. Thanks for your consideration, Johan

5 6

QR code request.
by john Culleton 23 Mar '12

23 Mar '12

I note that Inkscape offers the Datamatrix bar code as an option. However another 2d bar code is now in common use, the QR code which can be read by many handheld devices. I wonder if a QR generator could be added to Inkscape, perhaps as a GSOC project. -- John Culleton Free list of books for self-publishers: http://wexfordpress.net/shortlist.html Police Procedural and Expose: "Death Wore Black" "Create Book Covers with Scribus" http://www.booklocker.com/books/4055.html

3 2

Additional print file outputs.
by john Culleton 23 Mar '12

23 Mar '12

The printer Lightning Source Inc. will only accept print files for book covers in the form of PDF X/1-a:2001 or TIFF. Neither is available from Inkscape 0.48.2. While conversion of a png file is available through ImageMagick or GraphicsMagick this requires use of the the command line which the current generation has been taught to fear. So I wonder if one or both options could be built in to a future version of Inkscape. Perhaps this could be a GSOC project. -- John Culleton Free list of books for self-publishers: http://wexfordpress.net/shortlist.html Police Procedural and Expose: "Death Wore Black" "Create Book Covers with Scribus" http://www.booklocker.com/books/4055.html

1 0

0.48.3.1 Windows installer
by Krzysztof Kosiński 23 Mar '12

23 Mar '12

Hello all I have a Windows installer ready, and it seems to work correctly. It is 36 MB, so too big to send via email. Where should I upload it so that others might test? Regards, Krzysztof

8 10

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 22 Mar '12

22 Mar '12

> Yes, the Rosetta group has two basic patterns: simple rotations > (restricted to angles that evenly divide into 360) and rotation plus > reflection - I didn't see the reflection option in your design, perhaps > I missed it. It's in the Tiling dialogue mock-up for Radial tiling, and in the description of the work sequence for the "Add tiling type" section. I guess I should make a table with the transformation options, and add the Frieze options while I'm at it. On the previews: I'm actually trying to keep the guides themselves as uncluttered as possible where extra indicators are concerned. That's because one look at the detailed wikipedia base tiles convinced me that they're more confusing than helpful. As I said, there already are previews, before you create the guides. I think that they're enough to give users an idea of what's going on. Besides, the shapes themselves usually give a clue as to what the transformation will be (if it's a triangle, you know that it isn't simple translation). The guides can be transformed like any other object, so you can resize, rotate and flip them like normal objects. I believe the guide points feature is more useful than giving more indicators on the guides themselves: at the end of the day, when the user is designing a seamless tile, what he needs to know most is how a line going out of the tile will connect to the next tile. What happens to the corner of the base tile isn't as useful. Here's the description again: > When a guide point is created on one side of a guide, counterparts > are automatically created on all other sides of the basic guide. All > changes to the original will be reflected onto the new tile. > What's more, you can click and drag this guide to create a guide > segment. By snapping a node on a guide point and snapping its > handle to the end of the guide segment, and by repeating the > operation with the node's counterpart, the user can create smooth > transitions from one tile to the next. Guide points can be moved along the corners of the guides. When you do so, all its counterpoints are updated dynamically. I guess the current mock-ups aren't clear enough, I'll have to make a few new ones. Look at this program: http://www.cgl.uwaterloo.ca/~csk/software/penrose/ Unlike this program, the guide points can be moved along the sides of the guide. Like this program, by dragging on some of them, a segment is created that also appears on all the guide points' counterparts. Do you understand the concept now? You can know exactly how a line going out of the tile will go back in. As for the tiling shadow, the problem is how many tiles will be displayed. Controlling the number of tiles must be done from the tiling dialogue rather than from the tiling guide tool. I guess I could add a "show tiles outline" option to the tiling dialogue.

4 6

Re: [Inkscape-devel] Inkscape GIS
by Stefan de Konink 21 Mar '12

21 Mar '12

On 17-03-12 20:55, Brylie Oxley wrote: > Thank you for suggesting Mapnik Stefan! :-) Inkscape would be a suitable > GUI for a Mapnik based cartography solution. I do not think that > Inkscape and Mapnik are necessarily in opposition, do you? The major problem is, if you look at cartography to SVG is that data is not offered in layers you would actually use in regular print. The output of mapnik is actually a set of drawing commands. So your audience might require two approaches; - ability to get an arbitary piece of a map, and the ability to interactively edit the stylesheet, see output etc. Inkscape could help here because stylesheets contain a lot of SVG elements you want to edit along the map; the result of this operation is a stylesheet, and a set of icons. - the ability to get arbitrary data in layers and be your own renderer, stack layers, assign decimation, add colours etc. this would be closer to having a shapefile in a solution like Illustrator and modifying it. Opposed to mapnik this step requires the editor to do 'layer' operations theirselves. Stefan

1 1

Running Inkscape from non-default location (Ubuntu)
by Jeremy Villalobos 21 Mar '12

21 Mar '12

Hello: I checked out and built Inkscape 0.49x on Ubuntu following the Guide's instructions http://wiki.inkscape.org/wiki/index.php/CompilingUbuntu But when I run the program from the non-standard location, the 0.48x version pops up (the one instaleed with the repo manager) What env vars do I have to set/modify to run the program from the non-default location. Or does 0.49x has the wrong version being reported ? thanks Jeremy

4 3

PLEASE UNSUBSCRIBE
by a kayzar 20 Mar '12

20 Mar '12

1 0

Mathematical Art for teenagers
by veronika 19 Mar '12

19 Mar '12

Hi, I am a PhD candidate in Computer Science at the University of Victoria (Victoria, BC, Canada) and I am interested in the GSoC program. I am interested in the exploration of Math through the creation of Digital Art and how this can be used in classrooms and after school clubs to promote interest in Math and develop skills particularly among students in the age range 13 to 18. I have conducted an after school club with students in which we used Inkscape, Scratch/BYOB and various applets. Some of the results from this club can be seen in my blog: http://visquest.blogspot.ca. There are several projects that I would be interested in working on. One area is to take a topic such as Tessellations and fill out the tool set as needed to make these projects accessible for young teenagers. There is an excellent web site (http://www.tessellations.org) which describes many techniques for creating tessellations and there is a tutorial for performing the basic steps in Inkscape (http://www.digitalartforall.com/1267/inkscape-creating-tessellations/), together these make a very good starting point. Some of the places where students stumble are 1) Understanding commands such as Path-Division and Path-Union 2) Performing Translation and Rotation so that the pieces line up correctly (need a way to mark an alignment guide on both pieces based on style of tessellation) 3) The Tiling dialog is very complicated and does not support an iterative approach. Another area is to look at the learning potential for something like the Spirograph extension (or L-System extension or many other extensions) and how it could be improved. For example, there is quite a lot of interesting math to explore with hypertrochoid and epitrochoid curves, however, the current dialog approach does not give the user an intuitive understanding of how the circles move relative to one another. In contrast, the Spiromath applet (http://www.mathplayground.com/Spiromath.html) gives nice visual feedback about the relative motion but is very limited in its drawing capabilities. A fun project would be to turn the Spirograph extension into a tool, extend it to allow for shapes other than circles and give more direct control over things like pen position, number of revolutions (including the ability to rewind if it has gone too far) etc. I am interested in using Inkscape in my thesis research as a key part of a Mathematical Art environment and would welcome the opportunity to work with a mentor. I am interested in gaining experience developing tools and extending the user interface. Kind regards, Veronika -- View this message in context: http://inkscape.13.n6.nabble.com/Mathematical-Art-for-teenagers-tp4632081p4… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 1

Re: [Inkscape-devel] Mathematical Art for teenagers
by Valerie 19 Mar '12

19 Mar '12

Hi Veronica! Alright, now I understand why you were asking about the visual references for the tiling guides. I was approaching the issue from a "need as little prior knowledge as possible" approach, while you are interested in an educational approach. That could be solved simply enough. There could be an option to toggle indicators and markers on and off, and maybe show "neighbouring tiles." I'll try to add such options to the existing mock-up. :)

2 1

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 19 Mar '12

19 Mar '12

Thanks for the link! - The Frieze groups are definitely interesting! I'll add those to the current mock-ups once I have the time. They should help make border designs easier. - The Rosetta groups seem to be just Simple Rotations and Symmetry + Rotations though. Am I missing something? I'm not sure what you mean by rotation points, reflection lines etc. that can be moved though. They don't exist as separate points, they're just the borders and corners of the guides. A guide defines the shape of the base tile. You modify the guide itself, not points along the guide. (example: simple translation has a rectangle guide. You can easily change the dimensions of this rectangle, though it will stay a rectangle). Are you referring to my notion of guide points? Guide points are separate points that when added to one side of a guide, create counterparts on other relevant sides of the guide, so you know where you add lines in a way to create seamless transitions from one tile to the next. They're made so that a user would need 0 knowledge of wallpaper geometry when creating seamless tiles: they just need to connect to the guide points. I should have made a visual reference of guides and guide point behavior for each tiling type, but the truth is, I'm pretty confused about tiling behaviour myself. :S That's the whole reason I tried to come up with an interface that basically requires 0 prior knowledge. x) ------------------------------ Message: 6 Date: Sat, 17 Mar 2012 11:55:16 -0700 (PDT) From: veronika <vmi@...2827...> Subject: Re: [Inkscape-devel] New tiling interface proposal To: inkscape-devel(a)lists.sourceforge.net Message-ID: <1332010516483-4628619.post@...2730...> Content-Type: text/plain; charset=us-ascii You have covered the topic very well. Another example to look at is the Kali applet: http://www.scienceu.com/geometry/handson/kali/index.cgi?group=wt For Tiling along the Path you could support the seven Frieze groups and for Rotational tiling you could support the Rosette groups. In the guides for a given symmetry group, you could show the rotation points (along with their degree) as well as reflection lines, glide reflection lines and translation directions and lengths. I think you briefly describe these ideas in your document but since there is quite a lot going on here it may be useful to spell it out in detail for each symmetry group. The user should be able to move these guide lines and points as long as they stay within the constraints of the chosen symmetry group. Below is a picture of guides for symmetry p6m (colours just used for visibility but should conform to guidelines elsewhere): http://inkscape.13.n6.nabble.com/file/n4628619/wallpaper.png The book "The Symmetry of Things" by Conway, Burgiel and Goodman-Straus has some very nice visualizations for reference. -- View this message in context: http://inkscape.13.n6.nabble.com/New-tiling-interface-proposal-tp4570734p46… Sent from the Inkscape - Dev mailing list archive at Nabble.com. ------------------------------ Message: 7 Date: Sat, 17 Mar 2012 21:03:47 +0100 From: Stefan de Konink <stefan@...2063...> Subject: Re: [Inkscape-devel] Inkscape GIS To: brylie@...2823..., Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> Message-ID: <4F64EE23.3050006@...2063...> Content-Type: text/plain; charset=UTF-8; format=flowed On 17-03-12 20:55, Brylie Oxley wrote: > Thank you for suggesting Mapnik Stefan! :-) Inkscape would be a suitable > GUI for a Mapnik based cartography solution. I do not think that > Inkscape and Mapnik are necessarily in opposition, do you? The major problem is, if you look at cartography to SVG is that data is not offered in layers you would actually use in regular print. The output of mapnik is actually a set of drawing commands. So your audience might require two approaches; - ability to get an arbitary piece of a map, and the ability to interactively edit the stylesheet, see output etc. Inkscape could help here because stylesheets contain a lot of SVG elements you want to edit along the map; the result of this operation is a stylesheet, and a set of icons. - the ability to get arbitrary data in layers and be your own renderer, stack layers, assign decimation, add colours etc. this would be closer to having a shapefile in a solution like Illustrator and modifying it. Opposed to mapnik this step requires the editor to do 'layer' operations theirselves. Stefan ------------------------------ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ------------------------------ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel End of Inkscape-devel Digest, Vol 70, Issue 16 **********************************************

2 1

Problem using GDB on Windows
by veronika 18 Mar '12

18 Mar '12

Hi, I am new to Inkscape development and I am trying to use gdb on Windows. Using the latest source from trunk (via bazaar), I followed the instructions on the wiki, modified the build.xml and did a full re-build. I have no problem building the executable and launching the executable but when I try to debug it, I get an error immediately after the main window opens: warning: HEAP[inkscape.exe]: warning: HEAP: Free Heap block 1621e0d8 modified at 1621e258 after it was freed Program received signal SIGTRAP, Trace/breakpoint trap. 0x772504e5 in ntdll!TpWaitForAlpcCompletion () from C:\Windows\system32\ntdll.dll The backtrace appears at the end of this post. I have tried both the gdb executable that comes with devlibs and the one installed with mingw - both give the same result. I have been able to use gdb with Inkscape on Linux with no problem. Any suggestions? Has anyone else encountered this problem? Thank you for your help. Veronika [New Thread 3380.0x3a8] [New Thread 3380.0x10cc] [New Thread 3380.0x12a8] [New Thread 3380.0xa44] [New Thread 3380.0xf6c] [New Thread 3380.0x774] warning: HEAP[inkscape.exe]: warning: HEAP: Free Heap block 1621e0d8 modified at 1621e258 after it was freed Program received signal SIGTRAP, Trace/breakpoint trap. 0x772504e5 in ntdll!TpWaitForAlpcCompletion () from C:\Windows\system32\ntdll.dll (gdb) backtrace #0 0x772504e5 in ntdll!TpWaitForAlpcCompletion () from C:\Windows\system32\ntdll.dll #1 0x0028e8e8 in ?? () #2 0x7720a383 in ntdll!AlpcMaxAllowedMessageLength () from C:\Windows\system32\ntdll.dll #3 0x1621e0d8 in ?? () #4 0x771b35a7 in ntdll!RtlReleasePebLock () from C:\Windows\system32\ntdll.dll warning: (Internal error: pc 0x4a in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x4a in read in psymtab, but not in symtab.) #5 0x0000004b in ?? () warning: (Internal error: pc 0x4a in read in psymtab, but not in symtab.) #6 0x771b3492 in ntdll!LdrLoadAlternateResourceModuleEx () from C:\Windows\system32\ntdll.dll #7 0x1621e330 in ?? () #8 0x7725169e in ntdll!RtlValidateHeap () from C:\Windows\system32\ntdll.dll #9 0x0e9e0000 in ?? () #10 0x7720ab9a in ntdll!AlpcMaxAllowedMessageLength () from C:\Windows\system32\ntdll.dll #11 0x0e9e0000 in ?? () #12 0x771b3492 in ntdll!LdrLoadAlternateResourceModuleEx () from C:\Windows\system32\ntdll.dll #13 0x1621e330 in ?? () #14 0x75b198cd in msvcrt!free () from C:\Windows\syswow64\msvcrt.dll #15 0x0e9e0000 in ?? () #16 0x6aa0178a in sigc::signal_base::~signal_base() () from c:\veronika\research\inkscape\src\trunk\inkscape\libsigc-2.0-0.dll #17 0x00429b92 in ~signal1 (this=0x1621df04, __in_chrg=<optimized out>) at c:/devlibs/include/sigc++-2.0/sigc++/signal.h:2736 #18 ~signal (this=0x1621df04, __in_chrg=<optimized out>) at c:/devlibs/include/sigc++-2.0/sigc++/signal.h:3641 #19 SPObject::sp_object_finalize (object=0x1621dec8) at src/sp-object.cpp:199 #20 0x63a46492 in g_object_unref () from c:\veronika\research\inkscape\src\trunk\inkscape\libgobject-2.0-0.dll #21 0x00429791 in sp_object_unref (object=0x1621dec8, owner=0x0) at src/sp-object.cpp:270 #22 0x0042a12f in SPObject::deleteObject (this=0x1621dec8, propagate=false, propagate_descendants=false) at src/sp-object.cpp:494 #23 0x00c11b93 in deleteObject (propagate=<optimized out>, this=<optimized out>) at src/sp-object.h:471 #24 MarkerComboBox::create_marker_image (this=0x1619c928, psize=22, mname=0x13493180 "Arrow1Lend", source=0x124b4e40, drawing=...) at src/widgets/stroke-marker-selector.cpp:345 #25 0x00c12238 in MarkerComboBox::add_markers (this=0x1619c928, marker_list=0x16114e00, source=0x124b4e40) at src/widgets/stroke-marker-selector.cpp:306 #26 0x00c126bb in MarkerComboBox::sp_marker_list_from_doc (this=0x1619c928, source=0x124b4e40) at src/widgets/stroke-marker-selector.cpp:263 #27 0x00c12bfe in MarkerComboBox::init_combo (this=0x1619c928) at src/widgets/stroke-marker-selector.cpp:126 #28 0x00c13883 in MarkerComboBox::MarkerComboBox (this=0x1619c928, id=0x1621e0d8 "K", __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at src/widgets/stroke-marker-selector.cpp:68 #29 0x00b2e69e in sp_stroke_style_line_widget_new () at src/widgets/stroke-style.cpp:471 #30 0x00739b28 in Inkscape::UI::Dialog::FillAndStroke::_layoutPageStrokeStyle (this=0x16150978) at src/ui/dialog/fill-and-stroke.cpp:123 #31 0x0073a30a in Inkscape::UI::Dialog::FillAndStroke::FillAndStroke (this=0x16150978, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at src/ui/dialog/fill-and-stroke.cpp:64 #32 0x00db4a10 in getInstance () at src/ui/dialog/fill-and-stroke.h:35 #33 Inkscape::UI::Dialog::PanelDialog<Inkscape::UI::Dialog::Behavior::DockBehavior>::create<Inkscape::UI::Dialog::FillAndStroke> () at src/ui/dialog/panel-dialog.h:186 #34 0x004fd024 in Inkscape::UI::Dialog::(anonymous namespace)::create<Inkscape::UI::Dialog::FillAndStroke, Inkscape::UI::Dialog::Behavior::DockBehavior> () at src/ui/dialog/dialog-manager.cpp:68 #35 0x004fdf65 in getDialog (name=3267, this=0x13207190) at src/ui/dialog/dialog-manager.cpp:236 #36 Inkscape::UI::Dialog::DialogManager::getDialog (this=0x13207190, name=3267) at src/ui/dialog/dialog-manager.cpp:224 #37 0x004fe106 in Inkscape::UI::Dialog::DialogManager::showDialog (this=0x1621e0d8, name=3267) at src/ui/dialog/dialog-manager.cpp:257 #38 0x00d6e4e7 in operator() (this=0x1326fe9c, _A_a1=<optimized out>, _A_a2=<optimized out>) at c:/devlibs/include/sigc++-2.0/sigc++/functors/ptr_fun.h:147 #39 operator()<SPAction*&, void*&> (this=0x1326fe98, _A_arg1=<optimized out>, _A_arg2=<optimized out>) at c:/devlibs/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:103 #40 operator()<SPAction*&> (this=0x1326fe94, _A_arg1=<optimized out>) at c:/devlibs/include/sigc++-2.0/sigc++/adaptors/bind.h:1122 #41 operator() (this=0x1326fe90) at c:/devlibs/include/sigc++-2.0/sigc++/adaptors/bind.h:1110 #42 sigc::internal::slot_call0<sigc::bind_functor<-1, sigc::bind_functor<-1, sigc::pointer_functor2<SPAction*, void*, void>, void*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>, SPAction*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>, void>::call_it (rep=0x1326fe78) at c:/devlibs/include/sigc++-2.0/sigc++/functors/slot.h:103 #43 0x00470dc9 in emit (impl=<optimized out>) at c:/devlibs/include/sigc++-2.0/sigc++/signal.h:773 #44 emit (this=<optimized out>) at c:/devlibs/include/sigc++-2.0/sigc++/signal.h:2668 #45 sp_action_perform (action=0x13276560) at src/helper/action.cpp:164 #46 0x00539226 in SPDesktop::show_dialogs (this=0x124d4d20) at src/desktop.cpp:1845 #47 0x004374eb in sp_namedview_window_from_document (desktop=0x124d4d20) at src/sp-namedview.cpp:845 #48 0x0045b6da in sp_file_new (templ=...) at src/file.cpp:136 #49 0x0045ba2e in sp_file_new_default () at src/file.cpp:182 #50 0x00403b25 in sp_main_gui (argc=1, argv=0xeb3a908) at src/main.cpp:976 #51 0x00ef218f in main (argc=1, argv=0xeb3a908) at src/main.cpp:711 -- View this message in context: http://inkscape.13.n6.nabble.com/Problem-using-GDB-on-Windows-tp4628229p462… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

5 6

Problematic documentation changes in r10697
by Krzysztof Kosiński 18 Mar '12

18 Mar '12

Revision 10697 moved most of the documentation from .cpp to .h files. This means extensive recompilation whenever a documentation change is made, and therefore it discourages improving documentation for no obvious gain. If there was a desire to have all the docs in one file, they should have been moved to the .cpp file with the help of commands such as @class and @var. Unfortunately this revision mixes the pointless moves with useful fixes, so I can't simply revert it. Regards, Krzysztof

1 0

New tiling interface proposal
by Valerie 17 Mar '12

17 Mar '12

I redid the whole thing... again. http://wiki.inkscape.org/wiki/index.php/Tiling_tool This is the first among my proposals with a consistent behavior from start to finish (at least, I think so), and doesn't look like a badly-proportioned three-headed Frankenstein. A picture is worth a thousand words so.... this is the target behavior: http://wiki.inkscape.org/wiki/images/Tiling_interface_examples.png In fact, I now divide the tiling "tool" into 2 parts (then further divided the whole proposal into hopefully more manageable sub-parts): 1. A general tiling guide tool whose only interacting with the tiling process is to send it coordinates (the type that no-one wants to input manually). http://wiki.inkscape.org/wiki/images/Tiling_Guide_Toolbar.png 2. The tiling -process- is back in a dialogue. This is because no matter what I did, it wouldn't stuff into a toolbar, and having separate "tools" was becoming a bit ridiculous. However, all the things that need to be "on-canvas" (the guide, basically) is now on-canvas. The only numerical values you need to input manually are intuitive ones like the number of clones and maybe a start and finish angle. And values for dynamics, but I haven't figured out an on-canvas way to handle those as the same time as basic tile information... http://wiki.inkscape.org/wiki/images/Tiling_dialogue_proposal.png Also, this interface allows you to stack tilings, and could also integrate into whatever future Effects Stacking interface Inkscape comes up with. >From a single tile, you can define not only the interior tiles, but "edge" scenarios as well. The feature involved here is actually a simple cut, delete and join operation: Inkscape cuts the pattern along certain guides, deletes the parts that need deleting, and does a "Select all nodes" and "Join" operation. (of course, on this occasion, I discovered that Inkscape can't actually cut groups of objects yet, oh well) If you placed all the tile elements in a way to create seamless tiles (that's where Guide Points are supposed to help), then all the tiles will proceed to join up seamlessly, even with small variations (though not big ones). Hopefully this is a good start for others to come up with even better possibilities. Thoughts?

2 1

Inkscape GIS
by Brylie Oxley 17 Mar '12

17 Mar '12

Hello, My name is Brylie Oxley. I am a student at Sierra College in Nevada City, CA. I would like to apply for the GSoC program. I have been studying GIS at Sierra College, where the courses focus on proprietary tools. For libre GIS tools to be viable options, we need high quality cartographic tools. This is where I see Inkscape as an EXCELLENT candidate. With some effort and extension, Inkscape can be used as an integrated cartographic tool in a libre GIS workflow. The primary goal of the extension would be to enable Inkscape to receive/display information from one or more Libre Geospatial tools/data sources (such as QGIS, PostGIS, GeoServer, MapServer, OpenStreetMap, OpenLayers, and/or GRASS GIS.) Python would seem to be a good candidate language as there are already Python bindings in Inkscape, QGIS, and GRASS. The primary task of the extension would be to send/receive geodata, so most of the heavy lifting might be able to be done by existing modules (specifically GDAL/OGR.) http://grass.osgeo.org/wiki/GRASS_and_Python#Writing_Python_scripts_in_GRASS http://www.qgis.org/pyqgis-cookbook/ http://pypi.python.org/pypi/GDAL I feel that this is a very important step for the viability of libre geospatial and would appreciate any mentorship and feedback that this community can offer. Thank you very much for your time and consideration. --Brylie Oxley

2 1

EAN% barcode.
by john Culleton 17 Mar '12

17 Mar '12

My copy of 48.2 has the EAN5 barcode available. The latest version of the Tavmong Bah book does not list it. Is EAN5 part of the distro now? I remember adding it separately to 48.0. EAN5 is used for the price barcode on books, and is included with e.g., Scribus. -- John Culleton Free list of books for self-publishers: http://wexfordpress.net/shortlist.html Police Procedural and Expose: "Death Wore Black" "Create Book Covers with Scribus" http://www.booklocker.com/books/4055.html

5 5

Google Summer of Code 2012
by Josh Andler 16 Mar '12

16 Mar '12

Hi All, I just wanted to shoot out a message to let people know that we've been accepted as a mentoring organization again this year. If you know any college or graduate school students who would qualify and be interested, please let them know, we would like to talk to them. :) Cheers, Josh

1 0

Bug tracker maintenance
by Josh Andler 16 Mar '12

16 Mar '12

Hey everyone, If you're a developer and have a chance sometime soon, please visit the bug tracker to view what bugs are assigned to you. If you feel a bug assigned to you is wrongly assigned or that it is unlikely that you will work on that bug, please unassign yourself. We don't want to discourage anyone from taking on a bug because someone else's name is on it. As long as my LP-fu isn't bad (forget the stats on the bug page, I did it not including bugs marked "fix committed") the bug tracker currently has 1,791 open bugs (wishlist not included), 748 are marked as new, 167 marked High, and it appears that bugs w/ patches is at 84. Those numbers aren't horrible, but I'm sure there are a number of bugs that can probably be closed at this point. If you don't code, but want to help the project, you can give us a hand by trying to help us reduce the number of "New" bugs mentioned above. Trying to reproduce bugs is always helpful if they're not confirmed or if it looks like it was last confirmed a couple years back (or on old versions). I'm not sure if the tracker is as open as it was, but hopefully you can modify the status and such without needing to be a team member. If so, please review http://wiki.inkscape.org/wiki/index.php/Bug_management to find out how we do things. Any Qs, as always, please don't hesitate to contact me. Cheers, Josh

2 1

Re: [Inkscape-devel] Meeting: build system on Windows
by Johan Engelen 15 Mar '12

15 Mar '12

On 9-3-2012 10:00, Jasper van de Gronde wrote: > On 08-03-12 21:52, Johan Engelen wrote: >> Hi all, >> I would like to have an IRC meeting about the build system on >> Windows. >> >> Although I like buildtool, it cannot do parallel builds, so I am happy >> to change (back) to something else. And unify it with Linux if >> possible... >> I am trying cmake now, but it does not link without errors yet. It is >> not very encouraging to see the cmake build process get stuck on some >> intermediate step for a long while, seemingly checking something to find >> out it does not need to rebuild it. "btool" does this much much >> quicker... >> >> In any case, I'd like to discuss the options. Who's in? > > Depends on when the meeting is, but I wouldn't mind participating. > > And here's an alternative option: use buildtool on Linux as well. > Seriously. Yes, buildtool has its deficiencies, and it is much less > flexible than *make, but it is /so/ much easier to use and maintain (the > build file itself I mean, not buildtool). I'm completely unaware of the > issues involved in getting it to work on Linux, so perhaps it's just not > very feasible. Or perhaps I'm unaware of some of the issues buildtool > has on Windows. But I would hate to see buildtool go and be replaced by > some other monster of a build system just because it couldn't do > parallel builds (which should in principle be fixable). This of course triggered me to see if I could hack buildtool to do parallel builds. It turns out to be extremely easy to do so! See rev. 11087 Rebuild buildtool with "-fopenmp" and then you should be able to use the "-j" (20 parallel threads) option or e.g. "-j 4" (4 threads). Needless to say this speeds up a clean build tremendously on i7 2600K: 7 minutes. It is somewhat buggy, but who cares You have to run btool once more without "-j" to get a build done. Someone should be able to fix that... Cheers! Johan

2 1

Circular Arrangement
by Denis 14 Mar '12

14 Mar '12

Hi Community, I wrote some days ago about circular arrangement. I'm still busy writing a proposal document (which I need for the Software Engineering course, this project is part of). As soon as I finish, I'll let you know. In the meantime, I've done some mockups, you can find at http://www.pasteall.org/pic/28214. Let me know what you think. - The first part of the dialog("Anchor Point") is the point that should be used to arrange the objects on the circle. - The second part is used to select what the circle/ellipse/arc to put the objects on is. Note: I've put Radius x/y in there, because this allows to have ellipses. - The angles are used to describe an arc - Finnaly if Rotate objects is turned on, the objects on the circle will be rotated (e.g. If you're trying to arrange the stars in the european flag, you should turn this option off) By the way, as someone suggested, I should put this feature in the "Rows and Columns" panel. As IMHO this panel is somewhat messy (especially the align selection), I also thought of ways to improve that. Denis Declara

2 2

Surface synthesizer?
by Jasper van de Gronde 13 Mar '12

13 Mar '12

Is there any particular reason that the morphology filter uses something called a "surface synthesizer" (or something along those lines)? Its time complexity currently depends on the structuring element size, and I wanted to fix that, but to do that I need to be able to keep some history, as well as delaying the output until enough data has been gathered. Is this possible at all within this scheme? If not, is it okay if I just copy-paste ink_cairo_surface_synthesize - gut it - and write a few simple loops? (Or am I missing something?)

2 3

Nightly 0.49 download/compile.
by john Culleton 13 Mar '12

13 Mar '12

I build the latest and greatest Scribus versions overnight. Now I would like to do the same for Inkscape 0.49.x. If possible I would like to do an svn download. If not just a tarball of the source would do. If Bazaar is the only path I will learn that. But I prefer the more familiar svn path. I have Slackware Linux, and don't want to make an Ubuntu partition just for Inkscape. Please show me the pointers needed to download the latest 0.49 nightly. -- John Culleton Free list of books for self-publishers: http://wexfordpress.net/shortlist.html Police Procedural and Expose: "Death Wore Black" "Create Book Covers with Scribus" http://www.booklocker.com/books/4055.html

4 5

New Cairo release rumors...
by Tavmjong Bah 12 Mar '12

12 Mar '12

A couple of weeks ago on the Cairo mailing list there was a request for a release engineer to drive Cairo 1.12 home. Do we have anything that we want to see in the next Cairo release? I seem to recall there being an issue with being able to set the EPS bounding box. Any others? Tav

3 6

CMake: parallel builds
by Johan Engelen 11 Mar '12

11 Mar '12

Hello all, Does the cmake build work well on Linux? I wonder if parallel builds work with it. For lib2geom, which uses cmake, parallel building does not work. If it works for Inkscape, we can try to compare and see where things go wrong for lib2geom... Thanks, Johan

3 3

Feature proposal: erase mode (and other boolean modes) for drawing tools
by Valerie 11 Mar '12

11 Mar '12

I'm just running this by the mailing list to see if it's worth a feature proposal before submitting it. Feature: boolean modes for all drawing tools. 1. Select an existing object 2. Select a tool of your choice (say... Pencil), with Exclude mode activated for example. (boolean modes appear as small icons in the toolbar) 3. When you draw a shape, the originally selected object does not get un-selected. When you finish drawing your shape, Inkscape automatically chips away at the original shape. The original shape still does not get un-selected until you select something else, so you can continue chipping away at it. Exclude is just one mode, you can have addition, intersection, etc. It applies to both drawing tools and shape tools. I was inspired for this by 2 things: - Krita's "erase" mode. You can basically take any paint tool and activate an erase mode to make the eraser much more interesting. - I never use the eraser. The round shape just isn't too convenient. : ( Thinking about it now, Gimp has similar options for selection tools. I often draw a rough shape and slowly refine it by zooming in before adding to it or chipping away at it, so this feature would streamline the workflow a lot. (also, it took me a while to remember the boolean operations, I imagine shortcut-phobic users would appreciate this feature a lot) Also makes it easy to make quick holes.

1 0