- Inkscape Devel - Inkscape Mailman

node editing crashes
by Robert Crosbie 02 Jan '04

02 Jan '04

After Bulia's request for bugs, I figured I'd submit this problem I've been seeing lately in the current CVS: When editing paths with both the GUI and the XML editor, inkscape will crash. I always use the XML editor and node editor to position points in my paths to make sure I get them exactly where I want them. I find I can only make a few edits and inkscape will crash. Sometimes one switch between editor and GUI and inkscape will segfault*, other times it will take 10 or more. Having multiple paths may produce this problem faster (not sure). Sometimes inkscape won't crash, but will reach a state where nothing can be selected anymore and messages such as this will be produced: ** (inkscape:10227): CRITICAL **: file selection.cpp: line 523 (SPItem* sp_selec tion_item(SPSelection*)): assertion `SP_IS_SELECTION (selection)' failed ** (inkscape:10227): CRITICAL **: file selection.cpp: line 483 (void sp_selectio n_empty(SPSelection*)): assertion `SP_IS_SELECTION (selection)' failed ** (inkscape:10227): CRITICAL **: file selection.cpp: line 354 (void sp_selectio n_set_item(SPSelection*, SPItem*)): assertion `SP_IS_SELECTION (selection)' fail ed (inkscape:10227): GLib-GObject-WARNING **: instance of invalid non-instantiatabl e type `<invalid>' (inkscape:10227): GLib-GObject-CRITICAL **: file gsignal.c: line 2300 (g_signal_ handlers_disconnect_matched): assertion `G_TYPE_CHECK_INSTANCE (instance)' faile d (inkscape:10227): GLib-GObject-WARNING **: invalid uninstantiatable type `<inval id>' in cast to `GObject' I haven't submitted it to the bug tracker simply because I don't have a clear way of reproducing it. * I have disabled the SIGSEGV, SIGFPE and SIGILL handlers in my version: // segv_handler = signal (SIGSEGV, inkscape_segv_handler); // signal (SIGFPE, inkscape_segv_handler); // signal (SIGILL, inkscape_segv_handler); Cheers, Rob. http://members.rogers.com/rcrosbie _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

1 0

Re: [Inkscape-devel] RE: Win32 Preferences
by bulia byak 02 Jan '04

02 Jan '04

>I must say that Inkscape just gets better and better to use. Maybe its >familiarity. I'm just sorry that I am not a developer. As a user though I >can comment on use and nag people ;-). We definitely need more and more testing and complaining users, so please spread the word :) The current 66 bugs in the tracker is perhaps 1/5 of the actual number of severe bugs... _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoi…

2 1

Re: [Inkscape-devel] Ungroup All Command
by bulia byak 02 Jan '04

02 Jan '04

>No, "Ungroup all" is not necessary, Ungroup must simply ungroup _all_ >selected groups (now it only works if one group is selected). This way >you'll be able to ungroup any nested group(s) down to atoms by pressing >ctrl-u sequentially. This is now done. Please test. _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoi…

1 0

Re: [Inkscape-devel] ctrl-tab
by bulia byak 02 Jan '04

02 Jan '04

>It allows you to jump to the next control when inside a text entry field >(instead of inserting a tab). Not sure if that's all but I think so. >That's a pretty important accessibility feature, so we'd have to somehow >make sure that it wouldn't switch documents when the focus is on a >control that can't be left with regular tab. Which should be mainly the >text tool (while inserting text) and some dialogs. I just tested - Ctrl-Tab works in dialogs as before, it cycles through any widgets, not only text fields (just like Tab). As for on-canvas text, it did not have a ctrl-tab keybinding before and I don't think it needs to have it now; when on canvas, ctrl-tab should always switch documents for consistency. We do need, however, some key combination in the text tool to jump from one text object to the next and back, but it must not be Tab or Ctrl-Tab. Any suggections? _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 2

ctrl-tab
by bulia byak 02 Jan '04

02 Jan '04

Now [shift-]ctrl-tab cycles through open document windows, as in most other programs. Unfortunately GTK steals this key combination, so I had to run the verb explicitly in event-context.cpp. This means it is subject to the same problem as all other event-context shortcuts: it only works when mouse cursor is over the canvas: http://inkscape.org/cgi-bin/wiki.pl?EventContextGrab It's very annoying, and I'm now going to try to attack this problem once again. If anyone has any insights, please share. Has anyone tested the new repr listener in node editor? _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

3 2

sigc++ 1.2
by MenTaLguY 02 Jan '04

02 Jan '04

Okay, since the packaging situation for libsigc++ 1.2 seems better than gtkmm, I will reintroduce a dependency on sigc++. It should be available on almost all current Linux distributions, and the older RPM-based distros should be able to find packages on freshrpms.net (JonCruz tells me the RH 9 sigc++ package works on RH 8). OS X is OK too, as fink unstable (and soon stable, also thanks to Jon) also has it. If y'all don't already have it, make sure you get the right version -- 1.2.x, not 1.0.4 or something. Some distributinos seem to have a slightly weird package naming policy with it. Scream now if this will not work for you. -mental

1 0

gradient-vector.cpp
by Jon A.Cruz 02 Jan '04

02 Jan '04

I just removed sp_gradient_vector_dialog_close, since it was defined but never used. Was it just leftover cruft, or is there a reason to put it back?

2 1

all keys work regardless of mouse position
by bulia byak 02 Jan '04

02 Jan '04

OK, I think I fixed that. Now the canvas always gets all keys, including arrows, space, esc etc. (i.e. not only global verb shortcuts) so long as the document window has focus. This closes a sore "known problem" from 0.36 release notes. I'm not sure if my fix is "correct" but it seems to work. Previously, event contexts received events only from the "acetate" item on the canvas (this is an invisible item covering the entire canvas), and this item obviously can only have focus when mouse is over it. We have tried putting event grab on the canvas widget, but this apparently did not affect the acetate which, not being a GTK widget, cannot have a grab. My solution is simply to call sp_desktop_root_handler() from within the sp_desktop_widget_event() handler (which receives all desktop widget events regardless of mouse position) but only for GDK_KEY_PRESS events and only if the desktop's canvas has no current item (because in that case, an item handler must be called instead of root handler, and I don't need to do that anyway because this can only happen when the mouse is over the canvas). Please test the program thoroughly. This change may well have broken something I did not notice. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

fixing NR precision issues
by MenTaLguY 02 Jan '04

02 Jan '04

Okay, really more generally what we need to do is replace e.g. NRRectL and NRRectS with a single type ... maybe NRIRect. That was the general effect of changing NRShort and NRLong to the same width anyway, since the structures don't differ at all except in the precision they use. -mental

2 3

[Fwd: Re: purpose of s/double/Coord/ change in nr-types.h]
by MenTaLguY 01 Jan '04

01 Jan '04

-----Forwarded Message----- From: MenTaLguY <mental@...3...> To: Peter Moulder <Peter.Moulder@...38...> Cc: Nathan Hurst <njh@...5...>, Inkscape ML <inkscape-devel@...142...ge.net> Subject: Re: purpose of s/double/Coord/ change in nr-types.h Date: Thu, 01 Jan 2004 15:47:01 -0500 On Thu, 2004-01-01 at 04:55, Peter Moulder wrote: > I believe that in revision 1.13 of src/libnr/nr-types.h you introduced a > `typedef double Coord' (CVS comment "removed *S variants of NR structs"). > > Can you please document where Coord is to be used, or the purpose of > this change? > > Knowing the purpose of the type, or how the typedef may change in > future, helps programmers to decide when to use Coord and when to use > double. The purpose of NR::Coord and NR::ICoord are to provide "real" and integer types used for storing coordinates in the rendering subsystem (and consequently having sufficient precision for that purpose). (I'll add doxygen comments accordingly) The motivating factor here was eliminating the entire class of bugs caused by switching between various precisions so much, particularly in the case of integer arithmetic. If Coord and ICoord are used consistently for math involving coordinates (and have sufficient precision), we'll have many fewer headaches with precision issues. I erred on the side of using Coord everywhere at first because I think it's less work to revert the few instances where it's not appropriate rather than the other way around. Probably non-libnr code should have little reason to use them (operator*(double, NR::Point) should probably remain with the double, though maybe it should have an NR::Coord variant too). I will let Nathan be the ultimate judge of where it's appropriate and where it's not, since the NR:: stuff is his purview at this point. -mental

1 0