- Inkscape Devel - Inkscape Mailman

LPE crashes
by lapnect 26 Aug '07

26 Aug '07

I have just played with LPE and I found two ways to crash Inkscape (current SVN trunk). The first way: - draw circle - do *not* convert it to path - select that circle and copy it (ctrl+c) - draw line using freehand tool and select it - press ctrl+shift+7 - press 'Apply' - click on 'Paste' icon The second way: - draw circle - convert it to path - select that circle and copy it (ctrl+c) - draw line using freehand tool and select it - press ctrl+shift+7 - press 'Apply' - click on 'Paste' icon - press ctrl+z (undo) Hope it will be helpful :) -- lapnect

2 1

Fwd: SSnapping (AutoCAD way)
by Joshua Blocher 26 Aug '07

26 Aug '07

I havn't had the chance to watch the video yet, but would something like snap targets work. Let me explain. Targets would be a symbol that appear on viable snap positions I imagine it as a bullseye that appear as soon as you start dragging a node.When you get near a target the it changes from red to green to indicate where its snapping to probably not the best colors for colorblind people but you get the idea. You even as far as different shapes for different snap types. Small coloured squares/dots for grid snaps. Bullseye/circle coloured for nodes I'm not sure to do for line maybe just highlight it. and of course since this is inkscape an option or key combo to toggle them on and off. Joshua L. Blocher verbalshadow On 8/26/07, Jed Frechette <jedfrechette@...400...> wrote: > On Friday 24 August 2007 1:33 pm, Diederik van Lierop wrote: > > The object snapper in ACAD is a bit different: if only snaps after > > clicking the left mousebutton; this way ACAD can show what point will > > be snapped to before doing the actual snapping. Inkscape however snaps > > instantly while dragging: it cannot show what it will snap to, because > > it already has snapped by that time. The only thing we could do is show > > afterwards where it has snapped, which is only useful in cases where > > this is not immediately obvious. For example in selections with a large > > number of nodes, nodes being very close to each other, or at low > > snapping sensitivity. > > Good point, but I still think an on canvas "post"-snap indicator could be > useful. I seem to run in to the non-obvious corner cases pretty regularly. Is > my node snapping to the path or a node on the path? Is the upper left corner > of the bounding box snapping to something on the edge of my drawing or is the > invisible center of rotation snapping to something else? etc. Sometimes I > have no clue what is being snapped to. I suspect bugs in in these cases but I > haven't been sure how to debug them, if anyone has any hints I would be glad > to followup. > > In practice, whenever I'm using snap heavily I simply keep the snap dialog > open and constantly adjust the settings to get what I want. I suspect I would > still need to do this even with a snap indicator but hopefully to a lesser > extent. Of course, I don't know how typical my usage is and unfortunately I > don't have any time to look at the code myself so take my opinions for what > they are worth. > > Best, > > -- > Jed Frechette > http://jdfrechette.alturl.com > > 3722 Dead, 27186 Wounded > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

2 1

Improvements in filtering framework
by Niko Kiirala 25 Aug '07

25 Aug '07

I committed (actually a week ago) some improvements in filtering framework. The main part of this improvement is the new NR::FilterUnits class, which provides tools for handling different coordinate systems in filters. Another big part is moving code for preparing pixblocks from NR::Filter to NR::FilterSlot, where it more conveniently belongs. This means, that now all pixblocks a filter primitive can receive are in same coordinate system. (this fixes bug #1768003) Filter primitives can affect, what this coordinate system is, by overriding the get_input_traits function. Example from gaussian blur: FilterTraits FilterGaussian::get_input_traits() { return TRAIT_PARALLER; } At the moment, the only other possibility is TRAIT_ANYTHING, which is the default, and specifies that filter doesn't care, what the coordinate system is like. (feBlend and feComposite are like this, for example) TRAIT_PARALLER means, that x- and y-axis of the object must be paraller to x- and y-axis of the input image. For example, feGaussianBlur requires this, as the deviation is specified along object x- and y-axis. Only FilterGaussian has this implemented now, it should be implemented in other filters, that need it. I made it use bitfields and called it traits, because I think that this can have a wider use. For example, many filters need 32-bit RGBA images with premultiplied alpha as inputs. We could specify this as trait and move the handling code from the filter primitives to FilterSlot. Also, I'm thinking, that Filter::render and FilterPrimitive::render should be changed to take FilterUnits as an input instead of Matrix. This would give these functions more tools to figure out, where things should be placed, how large the affected area should be, where the bounding box corners are etc. Helper functions for calculating distances, transforming points from user coordinates to image coordinates etc. can also be added to FilterUnits, so that they don't need to be implemented in filter primitives. -- Niko Kiirala

2 1

Tango Icons
by Ryan Lerch 25 Aug '07

25 Aug '07

I was reading the release notes for the upcoming GIMP release (http://gimp.org/release-notes/gimp-2.4.html ), and I noticed that they are updating their icon set to one that adheres to the tango guidelines. I was wondering what everyone thinks about using the inkscape tango icons set(http://gnomelook.org/content/show.php/Tangofied+inkscape+icons+set?conte nt=48140 ) as default. I know that the current revision of this icon set is incomplete in some parts (eg: Tweak and Bucket Fill.) Just thought I would throw the idea out there. Cheers, ryanlerch

7 9

Time to start thinking about a release?
by john cliff 24 Aug '07

24 Aug '07

Hi Guys, Just thought with the SoC over it might be a good time to start thinking about release schedules again, or at least discussing them. Seems like a lot of fun stuff in the SVN build that people want to get their hands on and with the SoC deadline past locking down HEAD shouldnt be as much of an issue. Anyone got something their in the middle of that would be worth waiting for? Any passionate fors or againsts? lets hear what y'all think... Cheers Sim

7 12

Gradients and Pattern Libraries
by ryan lerch 24 Aug '07

24 Aug '07

After a discussion in the IRC channel about gradients and patterns, i have a few queries about them: 1. Do the inkscape/share/patterns and inkscape/share/gradients actually do anything in Inkscape yet? 2. Is there anyone planning to create code for a gradients or pattern library in inkscape, so they can be browsed and imported into the current document. 3. What would be the format for keeping, say gradients in a library? cheers, ryanlerch

8 12

lib2geom python binding
by joel＠...1709... 24 Aug '07

24 Aug '07

Question: are there any plans to make a python lib2geom interface? I've had a really nifty idea for an extension, but it requires bezier curves to be loaded from stock SVG files, and then I need to be able to solve the beziers in X for a given Y coordinate. [can lib2geom even do this?]

1 0

Re: [Inkscape-devel] [Inkscape-user] exporting slices as boxes
by bulia byak 24 Aug '07

24 Aug '07

On 8/17/07, Aaron Spike <aaron@...749...> wrote: > It would be more convenient and require less mental effort for the user > if they could see them. It helps to be able to see all of the boxes, not > just the selected box, while creating new boxes. You can. Just select all and then draw with Rect tool. It will even snap to the existing rects. (It will unselect all but the new one once you finish it, though.) > there is a simple solution. I can select all the boxes and give them > color while I am working with them. But again this is only a work > around. Everything can be called workaround for something else. For example, if we implement your "magic slices" and I want to change their color, I will most likely have to go and search for that in prefs. Which, for me, is a poor workaround for just selecting the boxes I need and clicking on the color palette. > And it require effort from a user to do something that we should > provide a real solution for. No solution is "real". One may be better than another but it does not make it more "real" in any sense. A specialized solution may be more convenient, but it may also be more clumsy and getting-in-the-way of those who don't need it. See, a new specialized feature is worth it if it offers something which is _in principle_ impossible or very hard to do with existing tools. And even if it has some added value, that feature better be very isolated and orthogonal to everything else. Otherwise, if it's instrusive, it must provide some really basic and important facility in order to be considered. The slicing facility is important for many people, check. But doing it via "magic slices" is very intrusive and non-orthogonal because it involves a whole new kind of objects and/or controls that all tools will need to be aware of - no check. And it also does not offer much added value compared to the naive approach, except some conveniences that may be just as well incorporated into existing tools/templates/dialogs - also no check. That's why it does not pass my filter. > > Yes, but this is just one of the dozens of selection methods available > > in Inkscape. Most other methods work fine. > > Could you please list the "dozens" of selection methods? I know we > provide quite a number, perhaps even 12 but I think you may be > exaggerating. OK, granted, "dozens" was an exaggeration :) But you can get 12 if you count all the keyboard modifiers in selector :) > Now, of all of the selection methods that Inkscape > provides, what would you say is the simplest, most obvious method for > selecting a single object. I argue that it is the single click of the > selector tool. Yes, but you forget another proposed method that you can use if you don't like transparent rects: make them blue, but place them in a semitransparent layer. Then when you need to export it, just set its transparency to 0. Minimum clicks to get what you need, and you can still click to select the slices. What's wrong with this? Difficult to set up? Just provide a template with that semitransparent "slices" layer already present. Difficult to discover? Write and popularize a tutorial. Cannot batch export the slices? Yes you can, in SVN this is added right to the Export dialog (the "export selected objects separately" checkbox). I can even easily add another checkbox there: export all within the object's bbox but not the object itself - and then you will not need to make the boxes transparent, because they will be hidden in the export anyway. Or, we can eventually support per-layer Outline view (this was already requested by other people for other purposes), which, if enabled for the export layer, will solve all of your problems at once: rects will be always visible and clickable even if transparent. And we can even enable per-layer outline color to differentiate them visually. Need more intuitive manipulation of the slices? Excellent suggestion, just implement the rect-specific commands for "subdivide horizontally", "subdivide vertically", and "rectangle union" on the Rect toolbar, and fix the KnotHolder so it can edit more than one selected rect (e.g. by dragging the touching sides of two adjacent rects) - and editing the slices will be a breeze, not to mention all the other benefits you get from these improvements. See? Every convenience you can think of is easily possible with the simple approach, just by extending the capabilities of existing tools. And the big advantage is that these extensions may be useful in various other situations too. Whereas, if you create a specialized tool just for slicing, it will be useless for anything but slicing. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

4 8

Calligraphy width - can you guess what I'm going to say? :)
by microUgly 24 Aug '07

24 Aug '07

I did a search for this because I thought it would have been brought up many times - but I couldn't find anything. I don't understand the benefit of width not being effected by zoom with the calligraphy tool. The Inkscape.org tutorial justifies it by saying: "This makes sense, because the natural "unit of measure" in calligraphy is the range of your hand's movement, and it is therefore convenient to have the width of your pen nib in constant ratio to the size of your "drawing board"" I could understand this if the calligraphy tool was only ever used for calligraphy writing. But I would think it's as likely, if not more likely, to be used as a drawing tool. And as a drawing tool this feature is very frustrating. To ensure consistent thickness lines when inking you have to manually calculate the width everytime you change zoom. Otherwise you end up with a mixture of very thick and very thin lines. Perhaps to not upset traditional calligraphy artists, is it possible we could get a checkbox to toggle how the width is effected when zooming? Even if the feature simply adjusted the value in width field as you zoomed in and out. -- View this message in context: http://www.nabble.com/Calligraphy-width---can-you-guess-what-I%27m-going-to… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

3 3

Re: [Inkscape-devel] Time to start thinking about a release?
by joel＠...1709... 24 Aug '07

24 Aug '07

> PDF does not support blur, let alone PS. The only workaround you have is to convert blur to bitmap before exporting. I think inkscape needs a pre-flight dialog then which gives you errors, warnings and messages concerning your export, otherwise the inexperianced user will struggle to understand why blur failed to export, much less how they can get around the issue. CorelDRAW has a rather nice example of a pre-flight dialog for printing. ---------------------------------------- From: "bulia byak" <buliabyak@...400...> Sent: 23 August 2007 23:51 To: "Adib Taraben" <taraben.a@...1512...> Subject: Re: [Inkscape-devel] Time to start thinking about a release? On 8/23/07, Adib Taraben wrote: > also we need to mark the things that _have to_ go into the release. > I do a lot of technical drawings and for me it is absolutely necessary > to include the blur into the pdf and ps export formats. PDF does not support blur, let alone PS. The only workaround you have is to convert blur to bitmap before exporting. We may eventually add an option to do this automatically but I don't think it's particularly high priority because the workaround is easy (just press Alt+B). -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 1