- Inkscape Devel - Inkscape Mailman

[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

SPOffset UI
by bulia byak 31 Dec '03

31 Dec '03

Now there are two pairs of inset/outset commands: one creates the SPOffset object and the other simply offsets a path, leaving it as a path. Which pair is linked to the menu commands can currently be changed by commenting/uncommenting within sp_selected_path_offset() and sp_selected_path_inset() in splivarot.cpp. I propose the following UI: - "Inset path" and "Outset path" commands act depending on the type of the selected object(s). For SPOffset objects, they increment/decrement radius by options.insetdistance (to be added to the preferences, no more relying on stroke width please!). For all other objects, they do one-time offset leaving objects as paths (or converting them to paths if necessary) also by options.insetdistance. If there are several objects selected, each one is treated according to its type. - The third command, "Dynamic inset/outset", creates an SPOffset with zero radius. It also flashes to the statusbar, "Use node editor to inset/outset the path interactively." If there are no objections, Fred, could you please implement these three commands and I will put them into the menu and in shortcuts. See this page on how to create/access a preferences value: http://www.inkscape.org/cgi-bin/wiki.pl?HandlingPreferences More issues: - The splotches bug is fixed, but now interactive offsetting has become much slower. With a text string, I need to wait at least a second after dragging the control before it regenerates the path. Is this inevitable, or can it be optimized somehow? - The quality of offset in SPOffset object is very good, however the sp_selected_path_do_offset() function creates ugly artefacts (e.g. try it on a text string) even when applied _only once_. Why the difference? - Please use statusbar API to report errors, instead of g_warning: http://www.inkscape.org/cgi-bin/wiki.pl?StatusBar Whenever a command cannot perform its action, it must provide a reason for it in the statusbar. Also please don't forget to enclose all text strings shown to the user into _("...") so they can be translated. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

3 2

Re: [Inkscape-devel] Nuke the fake config?
by bulia byak 31 Dec '03

31 Dec '03

>For those who were not on Jabber last night: > >Done. I replaced the following definitions >with GLib types: >NRLong gint32 >NRULong guint32 >NRShort gint16 >NRUShort guint16 You broke zooming with that change, because previously I patched gen-nrconfig so that shorts are not shorts but actually ints. Now shapes disappear at about 69x zoom. See this patch: http://sourceforge.net/tracker/index.php?func=detail&aid=854506&group_id=93… Please restore the ints precision as per this patch, so that zooming works again! _________________________________________________________________ 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

RE: [Inkscape-devel] RE: offset width modifying
by bulia byak 31 Dec '03

31 Dec '03

I've tried the new offset object - really impressive! For those who haven't tried it yet, you can now interactively adjust the inset/outset value by dragging a control point (similar to e.g. rounding a rect) and it will be redrawn in real time. You can also vary the radius attribute of the object in XML editor to achieve the same result. The quality and precision of the outline is very good (at least compared to the previous attempts to do multiple in/outsets). A few comments: - The new attributes that you add must be in the inkscape: namespace, not sodipodi:. - The inset/outset commads still require that a path has a stroke. Please change them so that they decrement/increment the radius attribute, by say 1 pt with each command, regardless of stroke (converting a path into offset if necesary). Ideally we'll need to have two pairs of commands, say one incrementing radius by 1 pt and the other (with alt) by the distance corresponding to 1 visible pixel at the current zoom (similar to alt-arrows). - The statusline description of the object can be more useful if instead of simply "Offset" it would say e.g. "Path inset by 1.5pt" or "Path outset by 3pt". - Even though the path quality is now very good, I still noticed occasional "splotches" that would be nice to fix. I'm now uploading one example to the bug tracker so you can see what I'm talking about. _________________________________________________________________ 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…

3 2

gtkmm2 rollback
by MenTaLguY 31 Dec '03

31 Dec '03

Well, I've made an executive decision... The packaging situation with gtkmm2 is really pretty dire at this point on several platforms (even RedHat), so I'm going to roll back our gtkmm2 dependency for now. I hadn't expected it would trail Gtk2 packaging by THIS MUCH, but it seems to be... Hopefully the situation will resolve itself in the next month or two, and we can go back to using it. -mental

2 1

Re: [Inkscape-devel] Re: dnd [was: Re: export patches]
by bulia byak 31 Dec '03

31 Dec '03

>Okay, had to change > >rnewdoc = sp_repr_read_mem (svgdata, data->length, NULL); > >to > >rnewdoc = sp_repr_read_mem (svgdata, data->length, SP_SVG_NS_URI); > >now it should behave exactly like the import function. Updated patch >attached and posted to the tracker. Works for me ;) Thanks! Indeed it works well now. I think you can commit it. Of course it'll need more testing when/if Gimp supports svg dnd too. And by the way, why can't I drag an svg document from my KDE desktop into Inkscape? Is this version of dnd Gnome-only? _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

5 8

Nuke the fake config?
by Jon A. Cruz 31 Dec '03

31 Dec '03

Can we get rid of gen_nr_config.c and nr_config.h? We 'should' just be using standard config approaches and config.h. This is even in gen_nr_config.c /** * A little utility function to generate header info. * * Yes, it would be possible to do this using more "native" autoconf * features, but I personally find this approach to be cleaner. * * The output of this program is generally written to art_config.h, * which is installed in libart's include dir. **/ To me, that translates as "I don't understand the standard ways, so I'll subset and re-invent a wheel myself". Given that we're trying to keep cross-platform including Win32 and OS X support, it probably is time to kill it. Are there any issues I'm missing? Or anything from those building on Win32 that would complicate things?

3 2