- Inkscape Devel - Inkscape Mailman

warning in LPE
by Jon A. Cruz 12 Jun '08

12 Jun '08

Does anyone have insight on this: live_effects/lpe-envelope.cpp: In member function 'virtual Geom::Piecewise<Geom::D2<Geom::SBasis> > Inkscape::LivePathEffect::LPEEnvelope::doEffect_pwd2(const Geom::Piecewise<Geom::D2<Geom::SBasis> >&)': live_effects/lpe-envelope.cpp:218: warning: control reaches end of non-void function I've been thinking I can address the structural and return issues, but I'd need to know what *should* be returned in the fallback case. Any ideas?

2 1

SPDocument initialization
by Jon A. Cruz 12 Jun '08

12 Jun '08

Hi guys, In cleaning up the autosave patch, I came across an uninitialized member variable in SPDocument (the flag for modified since last save). I cleaned up the initialization and added all the member variables I could find. However, it's possible this might unmask some other bugs or workarounds. Just wanted to give a heads-up on it.

1 0

Re: [Inkscape-devel] Proposal: stick to node or stick to segment
by Valerie 12 Jun '08

12 Jun '08

Hey, guys, Help! I'm trying to think up the interface for sticking, and the easiest would be to add a few buttons to Node edit mode to specify "stick:" you select two nodes and click the icon. Drawing a line from one stick point to another is fine too. I think there could be at least two types: stick node and stick object. Stick object is when you want the whole object to follow the other one around. Stick node only - with ability to stick handlers as well - is more used for linked fills and such. The whole object isn't moved, instead gets deformed by pulling the node in directions. There is one big problem though: does Anybody have any ideas how to make the nodes of two non-combined objects visible simultaneously for sticking? Proposals? The problem with combination, even if temporary, is that the combined objects lose their properties: a big no-no. Possibilities include: 1. Allow node-editing mode to show the nodes of multiple selected objects 2. Instead of targeting any available node, the user must first specify stick points or segments on individual objects. In a "stick" mode, all available stick points on all objects show up. This is also "cleaner" than when All the nodes show up. 3. Or same as above, except the available stick points only appear on mouse-over: you start drawing a line from the starter stick point to the destination stick point, upon drawing on the object the stick points of that object become visible. 4. A bit like above, but without needing to specify a custom stick-point: when drawing the connector, when you approach an object the nodes on said object become visible. So? Which one is acceptable? Or does anybody have completely different proposals in mind?

1 0

GSoC tech drawing project -- status report / outlook
by Maximilian Albert 12 Jun '08

12 Jun '08

Hi all, now that my recent changes are committed to trunk (which was a bit delayed because the LPE stacking forced me to rewrite some things), here is a little update on the status of my GSoC project. Caution, it's slightly lengthy! But even if you're not interested in most of it, I'd appreciate any comments on the questions/ideas mentioned (you may want to skip the first few paragraphs in this case). I started by writing three very simple LPEs for various geometric constructions. These are: circle-with-cadius, perpendicular-bisector and tangent-to-curve (in the following abbreviated CwR, PB and TtC). They were mainly chosen for the different kinds of user interaction they require so that I can use them as an indicator of what is still missing. Although LPE parameters can already be adapted using the LPE dialog, it is clear that for a user friendly interface we need knotholder handles for LPE items. I first added these in a quick-and-dirty way but it quickly became apparent that for a "correct" and more powerful solution the knotholder-related classes needed to be converted to C++. So this is what I did next (see my recent email for details). This also made it possible to add on-canvas handles for LPEs in a semi-automatic fashion similar to how parameters are added. I will put a description of how this works on the wiki soon. It works pretty well, but perhaps the mechanism can still be improved or made more elegant. Please let me know if you have any comments. Note that there already existed a PointParam parameter class for LPEs but the new handles do *not* duplicate their functionality since the latter can be used to alter _any_ kind of parameter, analogously to how handles for regular SPItems are used (e.g., with TtC there are handles to adjust the length of the tangent which is controlled by *scalar* parameters, not PointParams). Unfortunately, PointParams are currently broken due to the C++ification process but once I fix this, handles will also be added automatically for them. This will render the inconvenient "edit on canvas" button obsolete and make them much more comfortable to use (I'm looking forward to seeing the new lattice deformation in action then :)). One of the main remaining issues with handles is that we must eventually be able to simultaneously allow KnotHolders and NodePaths for LPE items. E.g., for PB and TtC it is essential to be able to edit the original path while at the same time adjusting the parameters on canvas. Currently this is not possible because an item can only have either a knotholder or a nodepath but not both. My first decent attempts to simply enable both for certain items consistently resulted in crashes. Since I'm not very familiar with the shape-editor code I'd appreciate any hints or even guidelines how this can be done. For instance, which parts of the code rely on the assumption that only one of knotholder/nodepath is active? Bulia, you said that you did some decent work in this direction. Do you have special advice how to proceed? Another simple recent change was to allow LPEs to either suppress the red helper path (which indicates the original path) or to display it permanently while the item is selected. E.g., for spiro splines it is suppressed while for PB and TtC it makes sense to know how the perpendicular bisector or the tangent are located with respect to the original curve so the helper path is displayed. BTW, I noticed a bug in my code - sometimes the helper curve does not disappear when the item is deselected. I will investigate this. What's the correct way to make the item disappear, anyway? The function remove_temporary_canvasitem() doesn't seem to work. IMO, the next big step to improve user interaction is to get rid of the "first draw a shape, then apply LPE" scheme. Most, if not all, of the planned LPEs only require very simple paths to which the LPE is applied. For example, CwR and PB only need a straight line, for a future angular bisector and circle-through-3-points we would need a path consisting of just three nodes, etc. My idea is this: Let's have a special mode in the pen and/or pencil tool which waits for a given number (say N) mouse clicks, then converts these into a polyline consiting of N nodes and (N-1) straight line segments (no curved paths are possible) and finally automatically applies a specified LPE to this polyline. This would be very similar to how the Spiro spline mode of the pen/pencil tool works now, only that arbitrary LPEs could be applied and that (optionally?) only polylines are allowed. As soon as we have a toolbar for the new geometric LPEs in place, the new "LPE mode" in the pen tool would be activated by pressing the corresponding button. Does this make sense? Any suggestions for details of the workflow? After this is done, I'm going to write the remaining planned LPEs (which I haven't done yet because I considered it favorable to have the on-canvas machinery in place in order to avoid major rewritings). This should be very quick (I already have drafts for a couple of them on my hard drive). Then I'd like to start tackling automatic toolbar integration of LPE parameters. I don't have a clear idea yet of what is needed for this so if you have any suggestions, I'd love to hear them. Johan, can you comment on this? Can I simply integrate RegisteredWidgets into existing toolbars or what kind of groundwork is needed to achieve this? Many thanks for reading thus far and for any comments you may have! Max

2 1

Is there a how to for creating integrated printer software for inkscape?
by stuart 12 Jun '08

12 Jun '08

Hi... Is there a how to for creating integrated printer software for inkscape? My assumptions are that inkscape can only print to raster and / or postscript type printers. And postscript is used when plotting or cutting is how the printer works. Beyond that, are there any provisions for "plugin" software printer drivers? For instance, what happens when you want to print to an HP plotter that understands HPGL? ...thanks

2 1

[Fwd: Re: r18847 introduces crash because of ... NULL]
by MenTaLguY 11 Jun '08

11 Jun '08

-------- Forwarded Message -------- From: MenTaLguY <mental@...3...> To: Peter Moulder <Peter.Moulder@...38...> Subject: Re: r18847 introduces crash because of ... NULL Date: Wed, 11 Jun 2008 13:15:31 -0400 On Wed, 2008-06-11 at 23:43 +1000, Peter Moulder wrote: > (If you'll excuse me pointing out the obvious, it's probably not a good > idea to deliberately introduce assertion failures into svn trunk.) I did address the failures I knew of beforehand (modulo the duplicate(NULL) bits I had once FIXMEd but since forgotten about) and those which I had discovered through casual testing (I *did* try various permutations of saving, just not Save As Plain...). However, there's ultimately no way around it -- if you add new assertions for things that can't be statically proven (either in absolute terms, or in practical terms due to e.g. the size of the codebase), there realistically *will* be some failures and you *have* to discover them empirically after introducing the assertions. Absent a complete enough test suite, the only way to discover lingering failures in a reasonable amount of time is to release the change to a branch where there is a large pool of testers. Incidentally, while the prohibition on NULL documents is new, the changes also caught at least one existing violation of an existing precondition: https://bugs.launchpad.net/inkscape/+bug/239092 (I should have tested extensions though. That I've no excuse for.) -mental

1 0

buildtool on linux
by Bob Jamison 11 Jun '08

11 Jun '08

Hi all, I've been working on buildtool some more, to try to make it more generic and portable. There is a lot of work to be done, but as of yesterday, it can now build Inkscape on Linux. build-lx.xml is the build file. Buildtool has a built-in package-config reader, which makes things a LOT easier. I uploaded a build here: http://inkscape.modevia.com/btool/inkscape-0806101650-btool.7z It uses binreloc, so it can be run from anywhere on the disk. It does not include all of the special dependencies of Inkscape. We will work on that later. It will likely just copy the not-so-common .so's to the $INKSCAPE/lib dir, exactly the same as the win32 "dist" target copies dlls. bob

1 0

Win32 Gtk locale
by Bob Jamison 11 Jun '08

11 Jun '08

Hi, all. On the channel, <gal_bolle> pointed out that although Inkscape's translations strings are working correctly, Gtk's are not. Looking around, I noticed that in the win32 package, we are copying devlibs/lib/locale and not devlibs/share/locale to the package. I believe the first is for translating the tools, and the second is for translating the runtime. I made the adjustment to build.xml and uploaded a build here: http://inkscape.modevia.com/win32/Inkscape0806111651.7z Please try this out and see if the Gtk stock button names are translated. Since the file dialogs are now native, they are not a good place to look. Maybe try the "Close without saving" dialog. bob

1 0

XML cleanups
by MenTaLguY 11 Jun '08

11 Jun '08

A few months back, I'd been threatening to make some significant changes to the XML code during this release cycle, and one of them just bit us. I was hoping it would go smoother than it apparently has. The issue is this: a lot of cleanup and implementation-hiding in the XML code is blocked by the fact that many parts of the code currently create XML nodes which are not initially attached to any document. This is compounded by the fact that a great deal of code doesn't know what the relevant document is, since it was long assumed that it could be set up with a document later. So, a lot of code has to be rewritten to plumb the relevent XML document in. I added an assertion to trap any code that neglects to create nodes with a document, and am proceeding from there to rework the affected code. That was the reason for the recent "Save As" crash. I wish there were a "nicer" way to do this, but after six years I've come to the conclusion that the drastic approach is the only way to get this done. -mental

1 1

Re: [Inkscape-devel] Proposal: stick to node or stick to segment
by Valerie 11 Jun '08

11 Jun '08

By the way, while thinking about stickies, I think I've finally thought of a possible animation interface for Inkscape! :D (though really, I'm in no hurry to see it implemented, not before the Inkscape interface is more dynamic) A long, Long time ago, I tried Flash in Summer Camp, and I'll just say that I didn't like it (though I don't know how it works now). The approach I'm suggesting is that you add actions to a given object. You basically call up a (big) panel and add actions much as you would a live path effect. When you use the "edit animation" mode, you can turn on the animation "skeleton", which basically makes icons appear next to the object to show if the types of transformations applied to it that frame. From there, the most common parameters can be edited in the toolbar by clicking the action icon of choice: "From" field, "To" field, anchor points, speeds etc. Types of actions: Move, Rotate, Resize, Opacity, Color, Blur, Stick, Free Transform. People can create their own plug-in effects. The effects can collapsed so that you can easily see the list of effects on that object. The panel looks a bit like this (> is collapsed, V is open): Action: [+] Add action ----------------------------------- > "Jump:" Move | Start: [ ] | End: [] V "Swing:" Rotate Name: Swing Start: [] Offset: [] End: [] Offset: [] Add trigger: [+] Anchor point: [] Speed: [] Repeat type: [] [] Offset (clicking opens up X and Y values) [] Jitter (clicking opens up X and Y values) ----------------------------------- Major elements: 1. Start and end: Start has 2 possible types: - Date - Trigger - "End" also has duration (which basically is a "+ [value]" figure) 2. Triggers. The use of triggers is what makes time management easy in this case. You can define Absolute triggers with specific times, or you can create a new one within the object and based upon an action. Basically, in "Hang", clicking on Add Trigger will pop up a panel asking you to: - name the trigger (example: Man.StopSwing) - the condition: either as a proportion of action completed (0%, 50%, 80%, 100%), or a specific parameter (ex.: angle reached 90 degrees) >From then on, this trigger can be called upon in another object and action. This way, you can specify that as soon as one object is done with an action, the other starts another action. "Offset" can be used too (ex: an object starts moving 20 seconds before another reached the end of a movement path). I prefer this trigger-centric approach because it makes time management that much easier across multiple objects. Back when I tried that older version of flash, I had to go looking which frames were doing what. :\ Here you can just change the duration of one action, and the rest automatically falls through. Note: triggers can also be events such as MouseOver, Click, etc. 3. Anchor point. You define anchor points on an object (eventually naming them something other than "Node9011"), and this will be the point of attach of the action. Different actions can have different anchor points. "Move" also asks you to specify a path. "Stick" asks you to define a destination point on a destination object: you're sticking one point to another. 4. Parameters: for rotation, you define the rotation speed and/or amplitude, for resize you define the starting and ending sizes. If possible, jitter and offset value options can be added. Of some interest, the main parameter (rotation, resize etc) could be a custom curve. A straight curve from one value to another is a linear resize for example. But you can also make waves of decreasing amplitude, which in the case of resize/Height only, for example, makes the object look bouncy after say... falling to the ground. 5. Free transform works a bit differently than the rest. My proposed interface is this: this action is applied onto an object with -multiple- layers that count as separate frames (eventually with sub-layers, but it's the first-level layers that are counted as Frames). So you don't do the transformations within the animation file, but separately, but this should be fine as it makes your CPU life easier. The user basically creates an image, makes several copies on separate layers, makes changes to each, then imports it into the animation file. When applying free transform (or whatever it can be called), the user determines how the image morphs from one frame to another (usually the underlying skeleton moves from one position to another, the user can specify time for each frame as well as relations to trigger events) An "update" option is quite possible, so you make adjustments to the external files and see them updated directly. En error console pops up if the result is too different. :P 6. Stickies. Stickies are a very important part of this process, because it means a whole lot less of actions! Example: A man is carrying a box, puts it on a truck, and the truck drives away. Breakdown: - Add Stick action to box, so you don't have to redefine the walking. - Add Move action to man walking. - The Stick action stops when the man arrives at the end of his movement path. - Add Move action from box to truck. - Add stick action from box to truck. - Add move action to truck. The box just follows it because of the stick. This greatly simplifies things because it avoids having to duplicate paths and values (which can be a whole lot after a while) Other example: - a Linux penguin walks to a seesaw. Linux penguin jumps onto the seesaw (move action). - the seesaw rotates. Linux penguin also goes down because as we also define a "stick" action to that end of the seesaw. - when that side of the seesaw reaches ground (angle trigger), the object on the other side (a Microsoft logo), that used to be "stuck" on the object until then, gets unstuck and does an arc trajectory into a nearby trash bin. :) In the meantime you have the grass defined to swing back and forth with no conditions at all, though the penguin stepping on it may "trigger" it to flatten. 7. There should be an automatic summary timeline for each object to show trigger events and actions applied. The timeline keeps it simple, triggers only show their name upon mouse-over (though they may be different colours depending on whether they result from an action underway in this object, in another object, or from clicking something), and tiny action logos appear in the timeline (mouse-over shows the name, type, and highlighted line and triggers to show how long it lasts) Once the user is happy, he orders Inkscape to calculate the entire output, makes any adjustments necessary before re-calculating, and exports. That's it! :D I plan to make visual mock-ups, but would there be any problems with this approach? Some people are probably familiar with the Flash way of doing things (whatever it is they are doing now), but I do prefer simply saying "Let's add a simultaneous move and rotation on this or that object. It lasts This long and stops when another object reaches a certain state." Yay? Nay? Anyway, users can write up all sorts of fancy effects on their own, like the object getting cut up in all sorts of ways or leaving a temporary ghost trail while resizing. People could download those as extra effects plug-ins.

1 0