December 2003 - Inkscape Devel

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

14 Dec '03

> > >I would prefer that you implement the push/pop/timeout behavior and API > > >in SPView, perhaps supplementing or replacing sp_view_set_status(). > > > > > >The signal itself should not need to change. > > > > Wouldn't we need to have at least two signals for pushing and popping? > >Not necessarily; the SPView could maintain a stack of messages, and >simply notify observers via the signal when the top of its message stack >changes. But GTK already has the stack of statusbar messages, why duplicate it? I think it's better to make two signals instead, one for push and one for pop. On the other hand, wait a minute. You have explained why we need to go to SPView in order to set statusbar. But why SPView has to send signals? This only makes sense if there may be more than one listener; but do we want different document windows to display the same message, even if they show the same document? I think not. Messages are always displayed in the window where the things happen. So maybe we can handle this without signals, i.e. get directly from the selection (or whatever else issues the current message) to its desktop widget? >Right now, given the current desktop, you need to look at >SP_NODE_CONTEXT (desktop->event_context)->nodepath->selection to get a >GSList of the selected nodes. By the way, now it's GList, not GSList :) I changed that some time ago to do tab-cycling back and forward in a more natural way. > > You know, being a usability freak, I care about usability not only for >users > > but for coders too. I think that the coder should not be forced to >provide > > anything but the obviously necessary information for each task. > >My experience with using global variables over the years is that they >DON'T make code more usable for developers (I use the term >"maintainable"), in the long run. Hey, actually my favorite programming language is XSLT, so you don't need to explain that to me :) And I was not advocating using globals, only making function calls as short and simple as possible. >The button actions should have been created on a per-desktop basis, >rather than having a shared set that all used SP_ACTIVE_DESKTOP. >However, fixing that requires a major reorganization of parts of the >codebase. OK, I promise to never use SP_ACTIVE_DESKTOP anymore :) Instead I will create several functions that accept different kinds of "current things" (such as selection, event context, desktop) and do different ->...->...-> chains to always arrive at the desktop widget that corresponds to that argument object (if possible, without signals). Then in different parts of the code I'll have to call different functions, depending on what object I have at hand. Would you approve of that plan? > > Otherwise the chances of errors will increase because people (like me :) > > will have to copy obscure bits around without fully understanding them. > >I don't want to stymie you, since you do really exceptional UI work -- >just, for now I would prefer that you copy the bits of indirect code >(maybe shifting them into helper functions for your own use), and in >your own new code try to stick with passing things as parameters rather >than using globals as much as possible. I'm not against passing parameters; I just want these parameters to be logical and short, with the fuiction itself doing all the ->->-> instead of me :) P.S. Have you tried my "black magic" bug? I have even recompiled it with -O1 but that did not help :( Do you think I can commit the g_print "fix" with appropriate comments (well, at least it's guaranteed not to break anything)? _________________________________________________________________ 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…

2 1

Re: [Inkscape-devel] color selector changes
by bulia byak 14 Dec '03

14 Dec '03

Jon, I suspect that http://sourceforge.net/tracker/index.php?func=detail&aid=859568&group_id=93… may also be related to your changes to color.c or style.c. Could you please have a look? This bug really makes it difficult to work in the program. >bulia byak wrote: > >>Jon, >> >>I wonder if >> >>https://sourceforge.net/tracker/index.php?func=detail&aid=859607&group_id=9… >> >> >>is a result of your recent color picker changes? Could you please look >>into it? > > >Most likely. Could be a missing scale value somewhere. > >I'll check. > > > _________________________________________________________________ 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…

2 1

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

14 Dec '03

> > 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? > >I would prefer that you implement the push/pop/timeout behavior and API >in SPView, perhaps supplementing or replacing sp_view_set_status(). > >The signal itself should not need to change. Wouldn't we need to have at least two signals for pushing and popping? >For example, in sp_selection_update_statusbar() in selection.c: > > sp_view_set_status (SP_VIEW (SP_ACTIVE_DESKTOP), message, TRUE); > >What happens if SP_ACTIVE_DESKTOP is not the desktop that the selection >object is attached to? What if it's a desktop for an entirely different >document. This won't normally happen (yet), but it could in the future. > >There is no need for the extra indirection anyway. An SPSelection knows >which desktop it is from; this should be: > > sp_view_set_status (SP_VIEW (selection->desktop), message, TRUE); OK, but what if there's no selection currently? And what if I want to update statusbar in the node editor? Its idea of selection is different (nodes). Perhaps I can still access selector's selection in node edit, but I haven't tried yet; can it be done in a simple fashion that would work everywhere? E.g. a global variable that always points to the current selection? You know, being a usability freak, I care about usability not only for users but for coders too. I think that the coder should not be forced to provide anything but the obviously necessary information for each task. Otherwise the chances of errors will increase because people (like me :) will have to copy obscure bits around without fully understanding them. So, I would prefer to have a function like set_statusbar_of_selection("message") that would figure out the active selection, go to its desktop, send signal, etc. In those rare cases where a message is not logically attached to a selection, another function would be used where you must also provide an SPView object. Is this feasible? How to reliably figure out current selection, and what to do if it's NULL? _________________________________________________________________ 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 2

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

14 Dec '03

I've put the three problems I found into the bug tracker: https://sourceforge.net/tracker/index.php?func=detail&aid=859680&group_id=9… https://sourceforge.net/tracker/index.php?func=detail&aid=859681&group_id=9… https://sourceforge.net/tracker/index.php?func=detail&aid=859686&group_id=9… so that they're not forgotten. I've also renamed and regrouped the menu commands and changed shortcuts. Hopefully the new commands are now more accessible. An issue I'd like to discuss is the simplify path command. As it is, it may be useful in combination with inset/outset to prevent exponential growth of nodes, but for a standalone command I would like to see a more aggressive algorithm. Now simplification preserves the shape very closely, and it does not always result in reducing the number of nodes. For example draw a freehand line and then simplify it - on the first step, the number of nodes usually increases! On subsequent simplifications, it decreases back, but not to the original number, and after some time the path becomes "stable" and is not simplified further. I would like a command that guarantees to remove at least one node on each application, and may distort the shape to achieve that (but tries to keep distortion to the minimum). When applied sequentially, such a command would eventually reduce any shape to a single bezier curve (i.e. two nodes for open subpaths, one node for closed subpaths) that approximates the original as closely as possible. Is this doable? Another command I would like to see is "divide". When applied to two paths, this command would cut the bottom object into pieces along the top path. E.g. is you have a smaller circle over a rectangle, applying "divide" would break the rectangle into a rectangle with a circular hole and a separate "plug" fitting that hole. I think it should be easy to implement by combining difference, intersection, and duplicate commands. _________________________________________________________________ Winterize your home with tips from MSN House & Home. http://special.msn.com/home/warmhome.armx

1 0

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