- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Virtual memory problems - win32
by bulia byak 11 Mar '04

11 Mar '04

I think I fixed this. Please test tomorrow's build. _________________________________________________________________ Add photos to your messages with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

Re: patch comments
by bulia byak 11 Mar '04

11 Mar '04

>They should track selection, I added the listener code >to toolbar, they update when you select a shape with >different properties (try creating a bunch of >different stars, the spins should update as you select >different ones. should also track handle changes.) >i also put the event handlers to do esc and stuff in. Ah, yes, sorry, I didn't notice your patch did not apply completely - for some reason it had bad line counts in two places and my patcher ignored the rest of it. Now I applied it in full - works really well, thanks! Notes: 1 You copied rect's tooltips to some of the new spinbuttons, write appropriate new ones instead. 2 toolbox.cpp: In function `void sp_star_toolbox_selection_changed(SPSelection*, GtkObject*)': toolbox.cpp:582: warning: `SPRepr*repr' might be used uninitialized in this function toolbox.cpp: In function `void sp_rect_toolbox_selection_changed(SPSelection*, GtkObject*)': toolbox.cpp:844: warning: `SPRepr*repr' might be used uninitialized in this function toolbox.cpp: In function `void sp_spiral_toolbox_selection_changed(SPSelection*, GtkObject*)': toolbox.cpp:1042: warning: `SPRepr*repr' might be used uninitialized in this function Do not assume that variables are automatically NULL, assign NULL explicitly when you declare them. 3 In the star, I can drag any of the handles closer or farther from center than the other. However the Sharpness spinbutton has its own idea of which handle must be "inner" and which "outer", so it shows the incorrect value of 1.0 when I drag the inner one away. It should be smarter and check the ratio of the handles first, before it calculates the sharpness. 4 Please try to remove the arbitrary limits like 32 star rays or 20 max revolution in spiral. 5 I think the defaults (0) are only useful for rect, as they allow to quickly get a not-rounded rect. In other tools, the defaults are pretty arbitrary and therefore useless. So I propose to remove those "defaults" buttons from spiral and star. 6 In addition to cx/cy spinbuttons, you may add start/end angle spinbuttons and an chord/segment toggle for the ellipse. Eventually it might be worthwhile to add more handles to some shapes too, for example a lower-right-corner handle for a rect so that the selected rect could be easily resized by the rect tool (in addition to adjusting its rounding radii). 7 When I click "not rounded" on rect, it resets radii to 0, but when I then draw a rect, it sometimes gets some small radius values (0.01 or 0.02). Looks like a rounding error somewhere. I will look into the "invalid cast from `GtkCheckButton' to `GtkSpinButton'" problem tomorrow. _________________________________________________________________ Free yourself from those irritating pop-up ads with MSn Premium. Get 2months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: [Inkscape-devel] problems with win32 (German)
by bulia byak 11 Mar '04

11 Mar '04

>but the rect is shown as it is (with no fill) Thanks, it is also caused by the same bug where , is used instead of . in numbers. We're working on that. _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: [Inkscape-devel] problems with win32 (German)
by bulia byak 11 Mar '04

11 Mar '04

>I tried to attach a the file, >but it doesn't give me any button to do that. >I will attach the picture to this e-mail. Rect1 is still holduing the mouse >button (you dont see the cursor on the screenshot). Rect2 is after release >the button. Thanks, but we're more interested in the resulting SVG file, not the screenshots. Also please attach your preferences file ($HOME\Inkscape\preferences.xml), it may be useful for debugging. _________________________________________________________________ MSN Premium with Virus Guard and Firewall* from McAfee� Security : 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

RE: [Inkscape-devel] "problem with gradients" (Bug 850924)
by bulia byak 11 Mar '04

11 Mar '04

>So, if it's a problem in Nautilus, then there really isn't anything we >can do. Shall I document the workaround and close the bug? Properly, this should have been investigated... But with the bug being scarce for info (no sample) and with Lauris' opinion, I'd vote for closing it. _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

patch comments
by bulia byak 11 Mar '04

11 Mar '04

1. This bit must come _before_ any drawing in GDK_MOTION_NOTIFY: if ( event_context->within_tolerance && ( abs( (gint) event->motion.x - event_context->xp ) < event_context->tolerance ) && ( abs( (gint) event->motion.y - event_context->yp ) < event_context->tolerance ) ) { break; // do not drag if we're within tolerance from origin } // Once the user has moved farther than tolerance from the original location // (indicating they intend to draw, not click), then always process the // motion notify coordinates as given (no snapping back to origin) event_context->within_tolerance = false; Its purpose is to do nothing if the mouse hasn't trespassed tolerance limit from the origin. However in arc-context (and probably elsewhere) you have sp_arc_drag() before it, which kinda defeats its purpose. 2. event_context->xp and xy should be reset to 0 in GDK_BUTTON_RELEASE, just in case. 3. Like I said, tolerance can be a local variable, i.e. instead of event_context->tolerance = prefs_get_int_attribute_limited ("options.dragtolerance", "value", 0, 0, 100); you can have guint tolerance = prefs_get_int_attribute_limited ("options.dragtolerance", "value", 0, 0, 100); and remove it from SPEventContext. 4. Cosmetics: please fix indentation (I don't care tabs or spaces, but the nesting structure must be indented properly), AUTHORS should remain alphabetical, and remove the "hello" :) Other than that, good work! Now what remains is the cosmetic/behavior of spinbuttons (focus, keys, font size - as in rect) and, most importantly, spinbuttons' event handlers and listeners to track selection. _________________________________________________________________ http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

RE: Spoonshapes - win32
by bulia byak 11 Mar '04

11 Mar '04

>I cannot make them appear regularly. Sometimes I can get two in >successsion. >Other times 15 or 20 normal ones might intervene. Noticed that as well. Please file a bug with your a screenshot. _________________________________________________________________ MSN Premium helps eliminate e-mail viruses. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

RE: [Inkscape-devel] "problem with gradients" (Bug 850924)
by bulia byak 10 Mar '04

10 Mar '04

>Summary: problem with gradients >Bug ID: 850924 I can't verify, but this bug is closed in sodi: http://sourceforge.net/tracker/index.php?func=detail&aid=782800&group_id=40… _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN Premium http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

Re: offset & simplify
by bulia byak 10 Mar '04

10 Mar '04

>to false). apparently illustrator does exactly the >same kind of errors in its offsets, so i suppose they >have taken the same method. You used a constant value in the call to Coalesce in sp-offset. I changed that to: SPItem *item = &(shape->item); NR::Rect bbox = sp_item_bbox_desktop (item); gdouble size = L2(bbox.dimensions()); gdouble exp = NR::expansion(NR::Matrix(item->transform)); if (exp != 0) size /= exp; orig->Coalesce (size * 0.001); I.e. I coalesce by the 0.001 of the item's size (divided by transform, because offset works with the original untransformed path). And it now works perfectly for most sizes! Only in the smallest size, at 256x zoom, there are noticeable distortions resembling pixelation, apparently because of a lack of precision somewhere causing nodes to "snap to grid". However, this is a much smaller annoyance than before. The version with my change is committed. Another change I did was reducing the minimum allowed radius from 0.25 to 0.01: if (fabs (offset->rad) < 0.01) offset->rad = (offset->rad < 0) ? -0.01 : 0.01; because with 0.25, there was a noticeable "jump" around 0 for small objects. _________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: offset & simplify
by bulia byak 10 Mar '04

10 Mar '04

>the offset quality is dependent on the simplification >quality, especially the "correct" version. for the >time being, i leave the bad version (selected by >setting the global use_slow_but_correct_offset_method >to false). apparently illustrator does exactly the >same kind of errors in its offsets, so i suppose they >have taken the same method. its advantage is that it's >faster, and easier to recombine in curves. but i still >haven't found a nice way to have a treshhold that >depend on the "detail" size (like for the "good" >version), so the simplification can eat some details. >as far as simplification is concerned, it's probably >wiser to leave someone else come up with a good >algorithm (and to not default to Coalesce(), which is >sometimes too strong). I tried use_slow_but_correct_offset_method = true, which gave good results indeed, but froze and crashed soon :( So I guess we should leave it at false for now. As for the current method, again, if it gives correct results for large objects, what prevents you from "tricking" it so it believes all objects are large enough for the artifacts to never appear? >also, when you say >"simplification", i assume you mean (a bit) >"smoothing". Yes, that's what is often needed in design, and what most people expect when they do "simplify": reduce the number of nodes making the path smoother. >The simplify() functions don't do >smoothing at all; they were intended to remove very >small segments in the path description, that's all. So I guess it's useful for doing simplification as part of the offset, but not usable for standalone Simplify command. >i can't remember what the defaults were for >yesterday's sp_selected_simplify(), but i don't think >i have done major changes to the behavior of simplify. >it's probably just the difference between >justCoalesce=true and justCoalesce=false Yes! options.simplifyjustcoalesce was 1 by default, now I changed it to 0 and it works very well again! With the starting threshold of 0.003 * size, it gives a very smooth transition from the original shape to the degenrate two-node path, preserving the original outline as good as it can on every step. Thanks, and please do not change the algorithm used by the standalone Simplify anymore! :) (you can of course tweak the algo used by offset, to fix the distortions, if this is possible at all) _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar � get it now! http://clk.atdmt.com/AVE/go/onm00200415ave/direct/01/

1 0