- Inkscape Devel - Inkscape Mailman

rev 15630 linking error
by bulia byak 02 Aug '07

02 Aug '07

Any ideas? It compiled fine a couple days ago... ui/dialog/libuidialog.a(filedialog.o): In function `Inkscape::UI::Dialog::FileOpenDialog::create(Gtk::Window&, Glib::ustring const&, Inkscape::UI::Dialog::FileDialogType, Glib::ustring const&)':ui/dialog/filedialog.cpp:40: undefined reference to `Inkscape::UI::Dialog::FileOpenDialogImplGtk::FileOpenDialogImplGtk(Gtk::Window&, Glib::ustring const&, Inkscape::UI::Dialog::FileDialogType, Glib::ustring const&)' ui/dialog/libuidialog.a(filedialog.o): In function `Inkscape::UI::Dialog::FileSaveDialog::create(Gtk::Window&, Glib::ustring const&, Inkscape::UI::Dialog::FileDialogType, Glib::ustring const&, Glib::ustring const&)':ui/dialog/filedialog.cpp:57: undefined reference to `Inkscape::UI::Dialog::FileSaveDialogImplGtk::FileSaveDialogImplGtk(Gtk::Window&, Glib::ustring const&, Inkscape::UI::Dialog::FileDialogType, Glib::ustring const&, Glib::ustring const&)' ui/dialog/libuidialog.a(filedialog.o): In function `Inkscape::UI::Dialog::FileExportDialog::create(Gtk::Window&, Glib::ustring const&, Inkscape::UI::Dialog::FileDialogType, Glib::ustring const&, Glib::ustring const&)':ui/dialog/filedialog.cpp:74: undefined reference to `Inkscape::UI::Dialog::FileExportDialogImpl::FileExportDialogImpl(Gtk::Window&, Glib::ustring const&, Inkscape::UI::Dialog::FileDialogType, Glib::ustring const&, Glib::ustring const&)' collect2: ld returned 1 exit status make[2]: *** [inkscape] Error 1 -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

referencing elements within an external SVG
by Felipe Sanches 02 Aug '07

02 Aug '07

SVG 1.1 spec says that: http://www.w3.org/TR/SVG11/struct.html#URIReference 5.3 References and the 'defs' element 5.3.1 Overview: *the 'use' <http://www.w3.org/TR/SVG11/struct.html#UseElement> element can reference any local or non-local resource http://www.w3.org/TR/SVG11/struct.html#ImageElement Section 5.7 The 'image' element: *Unlike 'use' <http://www.w3.org/TR/SVG11/struct.html#UseElement>, the 'image' element cannot reference elements within an SVG file. So... I imagine that the 'use' element should allow me to reference elements within an external SVG (i.e. a non-local resource) but I try to do that and I get nothing! Any clue on that? **************** This is my use.svg file: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg xmlns:svg="http://www.w3.org/2000/svg"> <use xlink:href="file:///home/aluno/Desktop/circle.svg" /> </svg> **************** This is my circle.svg file: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg xmlns="http://www.w3.org/2000/svg"> <circle id="mycircle" cx="300" cy="225" r="150" fill="red"/> </svg>

1 0

lxml on OS X: test and compilers needed
by jiho 02 Aug '07

02 Aug '07

Hello, I just compiled lxml on OS X 10.4 Intel and created a new Python packages bundle there: http://inkscape.modevia.com/macosx-snap/?C=M;O=D I would need: - someone with a Mac Intel and an svn version of Inkscape (or willing to download one from the same address) to test if lxml works precompiled as pyxml did - someone with a PPC Mac (10.3 or 10.4) to compile lxml there and send it to me for distribution (compiling it is as simple as download, extract, ./setup.py build, ./ setup.py install) Download link: http://codespeak.net/lxml/index.html#download Thanks in advance. JiHO --- http://jo.irisson.free.fr/

1 0

New drawing tool idea
by Joey Marshall 02 Aug '07

02 Aug '07

I posted this to the inkscape-users list and was suggested to post it here. So here it is, please tell me what you guys think: -------------------- Hello, For the past month I have been thinking over an idea I would really like to see made in an opensource vector program. Inkscape is my favorite so I'm posting this here. I think this would be a really great tool but would also take quit a bit of work (or at least I think it would, feel free to prove me wrong.) What I want: The tool is somewhat of a line tool. Similar to the freehand tool in that it creates a vector line, but enhanced. The differences would rest on the that is drawn. Instead of the curves that the freehand tool draws, the line would be composed of joints evenly spaced apart (the spacing would in general be small, but be user customizable). Each joint should have their x,y cords as well as a width property (it may be better to organize that different, but each joint needs to have this property, which would be a variable number set by a stylus used to display the line, I'll get to this in a moment). In addition a joint must be able to reside in multiple lines. The reason being so that two lines can "connect" to each other. Each line would simple be a stroke; the button clicks, the mouse moves, the button lets up - a line. So say you draw a line in the shape of a big C. Then you want to join the open end and have tails sticking out on ether end. You would start above the C shape on the rightmost side and draw your line down. As you draw you can hold down on CTRL to connect the line to any other you pass over (Or maybe have it so after you draw the line you can press a hotkey and it connects itself to any other lines it intersects with). That's all for the user drawing the lines, now for how it would display it. I'm not totally sure about how to do this (as if I am on any of this) but I was thinking it should draw out to look like a pen or pencil stroke (maybe have the general width be user defined so it could look big and fat to like a brush stroke). This is what I was wanting the width attr in the joint for. Maybe for displaying it create a line (or rather a complex polygon shaped like a line) that moves through all the points with the width (distance between the two edges on the sides of the line) changing with the width attr in the joints. Did any of that make sense? Ok, two more things. Coloring and editing. For editing I want something cool :) What I was thinking was that you can press down on CTRL or right click or something near a line and start drawing. As you go it moves and morphs the line to how you are drawing. It would have to automatically add and remove joints to keep evenly spaced. Is that at all clear? Lastly the coloring. I don't know how this could be made into inkscape easily (not that any of this would be easy) but I would want the ability to be able to fill in enclosures in the lines (also be able to change the color of a line but that wouldn't be difficult.) I could only really think of one way to do this. It would find all the joints of the lines that it needs to fill in and create a polygon from them (the joints). Perhaps have them be the actual joint objects (is this very feasible in C/C++?) so that when a line is moved after it is filled in the fill would update with it. Anyway, that is what I would really like to see in a vector editor like inkscape (I would love to see it in inkscape.) There are probably still several design holes that I overlooked but I think I conveyed what is in my mind. This would take a lot of work but I think it would be a very valuable tool to have. I tired playing around with it myself using cairo and PyGTK but wasn't able to get very far (I need to learn to stay as far away from the DrawingArea and Pixbuf/Pixmap as possible... ether that or get it figured out once and forall). If anyone thinks this would be cool and might want to implement it that would be awesome! At the moment I couldn't really fund anyone to do this and I'm not even sure this is something that would be wanted in inkscape. Please let me know anyone if you're interested or I'm unclear about something or what ever! Thanks for listening! Joey

1 0

ccHost upload from Inkscape.
by ryan lerch 02 Aug '07

02 Aug '07

I am just wondering if we can get an update on how the GSoC upload to Open CLip art library from Inkscape is coming along? I cant wait for this awesome feature... :P cheers, ryanlerch

2 1

Error compiling
by radar.map35＠...8... 01 Aug '07

01 Aug '07

Since few days, i get this error when i try to compile from SVN : In file included from ui/dialog/dialog-manager.cpp:26: ./ui/dialog/filter-effects-dialog.h:19:36: error: gtkmm/cellrendererspin.h: Aucun fichier ou répertoire de ce type make[2]: *** [ui/dialog/dialog-manager.o] Erreur 1 Does anyone get that too ? pygmee

2 1

filter UI (convolve matrix)
by Felipe Sanches 31 Jul '07

31 Jul '07

Here are some considerations about the convolve matrix ui current implementation: (1) I think that the rows and cols parameters dont need a scroll bar since they are integer values selectable within a very small range. The scroll bar is only wasting space there since its even easiear to select the desired value directly typing it or by using the up or dow arrows. (2) I have drawn a spline and have imported a bitmap. I have applied the same filter to both (convolve matrix) when I change the divisor or the bias parameters, the effect on the spline updates automaticaly while I scroll the bar, but on the image I MUST double click on the filter name to have the effect aplied. It is a weird behaviour I think. Do you know why is it happenning? (3) the bias and divisor scroll bars bypass the default value behaviour (which could be desired in some ocasions, mainly because the default value seems to be usually a good choice aesteticaly) Maybe a good soulition woul be to initialize it with the default value, not zero. Also it limits the range of possible values. (4) how do we set the targetX and targetY? Maybe we could have a little black dot indicating it on the matrix And one desired feature for the filters ui in general: (5) it would be nice if we coul drag and drop a filter from the left list into the filter diagram area at the right in order to use it as if it was a filter primitive. In the UI it would show the filter name (it's an abstraction to the user) but behind the scenes it would probably be a copy of the filter structure connected to the rest of the real primitives implementing a "higher level" filter. You understand what I mean? best wishes, Juca

6 7

Re: [Inkscape-devel] [Inkscape-user] Seeking documentation of Python bindings
by Ted Gould 31 Jul '07

31 Jul '07

On Tue, 2007-07-31 at 13:23 -0500, Kent Tenney wrote: > On 7/31/07, Ted Gould <ted@...11...> wrote: > > There are some effects that are defined internally in Inkscape. Those > > are built into the C code directly. I'm a little confused on your > > examples of 'Generate from path' and 'Render' as those are submenus. > > The submenus are also defined in the INX files, dynamically depending on > > which effects are available. > > If I rename share/extensions to share/extensions.hide, and open Inkscape, > those 2 submenus are the only members of 'Effects', each with 1 member; > Generate from path->Inset/Outset halo > Render->Grid Yes, specifically: src/extensions/internal/grid.cpp src/extensions/internal/bluredge.cpp --Ted

1 0

Spam in our sourceforge forums
by Diederik van Lierop 31 Jul '07

31 Jul '07

Hi, There's still a lot of spam being posted into the "installation help" forum. About 5 a day, with currently only one real post in the last month. That's a bit skewed... I guess people are being scared away when they see the first 10 messages of so being spam (I don't come over everyday to clean up the mess). Maybe we could try to block anonymous posts for a few weeks, and then unblock them again. There's a slight chance that the spammer (it's apparently only a single #%$#@) might notice and stop bugging us. This will also shy away real people (as opposed to the spam bots), but it's not being used anyhow at the moment. The "manual" forum already has anonymous posts blocked, but the others haven't. Diederik

1 0

Re: [Inkscape-devel] Change in object snap behavior
by Diederik van Lierop 31 Jul '07

31 Jul '07

> I don't personally see much reason for wanting to snap to a bounding > box. It's only weakly related to the underlying geometry. A (corner) > node, on the other hand, is a visible geometric feature. > > --bb Snapping boundingboxes is useful for objects having a stroke, if you want the strokes touching instead of overlapping. You'll get overlapping strokes when snapping to the paths. But I don't think we need the distinction between bbox corners and bbox sides (as in nodes vs. paths), do we? I'm trying to have as little options as possible because the snapping dialog can easily get too confusing. All the tiny detailed options are there under the hood, but I think only some subset should be provided to the user. For example, in the object snapper we currently only snap boundingbox corners to other bounding boxes, and nodes to other nodes or paths. There's no mixing of those any longer (i.e. no nodes to bboxes), which makes snapping much more intuitive. Does anyone have any objections to this behaviour? I like the idea of only snapping to nodes at sharp corners.We will still need an option to disable snapping to nodes, as someone might want to snap to any point along a path, also to any point close to a sharp node. It would be annoying if it snaps to the node when you get close to it, so this doesn't help in reducing the snapping dialog clutter. But I think I might filter out the smooth nodes anyway, merely for improving the snapping responsiveness. Diederik

1 0