January 2004 - Inkscape Devel

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

Inkscape Status 2003-12-31
by Bryce Harrington 01 Jan '04

01 Jan '04

Project Status Wednesday, December 31, 2003 The past couple weeks have seen work in a variety of areas. Ctrl-click selection within groups, including multiple and nested groups has been implemented. The new inset/outset capability is receiving a lot of testing attention. The Win32 build of Inkscape has also been a focus of development efforts over the past couple weeks, and it's expected that 0.37 will see much improvement in this area. A few issues have arisen and been resolved. The issue of handling comments in SVG documents was brought up by a Sodipodi user; comments are not always preserved when editing in Sodipodi or Inkscape. Fortunately, some good ideas have been voiced for addressing this. A second and much more critical issue has been raised regarding Gtkmm. As planned since early in the project, we began incorporating Gtkmm into Inkscape following the 0.36 release. Quickly it became evident that this introduced severe dependency issues. Gtkmm 2.x is not available commonly on most Linux distros. On Windows it adds to the DLL download weight. Most distressingly, it isn't yet ported to OSX. Due to these reasons we've decided the best course of action is to postpone use of Gtkmm until the library is more widely available. Statistics Nov 02 Nov 15 Nov 29 Dec 15 Dec 31 ========== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 6103 4391 3676 2452 2444 (56.2%) (68.5%) (73.6%) (82.4%) (82.5%) Max Week's Rank on SourceForge: 6023 62 37 27 22 (56.8%) (99.6%) (99.8%) (99.8%) (99.9%) Total SF Page Views 200 * 50,000 86,000 107,600 Total SF Downloads 0 * 1700 3640 4,751 Total Freshmeat URL Hits 0 746 1121 2237 2567 Total Freshmeat Subscriptions 0 16 19 28 30 Lines of Code in src/: 115,754 115,901 116,970 132,134 165,664 Code lines 100,549 132,458 Comment line 11,591 12,234 Blank 20,559 21.540 Lines of Docs in doc/: 1,135 1,135 2,100 2,225 2,615 Lines of content in website: 74 1,173 1,624 2,090 2,261 Size of the Inkscape wiki: 0 3,700 5,737 7,385 11,062 Hours since last ChangeLog mod: 90 6 2 21 0.8 Bugs open/total: 0/0 9/15 40/51 67/111 66/130 Features open/total: 0/0 18/18 23/24 40/45 103/115 Patches open/total: 0/0 1/ 6 5/20 6/25 4/32 CVS Commits (as per inkscape-cvs): 148 481 963 * 1580 Inkscape-devel membership: 4 49 61 64 65 Inkscape-announce membership: 0 9 14 16 20 * - Statistics unavailable

1 0

Re: [Sodipodi-list] 
by Jonathan Phillips 01 Jan '04

01 Jan '04

Maybe a warning dialog or a status bar update would be positive to notify the user if a comment is orphaned in someway. I know though this would require some intelligent coding. jon On Wed, 2003-12-31 at 15:17, MenTaLguY wrote: > I guess one thing to think about is how to deal with Sodipodi's > "advertising" comments if comment preservation were added. > > Obviously we wouldn't want to add an advertisment comment to the > document if one already existed, or they'd start piling up every time > one was saved. > > -mental -- Jonathan Phillips <jon@...15...>

2 1

Re: [Inkscape-devel] Nuke the fake config?
by bulia byak 01 Jan '04

01 Jan '04

>I didn't think about the gen-nrconfig change very closely when it was >first made, but in retrospect, since NRShort is a general-purpose type >with a precision implied by its name, changing its precision is probably >a bug in itself. > >The correct fix is to replace uses of NRShort that require more >precision with a type that provides it -- e.g. NRLong, or better gint32. Why "better"? What if one day, we need 64 bit precision - do a global search and replace again? The NR* stuff was there exactly for this: a layer of abstraction that allows to change the actual precision quickly - and it was not "a bug" because the typedefs are there for exactly this purpose (and they were not "general purpose" becaue the NR prefix limited their scope pretty narrowly to the NR subsystem). Frankly I don't understand why it was necessary to kill it and replace with hard-coded 32-bit types (I can understand getting rid of nr-config.c, but not this). Anyway, it's not my domain, so please fix it one way or the other, so long as it's fixed :) _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

3 4