- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Change in object snap behavior
by Bill Baxter 31 Jul '07

31 Jul '07

On 7/31/07, postmaster@...1785... <postmaster@...1785...> wrote: > We used to have an option to snap only to nodes and/or paths, which > currently is > not in the snapping preferences dialog in SVN (I'm still working on this > dialog). I've been shuffling the checkboxes, but also the snapmanager code. I > will put the snap to paths and/or nodes option back in for snapping to > objects, That would be great. > but I wonder if we need something similar for the boundingboxes also: snap to > the sides and/or corners? Does anyone think that would be usefull? 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

1 0

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

31 Jul '07

Unfortunately I think the documentation you seek is largely unavailable. :( This isn't on purpose, it just hasn't been done yet. Let me see if I can answer some of the questions here, but I'm going to CC the Devel list which can probably help also. On Fri, 2007-07-27 at 08:54 -0500, Kent Tenney wrote: > I haven't yet found; > > - an explanation of the xml in the .inx file There is some information in the Wiki on this. I've started an XML Scheme (attached) but it is not complete and I'm not sure it even validates (my first XML Schema). If you have specific questions I'd be happy to answer them. > - the api available to Python scripts The scripts themselves aren't locked into any API. The data comes through command line parameters and STDIN/STDOUT to the script. There is a convenience library in the extensions directory which provides come common functionality. If you have questions on those functions, please ask on -devel. > - a discussion of how Inkscape processes the share/extensions dir I'm not sure what you're looking for here. Sorry. Could you please reask this a different way? --Ted

1 0

Change in object snap behavior
by Bill Baxter 30 Jul '07

30 Jul '07

I noticed that in SVN the object/node snap behavior is different from that in 0.45. In 0.45 if I had a polyline then I would only get snapping to the nodes, not to other parts of the line. In 0.46 it is equally happy to snap to any part of the line, making it difficult to snap to the corner vertex. I can understand there's no particular reason to preferentially snap to a smooth node on a path, but for corner nodes I think you should get snapping behavior that somehow takes precedent over the line-snapping behavior. --bb

2 1

coloured markers
by Felipe Sanches 30 Jul '07

30 Jul '07

one friend asked me if it is possible to have start, middle and end markers coloured. The UI aparently only allows black markers. Then I looked at the svg xml and noticed that markers declarations are quite flexible. Is it only my impression, or we can indeed use as markers absolutly anything that is valid svg ? I would propose that a color-selection button is placed to the right of each of the marker combo-boxes. (maybe even 2: one for marker-fill and one for marker-stroke) Juca

3 2

Re: [Inkscape-devel] Gtkmmifying the desktop window object
by joel＠...1709... 30 Jul '07

30 Jul '07

Well, I still may not have made your work obselete. After all, all I've done is replace the GtkWindow* of SPDesktop::window with Gtk::Window*. It was a relatively simple fix to go through all the dependancies and change all those. For proper Gtkmmification, SPDesktop should probably be turned from a struct to a class, retagged "Inkscape::UI::Desktop" (or something), and derrived from Gtk::Window. This would be a proper job of it. My change is a sort of most minimal gtkmmification. ---------------------------------------- From: MenTaLguY <mental@...3...> Sent: 30 July 2007 10:08 To: ralf@...748... Subject: Re: [Inkscape-devel] Gtkmmifying the desktop window object On Mon, 2007-07-30 at 08:22 +0200, Ralf Stephan wrote: > Oh yes, I certainly did nothing of the sort. > As I demonstrated to mental long, long ago, the only what was > missing in my implementation was correct zooming. If I'd been aware that Joel was working on gtkmmification before (I've not been following development very closely for the past few months), I would've suggested he finish the work you nearly completed. As it is, I'm just relieved the task is finally done! I don't mean to denigrate the time you put into it yourself. -mental ------------------------------------------------------------------------- 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

1 0

new ways to scroll and zoom
by bulia byak 30 Jul '07

30 Jul '07

I know adding prefs settings for individual shortcuts is evil, but since we don't yet have a UI for editing keymaps, and these features were requested A LOT, I think in this case it's justified: * You can now enable Space+mouse drag to pan canvas, as it does in Adobe Illustrator. This mode is enabled by the "Left mouse button pans when Space is pressed" checkbox in the Scrolling tab of the Inksape Preferences dialog. By default it is off and pressing the spacebar key switches you to Selector and back, as it always did in Inkscape. * By default, rotating the mouse wheel scrolls the canvas vertically and Ctrl+wheel zooms in and out. Now, if you turn on the "Mouse wheel zooms by default" checkbox in the Scrolling tab of the Inksape Preferences dialog, this behavior is reversed: mouse wheel zooms without Ctrl and scrolls with Ctrl. This new mode should be familiar for users of AutoCAD and CorelDraw. * In the Zoom tool, right mouse button always zooms out instead of calling the context menu (which is rather useless in this tool anyway). -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

Gtkmmifying the desktop window object
by joel＠...1709... 30 Jul '07

30 Jul '07

Hi All, As we discussed a few weeks ago, I've now gtkmmified the desktop window object. I've also set this object to be parent windows of the file dialogs, which prevents them falling underneath the application window in Windows as per bug #1431528. I've spent quite a long time testing this modification, both in Ubuntu, XP and in Vista, and everything seems ok. Nonetheless, this sort of modification is could create bugs, especially with all the pointer casting which goes on in Inkscape. So let me know if there are any problems. In working on this I may have stumbled across another bug which has crept in from somehwhere: In Windows, try saving a file through the file dialog. At this point the application crashes. You can see this happen if you download Inkscape0707240355.7z (which comes from a few days ago before I comitted this latest mod, so it's not my fault). I used message boxes to trace the problem to line 644 of file.cpp: "delete saveDialog;". However when I compiled this morning, and stepped through with a debugger I could find no problem - so it remains an enigma for now. Best Regards Joel ----- Original Message ----- From: "Bryce Harrington" <bryce@...961...> To: "MenTaLguY" <mental@...3...> Cc: <joel@...1709...>; <inkscape-devel(a)lists.sourceforge.net> Sent: Saturday, July 07, 2007 1:01 AM Subject: Re: [Inkscape-devel] GTK+ and GTKMM problems > On Fri, Jul 06, 2007 at 03:20:42PM -0700, MenTaLguY wrote: >> On Fri, 6 Jul 2007 15:09:04 -0700, "joel@...1709..." >> <joel@...1709...> wrote: >> > What I really want here is "temporary wrapper" just to satisfy >> > FileChooserDialog. There seems to be rather a lack of documentation >> > about >> > all this - or maybe I don't know where to look. >> >> Glib::wrap wasn't intended to be used that way. >> >> > Am I right in thinking that while all inkscape dialogs use Gtkmm, the >> > main >> > window is based on plain old GTK+ ? If not, is there a way I can get a >> > reference to it's underlying Gtk::Window rather than a crumby >> > GtkWindow*? >> >> I think the best thing to do would be to rewrite the desktop window code >> to use >> a Gtk::Window rather than a GtkWindow as the top-level window. It's a >> small >> step towards the complete Gtkmmification we have been wanting anyway. > > I took a cut at this back when we first started doing the Gtkmm work > intently. It's in the experimental SVN module at bryce/inkscape_gtkmm/. > We ended up deciding to focus on dialogs rather than the application, so > this never really got to a finished point, but it still might be useful > for reference or as a starting point. > > Bryce > >

4 4

Win32 build error w/ pdf-input
by Bill Baxter 30 Jul '07

30 Jul '07

I'm getting a build error on a fresh update from SVN. The errors start off with: Make error line 179: problem compiling: src/extension/internal/pdfinput/pdf- input.cpp:19:27: error: goo/GooString.h: No such file or directory And snowball from there. Since it's an extension I presume I could just exclude it from the build and be fine, but I'm not sure how to do that with the btool.exe thing. Thanks, --bb

2 2

Lighting Effects in Inkscape
by Jean-René Reinhard 28 Jul '07

28 Jul '07

Hi, It's been a long time since I started using Inkscape. During the last two weeks, I got frustrated that lighting effects weren't implemented in Inkscape. I took advantage of Niko Kiirala great filter framework to write a first simple implementation of these lighting effects. Almost everything is implemented now. (kernelUnitsLength support is still missing but I plan to get it done soon). I write this email to the list to signal a discreprancy I noticed while implementing feSpecularLighting. In fact the svg feSpecularLighting specification, and test examples, do not follow Phong lighting model. In the SVG specs, the specular lighting is computed by taking ks * N.H^speExp In every Phong lighting model I found by googling it is computed as ks * R.E^speExp where ks is the specular constant speExp is the specular exponent N is the surface normal vector L is the light vector, unit vector from the surface point to the light E is the eye vector, unit vector from the surface to the viewer R is the reflected light vector, unit vector from the surface point indicating the reflection direction. H is the normalized vector colinear to L+E/2 writing things down we have N.H = cos (alpha) for some alpha and R.E = cos(2*alpha). The formula using R.E seems much more natural since the viewer sees reflection if R is "close" to E, ie R.E is close to 1. For the time being the N.H is implemented in Inkscape (standard compliance above all). However, can anybody explain the formula using N.H? Does anybody know why svg specularLighting uses N.H instead of R.E? Cheers, Jean-Rene

2 1

Bug : [ 1653629 ] 0.45 from source in ubuntu
by Jean-René Reinhard 26 Jul '07

26 Jul '07

Hi, after building the latest inkscape svn version, the exec I obtained kept crashing. After some tests I solved the problem. Inkscape wasn't able to find the key binding file. I just looked into the bugtracker. This bug was already reported and the bug report was closed. ([ 1653629 ] 0.45 from source in ubuntu). http://sourceforge.net/tracker/index.php?func=detail&aid=1653629&group_id=9… Shouldn't inkscape die in a nicer way than a segfault, with an explicit warning, if the key file cannot be found? Jean-René

2 2