- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] new booleans
by bulia byak 14 Dec '03

14 Dec '03

The new inset/offset with simplification works much better! The only glitch being that it often loses fill and stroke (fill:none, stroke:none in the style attribute) after offsetting, but I guess this should be easy to fix. Sometimes there's a strange irregularity. Create a star with approx. 20 rays, convert it to curves, and offset path several times. Most rays are expanded uniformly, but there are usually one or two that are distorted (usually at the top). This distortion seems to depend on how sharp were the original rays. One more problem: when I do difference, I expect the top object to be extracted from the bottom one, but it does the reverse. And now that we have the simplify path operation, it also must be on the menu and have a shortcut. I'll take care of that now. I'm also thinking about the best shortcuts for all these new operations. For example: ctrl+ union ctrl- difference ctrl-* intersect ctrl-^ xor (I think "xor" is easier to understand than "symmetric difference") ctrl-(, ctrl-) inset/offset ctrl-shift-(, ctrl-shift-) inset/offset by 10 times the usual amount (if possible) ctrl-alt-c convert stroke to path (ctrl-shift-c being "convert object to path") ctrl-i simplify path Any objections? If not I'll commit these. _________________________________________________________________ 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…

1 0

boolean operations
by MenTaLguY 13 Dec '03

13 Dec '03

Just a quick heads-up before I head off to bed... Nathan's merged Fred's boolean path stuff into HEAD, and I think we've nailed down the last of the build problems for the time being. Y'all might want to have a look. -mental p.s. looks like we will be starting the C++ conversion in earnest late this weekend

3 4

Re: [Inkscape-devel] handling statusbar messages
by bulia byak 13 Dec '03

13 Dec '03

>The way the class hierarchy works is: > > SPView - base class for all views of an SPDocument > ^ > SPSVGView - rendered graphical view > ^ > SPDesktop - editable rendered graphical view > >SPViews are the 'model' side of the MVC equation, with various widgets >(SPDesktopWidget is the one normally used with SPDesktops) acting as >view/controllers. It's actually the SPDesktopWidget, not the SPView >(SPDesktop) which is subscribing to the status message signal. I still don't see why SPView is involved in statusbar handling... but anyway, if you say this is right, let it be. What ails me is that I want to provide a richer and more convenient interface for statusbar messages. For example, I want a function for temporary displays that are pushed and then popped after some timeout. This means the statusbar signal must be split in two, or at least given extra arguments. Is this the right approach? >Btw, I do not want us to introduce more global state as far as "finding >the current desktop automatically" -- eventually I want all signal >handlers and SPActions bound to specific views, so they "know" their >associated view rather than having to look at a global variable to know >which is 'current'. Right, but what is to be done now? As I wrote, now all calls to sp_view_set_status start from the desktop and figure out its view. If this is wrong, what is right? Starting from some object on the canvas that logically "issues" the message, ascending to its SPView, and then sending a message from SPView to the associated desktop widget? That seems overly complicated to me, but I'm OK with it if its implemented and if I'm given a convenient interface to it. In other words, what is the minimum of arguments that a statusbar-setting function (callable from anywhere) must have? Now it accepts a message and an SPView, but I don't like having to figure out the SPView every time I call it. Can there be a function that accepts only the message and if yes, how to program it properly? _________________________________________________________________ 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…

2 1

black magic
by bulia byak 13 Dec '03

13 Dec '03

I found a bug that is likely triggered by the new NR high resolution. It's here: https://sourceforge.net/tracker/index.php?func=detail&aid=859364&group_id=9… Could anyone please confirm that bug with the latest CVS? I'm asking because the fix that I found for this bug is really very weird. I don't understand how it can fix anything. Pure black magic. Namely, add an empty g_print("") to line 204 of libnrtype/nr-rasterfont.c: NRRectF * nr_rasterfont_generic_glyph_area_get (NRRasterFont *rf, unsigned int glyph, NRRectF *area) { NRRFGlyphSlot *slot; glyph = CLAMP (glyph, 0, rf->nglyphs); g_print(""); slot = nr_rasterfont_ensure_glyph_slot (rf, glyph, NR_RASTERFONT_BBOX_FLAG | NR_RASTERFONT_GMAP_FLAG); On my computer, this fixes the crash. I would really appreciate if anyone can confirm both the bug and the "fix", and especially give any insight on how this fix could affect anything (and maybe even on how to fix this properly). I spent several hours trying to debug this but this g_print was the best I could find :) _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

doc?
by bulia byak 13 Dec '03

13 Dec '03

The 0.36 source tarball contains no /doc. What's up? _________________________________________________________________ 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

Re: [Inkscape-devel] printf
by bulia byak 13 Dec '03

13 Dec '03

> > > If not for this problem, does printf satisfy our requirements or are >there > > > any other problems with it? If it's OK, maybe we could just include >the > > > "standard" printf right into our codebase, instead of linking to a >library? > > > Just an idea. > > > > Possibly, but if we do one ourselves we can be more clever with e.g. > > rounding behavior. Anyway, Bryce said he alraedy had some code > > somewhere, as I recall... > > > >Yes, I do. I've added a task for myself to add this to the codebase. The reason I ask this questions is because I see how Lauris is handling this in 0.33. Now instead of a single printf call, he declares a char[] buffer for each value, calls a custom conversion function, and then assembles these buffers into a string. That is extremely bulky and hard to read, and I would like to avoid this if possible, preserving the format string approach of printf. So, how close is your code to being a drop-in replacement for printf with its format strings? _________________________________________________________________ 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…

3 2

printf
by bulia byak 13 Dec '03

13 Dec '03

>*printf() exhibits locale-dependent behavior on win32; we >need to replace it with our own code for generating correct >SVG measurements regardless of locale. If not for this problem, does printf satisfy our requirements or are there any other problems with it? If it's OK, maybe we could just include the "standard" printf right into our codebase, instead of linking to a library? Just an idea. _________________________________________________________________ Help STOP 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…

3 2

handling statusbar messages
by bulia byak 13 Dec '03

13 Dec '03

Currently, whoever needs to update statusbar calls sp_view_set_status() giving it the message and a pointer to a SPView object. This function emits a signal from that SPView object, and this signal is caught by the desktop object which does actual update to the statusbar (using gtk_statusbar_push()). This seems strange. Why is SPView involved at all? In ALL cases when sp_view_set_status() is called, the caller code has (or finds out) the current desktop and then finds its SPView by saying SP_VIEW(desktop), only to pass this to the sp_view_set_status(). Given that the message ends up being handled by the desktop anyway, the entire mess with SPView and emitting/catching signals seems unnecessary to me. The code needing to update statusbar could call a function in desktop.c directly, either giving it some desktop pointer, or even letting it find out the current desktop automatically. The signal and the statusbar-setting functions in view.c could then be eliminated. I think the code would be simpler and more logical this way. Any comments? _________________________________________________________________ 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…

2 1

zoom and precision
by bulia byak 12 Dec '03

12 Dec '03

I've augmented my libnr precision and 256x zoom patch with a fix to store SVG paths with 8 digits instead of 6 (changing %g to %.8g in printfs in svg/svg-path.c). Since I've been using this patch for some time and have not seen any problems, so I decided to commit it now. This is code that is in use literally every second, so by putting it in early in the release cycle we'll be able to catch more bugs with it. Please work and play at higher resolutions than you usually do and submit any bugs to the tracker. Note that you'll need to rerun configure after updating because I patched libnr/gen_nr_config.c which is recompiled and rerun on configure (I think). _________________________________________________________________ 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…

1 0

Open Source myths
by Jon A.Cruz 12 Dec '03

12 Dec '03

Here's a nice little article on software development http://www.onlamp.com/pub/a/onlamp/2003/12/11/myths.html Of all the issues raised, the ones I've thought about I'm in agreement with. The few I hadn't consciously considered before seem to be right on track also. In all, it seems that these are things that those in the Inkscape community are doing, however it's always good to explicitly state what's good and why. Among other things it might help us improve and also just keep us on track. (so at the very least, read the article and keep things in mind)

1 0