- Inkscape Devel - Inkscape Mailman

RE: text inset
by bulia byak 16 Dec '03

16 Dec '03

>ok, fixed. a few notes: >- the text was insetting correctly on my computer, >because it was using another font; the reason the >shape disappeared turned out to be the orientation of >glyphs path in conjunction with winding fill rule. Thanks! >- the result is filled with black because that's the >value it gets when asking for the stroke attribute in >the style (see xml tree), so it may be the color >handling bug you refered to in a previous bug report Yes, I think so. Jon, it's http://sourceforge.net/tracker/index.php?func=detail&aid=859568&group_id=93… which you said is yours. Do you have any progress with it? It's really getting in our way :) Now there are two more problems. Take the bug-textinset again and: - set its outline to 1 pt, press ctrl-) three times. It grows OK, but on fourth and subsequent outsets, nothing happens - it stops to grow. - now remove the stroke - you'll notice areas where the shape bacame really weird, e.g. under the top left serif of "w". - now reload the file and repeat, this time with a 0.5 pt stroke. Now it stops after 4 applications of outset, and there are less broken areas (but the "r" is still somewhat broken). So: why does it stop growing, and can you do anything about the broken contours? (sorry about the nitpicking, but it's a very very useful feature, and I want it to work as perfectly as possible) _________________________________________________________________ STOP MORE 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…

1 0

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

15 Dec '03

>If the actual check is done in SPText (I forget if it is), then it needs >to have some way of signaling that failure to its caller (an >SPTextContext method, in this case). OK, here's another one for you: knot.c, sp_knot_handler(), available are SPCanvasItem, GdkEvent, SPKnot. I want to explain in the statusbar when Esc cancels node drag. How do I get an SPView? (Sorry to keep bothering you, but I'm not too familiar with the hierarchy of objects.) _________________________________________________________________ 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

some questions/suggestions
by Alexander Kirillov 15 Dec '03

15 Dec '03

Hi, just checked out version 0.36 - great job! Still, there are 2 issues that have always bugged me in sodipodi and still bug me in inkscape. If some one can suggest a workaround, I'd be glad to hear it. If not, maybe i should file this as wishlist items in bug tracker... 1. Is there an easy way of creating a closed Bezier curve? Of course, one can create an open one and then connect endpoints, but it is a long process... 2. When copying an object, the copied object is put at exactly the same position as the original. Am I the only one who finds it inconvenient? I frequently need to have several copies of the same object in different places my drawings, and selecting one of the two objects which are literally on top of each other is awkward, especially if the objects are small. I'd much prefer that "paste" creates a floating object, which follows mouse cursor, and you click to show where to put it. What do the usability experts say about such an idea? Best, Sasha PS. Please cc me when replying: I am not subscribed to the list.

4 4

The GPL'd database for Loads of Linux Links now includes http://www.inkscape.org/ (fwd)
by Bryce Harrington 15 Dec '03

15 Dec '03

---------- Forwarded message ---------- Date: Sun, 14 Dec 2003 12:33:16 -0800 (PST) From: Barbara E. Irwin <beirwin@...106...> To: bryce@...58..., buliabyak@...58..., mental@...107..., njh@...58... Subject: The GPL'd database for Loads of Linux Links now includes http://www.inkscape.org/ I've recently included the Inkscape website on the Loads of Linux Links project website, which can be found here: http://loll.sourceforge.net/linux/links/index.html Complete details of this project can be found here: http://loll.sourceforge.net/announce-1.1.0.html I have classified the website under: Graphics. Thanks for the link! Barbara ------------------------------------------------------------------------------ Barbara Irwin beirwin@...106... Victoria, B.C. Canada The Roman Rule: The one who says it cannot be done should never interrupt the one who is doing it.

3 2

absolute path
by bulia byak 15 Dec '03

15 Dec '03

Regarding this bug: http://sourceforge.net/tracker/index.php?func=detail&aid=860202&group_id=93… does anyone else think that document.cpp must store the absolute path already, i.e. instead of document->uri = g_strdup (uri); in sp_document_create we should have something like document->uri = abs_path (uri, base); That would fix the above bug. If so what standard function is there for creating an absolute path? I could not find one in glib. _________________________________________________________________ Shop online for kids� toys by age group, price range, and toy category at MSN Shopping. No waiting for a clerk to help you! http://shopping.msn.com

1 0

RE: [Inkscape-devel] some questions/suggestions
by bulia byak 15 Dec '03

15 Dec '03

>1. Is there an easy way of creating a closed Bezier curve? Of course, >one can create an open one and then connect endpoints, but it is a long >process... In freehand and bezier tools, just press 'a'. It will then display anchors at both ends of the curve being created, and by drawing to these anchors you will close the curve. And closing a curve in node editor is in fact not difficult at all. >2. When copying an object, the copied object is put at exactly the same >position as the original. Am I the only one who finds it inconvenient? I >frequently need to have several copies of the same object in different >places my drawings, and selecting one of the two objects which are >literally on top of each other is awkward, especially if the objects are >small. I'd much prefer that "paste" creates a floating object, which >follows mouse cursor, and you click to show where to put it. What do the >usability experts say about such an idea? Actually you CAN move a pasted or duplicated object with arrow keys, because it's selected. Press ctrl-d and then arrows, it's very convenient imho. But I plan to change the paste command so it by default pastes in the center of the visible canvas, and a variant of this command (e.g. with shift or alt) pastes to where the object was copied from. _________________________________________________________________ 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] handling statusbar messages
by bulia byak 15 Dec '03

15 Dec '03

>No, it just means that status bar messages need to be set from places >that know which SPView they're operating on behalf of (if any), or less >likely that an SPView needs to be passed in somewhere that it currently >isn't. > >Maybe we need to step back a moment though -- which g_warnings do you >want to turn into status bar messages, "Non-printable character" >and why? Because the user needs some feedback to understand why a character he typed in (most likely in Unicode mode, but not necessarily) did not appear on the screen. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f%2fjoin…

2 1

C++ conversion
by MenTaLguY 15 Dec '03

15 Dec '03

The switch to C++ is essentially complete. Please do a clean checkout. -mental

1 0

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

15 Dec '03

>On Sun, 2003-12-14 at 22:19, bulia byak wrote: > > Here's a quick question. I want to display the warnings on the statusbar > > (instead of g_warning) in sp_text_insert in sp-text.c. What I have at >this > > point is just an SPText object. How do I go from it to SPView? I see no > > members in _SPText that I could usefully -> to. > >There is not a 1:1 relationship between SPTexts and SPViews. Which means, we need to set the status of the global current desktop, after all? _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjo…

2 1

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

15 Dec '03

>The easy way would be to have sp_verb_get_action() create SPActions on a >per-SPView basis (currently only one SPAction is created for each verb, >globally). > >An SPView * can be stored in each SPAction, so the SPAction::perform() >callback will "know" which SPView * (i.e. SPDesktop *) it applies to. > >Voila. No more need for using SP_ACTIVE_DESKTOP in verbs. > >sp_verb_get_action() is only used in a very few places, so the change >should be very non-intrusive, but it will (among other things) finally >let us implement per-desktop tool states correctly. Sounds good. Please add this to the roadmap :) Here's a quick question. I want to display the warnings on the statusbar (instead of g_warning) in sp_text_insert in sp-text.c. What I have at this point is just an SPText object. How do I go from it to SPView? I see no members in _SPText that I could usefully -> to. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f%2fjoin…

2 1

RE: [Inkscape-devel] sp_status_display()/sp_status_clear()
by bulia byak 15 Dec '03

15 Dec '03

> static SPDrawAnchor * > sp_draw_anchor_new (SPDrawContext *dc, SPCurve *curve, gboolean start, >gdouble dx, gdouble dy) > { > SPDrawAnchor *a; > > sp_status_display(g_strdup_printf ("Creating anchor at %g %g", >dx, dy)); > ... > return a; > } > >Admittedly, the "original" would have been overly complex. The thing >is, I think we have to be careful not to simplify the wrong things. > >For example, why did we need the last parameter to sp_view_set_status() >anyway? It's never actually used. It seems a good candidate to remove. Done. >Also, shifting half the burden of memory management off is not a bad >thing, but why not get both ends? Otherwise to people other than >authors of sp_status_display(), it looks like a memory leak. Sure, I would have done that myself, if only I knew how to define functions with variable number of arguments :) Now that you've shown me how to do that, I'll be able to avoid such things. I see you could not wait and removed my functions replacing them with yours :) Sorry I'll now overwrite your changes, replacing them with still better functions that have time control (but implemented using your _statusf internally). Right now I have one problem that I need help with. The stupid gtk_timeout_add can only pass one argument to the function it calls, but I need two arguments to remove the message: the statusbar * and the message_id. I tried packing them into a struct and passing a pointer to the struct, but here are two problems: - if the struct is static, things break when a new timed message is displayed while a previous one's timeout has not yet elapsed, because the new call of the message display function will overwrite the static struct contents, and only the last message will be removed and the previous one will stuck forever; - if the struct is local to the message display function, it does not work at all, because its content is lost when the function is over. What I want is a way to pack the contents of the struct itself, not a pointer to it, to pass to gtk_timeout_add. But it won't convert a struct into a gpointer that this function requires. What to do? A workaround might be to pass only message_id (converted to gpointer) and leave the statusbar stored in a global variable. But that is ugly and unreliable. _________________________________________________________________ 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

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

15 Dec '03

>On Sat, 2003-12-13 at 23:42, bulia byak wrote: > > 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. > >I may have talked about using the GTK statusbar stack earlier, but then >I looked further into the GTK statusbar API and it's really pretty >awkward (IMO). How do you feel about it? Don't know - OK for me. I use push to display and _remove to remove a message with a specific id (i.e. if it was already replaced by some other message, nothing changes). >To that end, I want to keep the signal (or at least some kind of >notification callback) to maintain that interface boundary. OK, I kept the one signal, but added an argument msec (how long to stay the message, forever if zero). > > 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? > >Well, at present SP_ACTIVE_DESKTOP is a necessary evil in a few places >-- but I'd certainly appreciate if you could minimize its usage. I would not call them "a few". For example, all global verbs use it, because I see no other way for them to perfom their action, given they can be called anywhere, e.g. in a dialog. >Adding a method to SPEventContext to set the status message for that >event context's desktop would be good too (maybe something printf-like >... e.g. sp_event_context_set_statusf (SPEventContext *context, const >gchar *format, ...)?). Will do that now. All tools will display a helpful default message when sqitched to. _________________________________________________________________ Don�t worry if your Inbox will max out while you are enjoying the holidays. Get MSN Extra Storage! http://join.msn.com/?PAGE=features/es

2 1

C++ conversion
by MenTaLguY 15 Dec '03

15 Dec '03

Just a quick heads-up that the C++ conversion is happening tonight (if all goes smoothly). -mental

1 0

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

14 Dec '03

> > Now I have a segfault whenever I apply inset/outset > > to e.g. a star or circle > > (converted to curves first). > >uh? doesn't bug here... changed the SP_IS_PATH in >SP_IS_SHAPE, maybe it'll correct the problem (i don't >understand the difference). inset/offset dont change >style anymore. Great. I only now realized that you inset/outset a shape by its stroke width, so with stroke:none there's no expansion. I don't think this is expected behavior - I may very well want to inset/outset a shape without a stroke. Instead, let's decide on some standard inset/outset step, say 1pt, that is applied to all shapes (now hard-coded, later settable in preferences). Also currently there's a bug that drops stroke:none when new shapes are created, and it causes a crash when attempting to expand a shape that has stroke-width but has no stroke: or stroke-opacity: in its CSS. We'll try to fix this bug ASAP, but for now could you please add some extra protection in your code: if there's no stroke: specification it is implied to be "none". >the good behavior would probably be to >set the style to >"fill=none;stroke=black;stroke-width=1.0pt". No, why? I think we must restrain from setting some arbitrary styles; the commands must preserve the fill and stroke (when insetting/outsetting) and convert stroke to fill (when converting stroke to path). > > determine the shape of the > > cut-out. When I subtract bottom from top, I may end > > up with a quite > > unexpected shape because I don't see what I'm > > subtracting. > >agreed. changed the order so that it's "under-over", >but the determination of which object is over the >other is done "the dirty way (tm)" by looking in the >xml tree, since i couldn't find a function doing that >elsewhere. if you know of such a function, can you >tell me where it is? I think there's a z-order property in CSS, but I don't know if Inkscape (or SVG) use it at all. As far as I can see, the XML tree order is the same as the z-order in Inkscape, at least for drawings created in the program. But I may be wrong. Anyone else have an insight? >the polygon intersector i use currently rounds >coordinates to 1/32, so that more precision than >needed. the function that creates d="" in >splivarot.cpp is liv_svg_dump_path() and is a copycat >of sp_svg_write_path(). Yep, but you probably copied it before I changed the precision. As I see, now your commands create d="" paths even with 9 digits so that should be enough I think. >i hope my "tweak it 'til it works" development style >doesn't bother you too much; it's fine for livarot >since nobody uses it, but might be a problem for a >real program like inkscape... No problem!!! We're doing this ourselves all the time. Our motto is "patch first, discuss later" :) We're very excited about your code, so please continue working on it. We'll have lots of time to fix most bugs before the next release. _________________________________________________________________ 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

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

14 Dec '03

>ok, some problems you mentioned are corrected (text >not handled in outlines, offsets not behaving like >outlines, outlines done even when stroke=none). Now I have a segfault whenever I apply inset/outset to e.g. a star or circle (converted to curves first). >for difference, the rule "result=bottom-top" is a >stamping; while i have nothing against it, forcing >users to change the organization of the elements to do >an operation is probably not good. so i changed the >behavior to "result=first selected-second selected", >so that layering doesn't need to be changed to do a >difference. if that doesnt feel right, i'll change it, >no problem. I think this is wrong. First, the order of selecting objects may (in complex drawings) entirely depend on how convenient is each object for selecting. Second, one may select both objects with one rubberband, in which case the "order" is undefined. And third, when I prepare to do difference, I need to see and adjust the edge of the future shape, which means I need the subtracted shape to be on top because it will determine the shape of the cut-out. When I subtract bottom from top, I may end up with a quite unexpected shape because I don't see what I'm subtracting. >as a side note, it is true that outlines and such >don't like path obtained by the freehand tool. in my >opinion, there are already 2 things causing this: >dumping the coordinates in the d attibute in the xml >representation is not done with enough precisoin >(should be corrected now that you've increased the >precision), so that tangents at each end of the cubic >patch (in fact, the control points) move slightly. >since these tangents are very short, this result in >(random) sharp edges, spikes and the like; also the >points collected by the tool are fitted to bezier >curves by the fitter in bezier-utils.c, while it may >be better to collect all the points and then fit them, >like illustrator does "Cleanup" has always been a mystery for me, I never had time to figure out what it actually does. Is there any value in it being separate? Maybe combine it with simplify? As for precision, I just changed %g to %.8g in svg/svg-path.c so that now curves are stored with 8 digits in each point in the d="" attribute. Is this enough for your purposes? If you have similar code that creates d="", you can use the same specification there. And if you can in any way improve the freehand tool, e.g. by sombining it with your simplify command, that would be fantastic! What I would love to see is a slider controlling how closely the program reproduces the freehand. (For now, you can just make it a fixed value so I could recompile with different values to experiment, and I will add UI for changing it later.) _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f%2fjoin…

2 1

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

14 Dec '03

> mywidget(FOO, BAR, ftos(1.0/42.0)); It's nice, but now instead of the single printf ("C %.8g %.8g %.8g %.8g %.8g %.8g", ....) I will have to create 6 char[] buffers and call ftos 6 times, just as sodipodi 0.33 does... I'd like to avoid this if possible. Also, I don't see any mention of some non-standard and potentially useful rounding modes in ftos. And something of what it offers (such as the *10^X notation) is useless for us because we need it for SVG, and SVG must remain parsable. So for now, my vote is for including a standard locale-independent printf into the codebase. This will fix the win32 problems with minimum code disruption and will let us expand our printf version if necessary (e.g. with different rounding modes). _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f%2fjoin…

5 7

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

14 Dec '03

> > Initial Comment: > > - create a text string > > - convert to path > > - inset or outset > > The path disappears (no d="" attribute). > >fixed that for outlines (SP_IS_PATH() is true for >text, i wasn't expecting it), i'll change the >.._do_offset() function later (it's a minor change) Indeed "stroke to path" (i.e. outline) now works for objects from a text string, but inset/outset segfaults for them :( > > Initial Comment: > > When insetting or outsetting a shape repeatedly, it > > loses fill and stroke (gets fill:none;stroke:none) > > after the second inset/outset. On the first > > inset/outset, it sometimes becomes black. Fill and > > stroke must be preserved in inset/outset operations. > >losing the stroke is intended: if you have a path, and >want a polygon representing the stroke, that new >polygon has no stroke, just a fill. so the function >sets stroke to none and fill to the stroke of the >original path. outlining a second time should will >have the fill none since it will be copied from >stroke. maybe i should prevent outlining if stroke is >none? or use another behavior? What you describe is correct for the "stroke to path" (i.e. outline), but I was speaking about inset/outset. These operations should of course preserve fill and stroke. > > 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). > >distortion is the problem here. when simplifying the >outline stroke of very thin strokes (like a 1 pixel >wide stroke), distortion becomes very visible, so the >treshholds depend on the stroke width now. if you want >to apply it to arbitrary path, you need a way to >specify the treshholds (which are sort of the maximum >distance from a point to the approximated curve). note >that the sp_selected_path_cleanup() does not use the >bezier fitter in helper/bezier-utils.c, but simply >merges the subpaths when possible; it's far less >agressive than sp_selected_path_simplify(). at any >rate, i dunno what to do here, except removing >sp_path_selected_simplify() altogether... No, don't delete it :) I will experiment with different threshold values to find a value more suitable for standalone application of the command. As for using simplify with inset/outset, the dependence on the stroke width is of course correct, no need to change that. >regarding the errors in outline (d="", >irregularities), can you send me SVG samples? Will do, later today. _________________________________________________________________ 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…

1 0

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

14 Dec '03

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? _________________________________________________________________ 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 2

sp_status_display()/sp_status_clear()
by MenTaLguY 14 Dec '03

14 Dec '03

I notice that sp_status_display() was introduced a couple days ago, and that it is used like this: static SPDrawAnchor * sp_draw_anchor_new (SPDrawContext *dc, SPCurve *curve, gboolean start, gdouble dx, gdouble dy) { SPDrawAnchor *a; sp_status_display(g_strdup_printf ("Creating anchor at %g %g", dx, dy)); ... return a; } Admittedly, the "original" would have been overly complex. The thing is, I think we have to be careful not to simplify the wrong things. For example, why did we need the last parameter to sp_view_set_status() anyway? It's never actually used. It seems a good candidate to remove. Also, shifting half the burden of memory management off is not a bad thing, but why not get both ends? Otherwise to people other than authors of sp_status_display(), it looks like a memory leak. [ rule of thumb: the module that allocates memory should almost always be the one to free it ] Why not change sp_view_set_status() or add an sp_view_set_statusf() so that it allocated and formatted the string internally? sp_view_set_statusf(SP_VIEW(SP_EVENT_CONTEXT_DESKTOP (dc)), "Creating anchor at %g %g", dx, dy); I realize SP_VIEW() and SP_EVENT_CONTEXT_DESKTOP() are awkward, but they are a cost of doing business in C. When we move to C++, we can start doing away with lengthy accessor names and we can remove the need to explicitly cast to superclasses: dc->get_view()->set_statusf("Creating anchor at %g %g", dx, dy); I have introduced an sp_view_set_statusf() and a corresponding sp_view_clear_status() to CVS HEAD. I would appreciate it if you would use them in place of sp_status_display() and sp_status_clear(). sp_view_set_statusf_va() can also be used to implement other *_set_statusf() methods in other places (see sp_view_set_statusf()'s implementation for an example). -mental

1 0

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