- Inkscape Devel - Inkscape Mailman

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

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

C++-ification
by Bryce Harrington 12 Dec '03

12 Dec '03

Just a quick head's up, we're about to proceed with the renaming of all .c files to .cpp. Nathan is working on updating Makefiles &tc. presently and if it works out, he'll be committing the changes soon. The expected near-term effects to be aware of: * Change histories on code files will be reset * Potential build issues on some platforms * Everyone will need to cvs update -Pd, make distclean, and rebuild * Compilation with gcc will cease to work as support for gcc is ended * If you are working on a branch or out of sync with CVS HEAD, your next merge may be more complicated than usual due to the file rename These issues should be transitory, but please expect some turbulence for a bit. Thanks, Bryce

2 2

Re: [Sodipodi-list] Re: 0.8 multiplier
by MenTaLguY 12 Dec '03

12 Dec '03

On Thu, 2003-12-11 at 13:06, Lauris Kaplinski wrote: > SVG spec is resolution agnostic. Yes, but I finally read this part of the SVG spec... > All its units are just > defined as certain ratios of undefined base unit (pixel), that > may or may not be related to some real-world unit. For the initial coordinate system, the SVG specification refers to CSS2's definition of length units, which broadly specifies two classes of units: 1. relative units which do NOT have fixed relationships with real-world units * em and ex: determined by the current font size * px: determined by the user agent, generally some multiple of device pixels 2. absolute units which _are real-world units_ (subject to the user-agent's ability and desire to match them) * mm: real-world mm * cm: 10 mm * in: 2.54 cm * pt: 1/72 in * pc: 12 pt > Sodipodi document has real-world dimensions. > To map resolution agnostic SVG onto real-world paper, it uses > mapping: > 1 SVG point == 1 typographic point (To be totally pedantic, typographic points are 0.0138 in, which is not _quite_ the same as Postscript/SVG points [1/72 = 0.01388888...]; I think everyone uses the Postscript definition nowadays though.) > As 1SVG point == 1.25 SVG pixels, and pixels are SVG base units, > SVG base unit == 0.8 typographic points on all sodipodi documents. Unless a viewBox is set, the relationship between user-space base units (pixels) and the absolute units is totally user-agent dependent. (this is why all examples in the SVG spec specify a viewBox) Thinking about this, if Sodipodi intends to be completely interoperable, it needs to always write a default viewBox according to the base units/points mapping it imposes. e.g. for a document 100ptx100pt, the viewBox should be "0 0 125 125". -mental

1 0

menu reorg
by bulia byak 12 Dec '03

12 Dec '03

I propose to break Edit menu into two, Edit and Object. Otherwise it's pretty long already, and will be still longer when we add boolean ops. I think everyrhing up to and including Clear All/Select All should remain in Edit, and the remainder of items should go to Object. If there are no objections, I will commit (it's a cosmetic patch so it's unlikely 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

0.37 plan
by Bryce Harrington 12 Dec '03

12 Dec '03

It's very cool to have 0.36 out the door after so much work! It's being well received by the community, and the feedback is that we've definitely made notable improvement over the baseline. So what's next? First, as we talked about, we're going to keep things low key the rest of the month, and enjoy the holidays. This next release is going to be a bit different than this past one. For 0.36 our goal was to strive to get some new features in and revamp the look and feel, to prove that this project brings new value to the community and to gain experience working as a project. For the 0.37 release our focus is going to change. We want to make the codebase itself better, so that it is easier and more enjoyable for us to work on in the future. Doing this will require undertaking several sizeable endeavors: * Convert the codebase to C++ * Change from function prefixing to true C++ namespaces * Adopt a new code style * Remove all obsolete code * Organize all of our documentation The above work will touch pretty much all the files in the codebase, and since that could be a significant amount of work, I think we should use a divide-and-conquer approach to it. A way to achieve this is to divide the codebase into several distinct "subsystems"; this way the size of the commitment each of us must make will be tractible, and so that we can work together as a team to achieve them. I'll establish a list of these subsystems shortly; there is a diagram on the Documentation page of the website to give some hints as to what this list will be. In addition, there are several features we'd like to pursue, such as reorganizing the dialogs, Fred's new booleans work, and Nathan's grid code. There are also a number of bugs we decided to leave to this release, that should receive attention. We can look forward to seeing these features and bug fixes folded in, as we proceed with the principle objective of the code conversion and cleanup. Bryce

1 0

Plugins - first cut at requirements list
by Bryce Harrington 12 Dec '03

12 Dec '03

I've posted my first stab at a list of requirements for a plugin/extension/module system here: http://www.inkscape.org/cgi-bin/wiki.pl?PlugIns Ted's done a good bit of work on implementing support for a module system, so hopefully this list can be made to mesh with that work. The intent of making a requirements list is to firmly identify what we want out of this system, so that as folks work on implementing it, it is clear what it needs to do. Please look it over and add your thoughts of what should be in there. Bryce

1 0

new booleans patch
by bulia byak 12 Dec '03

12 Dec '03

I've been sent a new patch that implements boolean operations, offset/inset path, and path outline. The license is public domain. It's been uploaded to the tracker. I've just compiled it and it seems to work as advertised, although I did not test it much yet. I will now incorporate it properly (creating commands for all functions) and test as much as I can. If there are no problems, I think we must get this into CVS right now, before the release. Rationale: 1) it's a killer feature, 2) it's orthogonal to everything else, so even if something is broken in the new functions, this will not affect the rest of Inkscape. Everyone is welcome to download and test the patch too (or at least review the code). Big thanks to the author! _________________________________________________________________ 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…

3 3

status bar discussion
by bulia byak 11 Dec '03

11 Dec '03

Please review and contribute: http://inkscape.org/cgi-bin/wiki.pl?StatusBar _________________________________________________________________ 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

RE: [Inkscape-devel] New guide prototype
by bulia byak 11 Dec '03

11 Dec '03

>G'Day! >Peter and I have been working on a new grids and guides idea which extends >the control handle idea of Dia and Visio 'correctly' (We can justify this >claim quite strongly). There is a test bed version of it at: Thanks, I really enjoyed it! The ability to move a guide so that all objects aligned to it would move too was something I always dreamed of. But I'm not sure I fully understand the difference between the two tools. Is it correct that the first tool behaves exactly as the current selector, i.e. scales and moves regardless of snaps (but keeps the snaps where breaking them is not required for moving), while the second one attempts to scale or move preserving snaps if possible? Note that currently in selector, the edge of the object is not the same as the resize handle, as the handle is always at some distance from the edge. When you implement the "snap marks" you will need to attach them to the object's bounding box, not the handles. And the center of an object can now be moved to any point, so snapping the center onto something must take into account (this is particularly important with text objets, where I often need to align e.g. the baseline of a letter, which is neither the center nor the edge). _________________________________________________________________ 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…

1 0

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

11 Dec '03

>>- The GTK+ selector is shakey: when you move the small circle inside the >>triangle, the triangle shakes and jitters. I think this is because the >>color itself produces HSV, but its position is determined by the RGB, and >>the conversion/rounding errors when the color goes to RGB and back make it >>unsteady. Can you ensure that the color wheen is connected to the HSV >>value? Also, when you move the circle to the black or white corners, the >>triangle snaps to the red, i.e. loses its current hue value. I think this >>will also be fixed if you make it reflect the HSV value, not RGB. >> > >Guess what? Don't bug me about this one. ;-) > >Actually... it is just the standard GTK+ color selector. My code only >creates one and then listens for changes. All those details are handled by >the GTK+ version you're running. > >Although it could be a bit of feed-back loop. I'll check to make sure >that's minimized. Yes, that seems to be a feedback problem. I commented out the last gtk_signal_emit (GTK_OBJECT (csel), cs_signals[CHANGED]); in sp_color_gtkselector_gtk_changed(), and jittering is gone, although the object color is not updated. So you just need to make sure this signal you emit is caught by the right listeners (i.e. the canvas objects) and not the color widget itself. Maybe encosing the emit into a pair of block/unblock functions might help. >Actually "color palettes" were something I was going to add. For the GTK+ >wheel, I just need to feed an array of colors for the palettes. Of course we need a separate color palette widget, ideally dockable to the document window, but for now a small palette inside the picker would be nice too. >So we might need "color palettes", "color schemes" and "swatches". I think >details of this would be best hashed out on jabber and on the Wiki. Yes, and a current color widget too (see wiki). >True... but it's built into the GTK+ widget. It does not have alpha (the >one difference). Of course, a simple work-around is to just hide the bottom >entry area when the color picker has one. Would that work better or be >distracting? I don't like that option too. Would be ideal to find a way to tweak the standard GTK widget. >I've split the second notion off into the notebook with tabs. Thus the >"Mode" switch should change to only determine the colorspace to use. I was >planing on "RGB", "CMYK" and "Any", with "Any" being the default. Later we >might also add "Spot". Then it must be named more descriptively, e.g. "Store color as:", but then "Any" sounds kind of funny. >But... I was just thinking the other day that another approach might help. >If we did named "color picker sets" then the user could change the set >named "full" and the set named "brief". They could also create new sets and >use them per location, or just stay with the default sets. I was thinking >that this has the benefit of being simple for beginning/normal users, yet >allow full customization for power users. And the coding would not be too >different than for a two-state enum'ed or boolean'ed set. Maybe, although I don't feel a need for this. Maybe just me. I think the GTK color wheel can be the default picker most people use, and the others are just "for completeness" and for special purposes. The wheel makes it possible to enter RGB values anyway, and it's not that you'll want to move RGB sliders very often, because HSV is much more natural to an artist. >In either case, hooking the color selections up to the new overall >preferences setting dialog would be handy. Yes, that's where it belongs IMHO, without cluttering the actual picker interface. Please add that to the PreferencesDialog wiki page. _________________________________________________________________ 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 helping
by Jonathan Phillips 11 Dec '03

11 Dec '03

Although I'm new to the project and everything (congrats to ourselves on the new release), it is important for me to tell everyone I'm involved with about some personal things. My sister, Charis Gohil, passed away today at 3 AM CST. It was an amazing peaceful moment here as it was the first snow, and we (family and my sister) had our last words before the end of her time on earth. I started a journal about my sister, but it is not really that relevant anymore, but has pictures of her and myself. http://protofunk.org/?page=bio/charis/index I loved my sister very much and am happy that she is in a better place :) jon On Wed, 2003-12-10 at 21:46, Bryce Harrington wrote: > On Wed, 10 Dec 2003, Jonathan Phillips wrote: > > > stuff... > > > > Bryce, I'd be on top of all these changes but my sister's state has > > worsened in the last two days. She is probably going to pass away in the > > next day or two. I will get back as soon as possible. Sorry I can't help > > get this release out the gate. I'll be on board and running at 200% > > soon. I'm going to be offline here for a bit. > > > > This is not all doom and gloom here, it is actually been one of the best > > times with my sister ever...fyi... > > Thanks for the note; don't worry about Inkscape, family comes first. > We've got things well in hand. > > Btw, what's your sister's name? > > Bryce -- Jonathan Phillips <jon@...15...>

2 1

RE: [Inkscape-devel] color selector changes
by bulia byak 11 Dec '03

11 Dec '03

>Well... I just checked in some changes for the color selector. It needs a >little more polish (mode, CMYK types, and the popup to select subsets of >possible pickers) but should be ready for some initial testing and use. Thanks! My initial impressions: - Do the slider strips have to be so wide (i.e. tall)? I'd like to see them take less vertical space. - Before, the slider strips expanded horizontally when you resized the fill&stroke dialog. This was nice as it allowed to get a better resolution at the expense of screen space. Now they stay the same length no matter how you resize the window. - RGB, CMYK, and HSV are all familiar abbreviations to a designer. But "GTK+" is confusing. Is this a new color model? Better call it by what it shows, e.g. "Wheel". - The sliders are always black and therefore are invisible on dark areas of the strip (this was the problem with the old picker too). They need to be made either e.g. black interior with white outline, or some pseudo 3D, or (as in Gimp) pairs of black triangle at top and white at bottom, or automatically inverting when going from light to dark and back (as is the pointer on the GTK+ wheel). - The GTK+ selector is shakey: when you move the small circle inside the triangle, the triangle shakes and jitters. I think this is because the color itself produces HSV, but its position is determined by the RGB, and the conversion/rounding errors when the color goes to RGB and back make it unsteady. Can you ensure that the color wheen is connected to the HSV value? Also, when you move the circle to the black or white corners, the triangle snaps to the red, i.e. loses its current hue value. I think this will also be fixed if you make it reflect the HSV value, not RGB. - BTW when you resize the window, it's the color wheen in the GTK+ tab that must be made larger so you can pick colors with better precision. - When the fill&stroke dialog has focus, the GTK+ triangle has some ugly non-antialiased one-pixel black border. Without focus, it looks OK, no border. - In Gimp, a similar GTK+ color wheel also has a small palette where you can remember colors (in the bottom right area). Can we have it, too? - "Color name" should really be "Hex" or something like that. Besides, it's redundant as we have the RGBA field below. - The "previously selected color" in the GTK selector is always black. It must reflect the color we got from the program or from preferences; i.e. for "apply to selected objects", when I select a new object, both halves of the color swatch must show the same color, and then the left side should stay the same while the right one is changing. - The "Mode" switch at the top seems redundant (and incomplete), now that we have the multi-tab interface for different pickers. - The bottom right button that allows you to select which pickers are shown is also redundant, IMHO. Instead, the color selector must remember (both within and across sessions) the last picker used and show it when activated. With this, removing pickers is not necessary and frees no extra space. _________________________________________________________________ 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

New guide prototype
by Nathan Hurst 11 Dec '03

11 Dec '03

G'Day! Peter and I have been working on a new grids and guides idea which extends the control handle idea of Dia and Visio 'correctly' (We can justify this claim quite strongly). There is a test bed version of it at: http://bowman.csse.monash.edu.au/~pmoulder/guides-LATEST.tar.gz To run it you will need python-gtk2 and python-numeric (also called numpy). Please run it and tell us if the behaviour feels right - it is easier to try variations whilst the code is python, rather than C++ (although it is easier to know whether the behaviour feels right once we implement it in inkscape proper) Feel free to ask questions about our intentions, and suggest extensions that would be helpful. Clearly the prototype is but a taste of what can be done with this new approach (We have several whiteboards worth of ideas to implement :), but it is important to work out the basic interface now. In particular, what do people think about the two tools behaviour? Should this be folded into a modifier key on the selection tool? Can it be done well with only one tool? Is the breaking of constraint behaviour (which control point disconnects when you move something) reasonable, or can you suggest a better heuristic? (Currently the rule that is broken is chosen arbitrarily, perhaps it would be better to break the oldest created relationship, or perhaps the least recently moved?) What do people think of the indicators for how control points are connected to guide lines and guide points? Suggestions? In case you're wondering, our intent is to provide Dia level diagraming support, as well as strong CAD type design elements. Some things which we know how to do, but haven't added include: adjustable spacers, enforced alignment and distribution, clipart with programable control handles (like visio), and many other goodies :) Thanks, njh

2 3

Inkscape 0.36 - "See, even a 5 year old can use it."
by Ted Gould 11 Dec '03

11 Dec '03

Inkscape Release 0.36 "See, even a 5 year old can use it." This is the second release of Inkscape and there has been a tremendous amount of work that has been done on the project. Many patches and ideas that had been 'waiting in the wings' have now been applied to the codebase. Now Inkscape is easier to use for users as the interface is less complex and more intuitive. In Brief: * Main GUI has been significantly redesigned * Usability of dialogs, keyboard shortcuts, and mouse is improved * Preliminary support for layer grouping, path markers, and extension modules * Much more user and developer documentation - doxygen, docbook, man page, wiki, diagrams, & more * Many bugfixes, minor enhancements, and usability tweaks What is Inkscape? The Inkscape application is an open source SVG editor with capabilities similar to Illustrator, CorelDraw, Visio, etc. Supported SVG features include basic shapes, paths, text, alpha blending, transforms, gradients, node editing, svg-to-png export, grouping, and more. Enhancements * CSDI interface has been traded for an SDI one: Now each document window has its own menubar at the top and its own detachable toolbar at left. This increases Inkscape's compliance with the GNOME HIG and decreases confusion for the majority of users. * A secondary (horizontal) detachable toolbar is introduced for operations and controls specific to each tool. At the moment this toolbar is mostly empty but we have big plans on how to fill it with all kinds of useful things for convenient access. * Dialogs now always stay on top of the document window (even if you have several document windows open). They are easy to open or activate (using shortcuts displayed in their title bars), close (Ctrl+w), or defocus (Esc). Moreover, dialogs remember their size and position across sessions. * New commands: Paste style (apply the style of the copied object to the current selection), Fit page width to window. * Introductory layers support. There is now code in the code base to start handling layers. GUI elements to follow - watch this slot! * Arrowhead and marker support. A much requested feature which increases the usability of Inkscape for everyday tasks. * Using mouse is now less painful thanks to the increased mouse tolerance (you don't have to be exactly over an object to grab it) and introduced drag tolerance (very small drags, which are usually accidental, are now considered clicks and do not move anything). * Undo is now unlimited (that is, limited only by available memory). * Lots of new keyboard shortcuts. Notably, Esc now consistently deselects, cancels selection, and cancels drag or transformation of any kind (so far only in selector and node edit). Arrows, Ctrl+a, and Tab/Shift?+Tab act on nodes in node editor exactly as they do on objects in Selector. There are at least two ways to activate each tool, one with an F<number> key (Corel Draw style) and another with a single letter (Adobe Illustrator style). Space toggles between Selector and your current tool. Dialogs are consistently activated by Ctrl-Shift-<letter> combinations. * There's no lower limit on the size of exported PNGs anymore. You can use Inkscape to create even 1x1 PNG images. * The standard xml:space attribute on text objects is now honored. For newly created objects it has the value of "preserve" which means all whitespace characters are shown exactly as typed. * Enhanced modules system. Now modules can be defined using external files so no C coding is required for an extension. * Mac OS X and Windows build fixes. These builds are getting more mature and working better. * Increased code documentation. Come check it out, the Inkscape codebase is getting more readable every day. * Numerous bugfixes and usability improvements. Infrastructure * The web presence of Inkscape is dramatically different than with the last release. If you haven't already, you should check it out at: http://www.inkscape.org. * Many people have been contributing to the Wiki, which has a sizable amount of content today: http://www.inkscape.org/cgi-bin/wiki.pl. * Doxygen documentation builds are now happening on HEAD nightly: http://www.inkscape.org/doc/doxygen/html. * CVS snapshots are taken on a nightly basis: http://www.inkscape.org/cvs-snap/. What lies ahead * More useful stuff in the secondary toolbar - all kinds of controls that are relevant to a specific tool will be put into that toolbar for convenient access. * A new, extensive Preferences dialog. Lots of settings that are now hard-coded will be settable. * Dialogs reorganization: less dialogs overall, with their functions more logically grouped. * More precision, maximum zoom of 256x or more. * Complete keyboard control for node editing, including editing control handles of a node. * GUI selection of arrowheads for path start/end/mid markers. Known problems * At least on KDE, floating dialogs may not stay on top when you switch between maximized document windows. You may need to click on the window's title bar to bring the dialogs to top. (See src/dialogs/dialog.events for a possible workaround and comments, feel free to suggest a patch.) * Also on KDE, detached toolbars do not stay on top. (This is a KDE problem.) * On Windows, dialogs do not stay on top of document in this version. * Some keyboard shortcuts (e.g. arrow keys for nudge) do not work if your mouse pointer is not over the document window. * When using Copy/Paste? (or Paste style) commands, you cannot copy gradients or arrowheads from one document to another. Workaround: use the XML editor to copy the content of the <defs> element from the source document to the target document, then copying gradients and arrowheads will work. * Pasting text directly into a text object on the canvas does not work. Workaround: open the Text dialog (Ctrl+Shift+t) and paste into the text editing area there, then click Apply. * 'warning: failed to load external entity "glade/icons.svg" - This is not a fatal problem, but merely an indication that Inkscape could not locate its icon images. This problem can also be detected when some of the button icons show up as random noise. The usual fix is to go through the 'make install' process so that the icons.svg file gets copied to the expected location. * 'colinear!' - This is a libart warning. The original libart intersector has all kinds of numerical problems, and it is believed that this warning is emitted if it tries to find intersection of two almost parallel lines. Robert Crosbie recently noticed this still occurs when using the Calligraphic tool. More information at: http://www.inkscape.org/

1 0

New Jabber server
by Bryce Harrington 11 Dec '03

11 Dec '03

Hi all, dmandell has graciously set up a permanent Jabber room for Inkscape on his server, and I'd like to propose we transition to that instead of the one on jabber.org. The reasons for this are: * Fewer users on it so probably not so laggy * We've got the ear of the admin (useful in case of problems) * Forewarning in case of server software changes * Fewer random visitors We're going to test it a bit this evening, and assuming things go well, and no one identifies any issues with transitioning, we will update the website docs to point there instead of jabber.org. Bryce

1 0

color selector changes
by Jon A. Cruz 11 Dec '03

11 Dec '03

Well... I just checked in some changes for the color selector. It needs a little more polish (mode, CMYK types, and the popup to select subsets of possible pickers) but should be ready for some initial testing and use. As part of it, I was simplifying the pickers to juse use SPColor objects instead of all the overloaded different component primitive types. This might be a good thing to continue... as it could facilitate moving to better color, custom spot color, etc. Oh, and the 'API' (as it were) for creating new pickers will probably undergo a little revision. At the moment the gtkcolorselector might be an interesting place to start.

2 1

0.36 release candidate tagged in CVS
by Bryce Harrington 11 Dec '03

11 Dec '03

The one priority-9 bug that was identified in testing was fixed by Bulia, thus closing the last task required for the Inkscape 0.36 release. It builds with both gcc and g++. Folks are itching to get into dev mode for 0.37. We're ready to cut the release. RELEASE_0_36_0 is now tagged in CVS. Unless we discover any major issues during packaging, this should be considered the official release source. If there are issues that require fixing for this release, we can create a branch from this tag point to work on them, and allow the main branch to return to development. This tagged version can be checked out via the command: cvs co -r RELEASE_0_36_0 -d inkscape_0_36_0 inkscape Ted, can you finalize and post the official tarball at your earliest convenience? Nathan and Mael, once this tarball is available, please proceed with creating the Debian and Windows binary packages, and I'll do the same for RPM. Once all of these packages have been created, then we will put out an announce to Freshmeat, et al. Hopefully we can achieve this within a day or two. Meanwhile, everyone should consider CVS HEAD to be unfrozen and available for open development once again. Thanks, Bryce

3 4

last changes pleease
by bulia byak 11 Dec '03

11 Dec '03

Hoping it's not too late, could you guys please take the latest CVS for the release? Just a couple last-minute cosmetic changes: h and v shortcuts for flipping, and the Edit menu is split into Edit and Object. This is important for making a good first impression, as the old Edit menu was way too big. _________________________________________________________________ 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…

1 0

RE: [Inkscape-devel] 0.36 release candidate tagged in CVS
by bulia byak 10 Dec '03

10 Dec '03

> > What about doc/keybindings.txt? Whoever is preparing the release, pray > > remove this old crap and replace it with a copy of KeyboardShortcuts >from > > wiki! > > (ideally this needs to be automated) > >Ah, true... > >Ted, I've marked this as a task for you. Bulia, can you cut a copy of >your doc from wiki and put it into CVS HEAD? Ted can pick it up from >there when he's ready. Done, doc/keybindings.txt removed, doc/keyboard-shortcuts.txt added (manually created for now). _________________________________________________________________ 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…

1 0

Website problems
by Jon A.Cruz 10 Dec '03

10 Dec '03

I've noticed some problems on the website in regards to it's markup. The most visible problems showed up under Mozilla 1.0.2. I then went to validate the pages (at http://validator.w3.org) and found that there are actual problems. Whoever can make changes should probably go through and use validators and do some cleanup. In hand with those pointing out problems, the 3.2 and 4.0 HTML references at http://www.htmlhelp.com are *very* useful, since among other things they are machine generated from the DTDs and include listing what tags/elements can contain others, and which can be contained. A *must* use for anyone doing web work. :-) Anyway, on to some specific problems: * The validator doesn't like the keywords meta tag for some reason. * Anchor tags can't contain H1 tags. Just swap and put the A's inside the H1's and all will be happy-happy * ALT attributes missing on images. It's polite to have them. :-D * List nestling broken. This is probably the main cause of the problems I was seeing. * Literal "<defs>" in the text, instead of "<defs>" On the list nestling, the problem is with UL's contained in other UL's. The validator complains because a UL can't contain another UL. However, it's legal to include a UL inside of a LI. So at the moment the last list entry is closed before opening a new UL. That closing </LI> tag should be moved to *after* the enclosed UL. Then all should be happy-happy. :-) (I've gone ahead and sent this out to the list since these are subtle things that are easy to trip over and not be aware of, however once understood they're easy problems to avoid. Plus the two links up there are very useful)

2 1

RE: [Inkscape-devel] 0.36 release candidate tagged in CVS
by Bryce Harrington 10 Dec '03

10 Dec '03

On Wed, 10 Dec 2003, bulia byak wrote: > What about doc/keybindings.txt? Whoever is preparing the release, pray > remove this old crap and replace it with a copy of KeyboardShortcuts from > wiki! > (ideally this needs to be automated) Ah, true... Ted, I've marked this as a task for you. Bulia, can you cut a copy of your doc from wiki and put it into CVS HEAD? Ted can pick it up from there when he's ready. Bryce

1 0

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

10 Dec '03

The updated patch from the author and my hookup patch (which puts the new commands into the menu and as shortcuts - ugly, just for testing) are here: http://sourceforge.net/tracker/index.php?func=detail&aid=857377&group_id=93… Bryce, can you give Fred developer access to the CVS so he could create a branch for testing the new functions? (Or maybe I can now do this too as an admin, but I don't know how :) _________________________________________________________________ Get holiday tips for festive fun. http://special.msn.com/network/happyholidays.armx

2 2

Re: libgsf + Inkscape
by Jody Goldberg 10 Dec '03

10 Dec '03

On Tue, Dec 09, 2003 at 09:49:19PM -0800, Bryce Harrington wrote: > On Tue, 9 Dec 2003, Dom Lachowicz wrote: > > > > I just committed a bunch of documentation. We're a bunch closer to 100% API > > documentation now. Nice work. > Very cool. May want to think about a webpage too... at the least, a > list of features. Yah. I know. I tend to be better at writing code than web pages. Probably when gsf 2.x comes out or someone steps forward. > Possibly libgsf and neon would obviate any need for gnome-vfs but I > haven't really looked in enough depth to say for sure. I haven't > confirmed that gnome-vfs actually supports WebDAV, and if it does, > how good the support is. > > WebDAV is composed of a number of different methods, some basic (GET, > PUT, HEAD), others more advanced (MOVE, MKCOL, PROPFIND, etc.) So when > a lib or app says it supports WebDAV you have to check 'how much'. Neon > supports a wide range of them, according to its feature list. > > http://www.webdav.org/neon/ Interesting I'll have to have a look. As mentioned our plans had been to use libcurl for network related activity. However, I have not checked on its webdav status any more than gnome-vfs. > Have a look at Neon and let me know what you think. Would it be > feasible to use it in conjunction with libgsf? I'll have a look. > The direction we're heading is to make wrapperization of the app easier, > whether that be with Python bindings (via SWIG?), Bonobo, or even a kind > of SVG Canvas. Being able to plug inkscape into other things opens lots > of very interesting uses of it. That would be very interesting. Abi and Gnumric had previously discussed supporting embedding by just rendering an svg image. Something like this would be nice.

2 1

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

10 Dec '03

Are you subscribed to the inkscape-devel list? Let's move our discussion there, because many people will be interested in your code. >the code is "borrowed" from the >sp_path_selected_combine(), and there's a check on the >number of elements in the selection (looks like it, at >least). It only checks that there are at least two objects selected: if (g_slist_length (il) < 2) return; So we need to fix it for the case when there are more than two. If you can make intersect and union functions accept any number of objects in one go, that would be the best. And for difference functions, we need to check that there are exactly two objects selected, and complain if not (for now you can just print a g_warning and do nothing). > > Inset and offset, although very very useful, are > > unfortunately more buggy. > > When you do them repeatedly, the number of nodes > > grows very fast, and soon > >oops... yes the number will grow fast (exponentially). >isn't there already a function to cleanup a path in >sodipodi? None that I know of. i recall seing somewhere discussion on how >to simplify a path... besides it's just a lame >approximation of the offset, there's probably wiser >algorithms (that i do not konw about) You can discuss this on the list with people who have much better knowledge of algorithms than I, such as Nathan Hurst. >well, the soutline/offset/inset algorithm is quite >stupid: build an offset path, and treat it like a >polygon. the "difficulty" lies in building the offset >path. the code is still rough, and doesn't like null >segments in the path, path with multiple subpath, >closed paths, etc... i have to admit it hasn't been >tested thoroughly; just outlining a path twice as you >suggested brought up a number of serious problems i'll >have to investigate. on top of that, the result of the >offset is transformed in a svg path description (so if >d="", it means the algorithm completely failed), and >the precision used to store the coordinates in the d >attribute seems insufficient. We plan to increase it from 6 digits to at least 8. Do you think 8 will be enough for you? >technically, coordinates >are rounded to a 1/32 grid by the code in livarot; >dumping the path with less precision in the xml tree >can cause ugly things. the cusps you mentioned are >usually small segments making sharp turns because >coordinates were rounded. using a round or bevel join >"removes" them (btw, how do you set the miter limit in >inkscape?) I don't think setting meter limit is implemented. Anyone? I think now the best course of action is this. I'll ask Bryce to give you access to the CVS so you could create a branch for testing and development of the new commands. You will store the entire Inkscape tree there, so that people would be able to checkout and test it without patching. To hook up your commands to the menu and as shortcuts, I did a simplistic patch, which I will now upload to the Inkscape tracker along with your updated patch; you can use my patch as a starting point. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

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

10 Dec '03

After some testing I can say that the four basic operations (union, intersect, diff, symdiff (which is similar to combine, except that it adds nodes where sides intersect)) are very stable. I could not force them to do something wrong or misbehave. The only problem is that when more than one object is selected, these commands only operate on the first two objects while others simply disappear. But I think it will be easy to fix. The quality of these operations seems to be good: no extra points, no curve distortion. Inset and offset, although very very useful, are unfortunately more buggy. When you do them repeatedly, the number of nodes grows very fast, and soon some very strange artifacts appear (such as dense "clusters" of nodes that really distort the shape). Also, when you do inset or offset to a path with many nodes, it becomes extremely slow, and Inkscape may hang for minutes. Sometimes, a path simply disappears (the object is there, but its d="" attribute is empty). The outline stroke function works acceptable. Sometimes the strokes are distorted (usually near ends or sharp cusps) but the number of nodes in the resulting shape is not too big, and for simple strokes it gives good results. >Actually, having looked at the patch, I think we really need to leave >this 'til the next release. Three reasons: First, it's in C++ and we >had decided to hold off on changes that commit us to C++ until 0.37. What is the value of preserving plain C compilability? Will people complain if we require C++ for 0.36? I, for one, do not care what is the compiler, so long as the program works :) >Second, it's a good bit of code, and deserves to be tested. The best way to test is to release! We're not doing 1.0, after all. It's just a 0. release. >Third, we >will need to do some additional development (buttons, etc.) to integrate >it. I could certainly live without buttons - menu commands and shortcuts are quite enough for the time being. Besides, we could borrow buttons from the other patch, and I think I remember seeing the icons somewhere in the sodipodi innards already. So my opinion is this: let's include the four boolean operations and outline path for this release, and then help the author debug the inset/offset operations for the next release. _________________________________________________________________ Get holiday tips for festive fun. http://special.msn.com/network/happyholidays.armx

2 1

Re: [Inkscape-devel] non-ASCII chars
by bulia byak 10 Dec '03

10 Dec '03

>So... it's often good to do 'sanitizing' of input. In this case, where it's >direct user input, speed should not even be a problem. OK, what about: u = g_utf8_get_char (utf8); if (u == (gunichar) -1) { g_warning ("Bad UTF-8 character"); return pos; } if (!g_unichar_isprint (u)) { g_warning ("Non-printable character"); return pos; } is this enough sanitizing? :) _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

3 2

Status of priority-6 bugs for 0.36 release
by Bryce Harrington 10 Dec '03

10 Dec '03

All of the priority 9 bugs and all of the bugs listed on the roadmap for required the 0.36 release have been resolved and closed. (It's been pretty amazing how much intensity was placed into bug fixing this last week; 20 bugs closed!) The remaining priority-6 bugs are listed and commented on below. My thought was that the priority-6 bugs "would be nice to close" but were not required. We've closed a number of them, and I think the remainder can be left for a future release. If anyone feels differently on any of these, speak up now. Bryce [ 851467 ] Export selection bounds too small There is a patch for this that John Stracke is developing for Sodipodi. If we wait a tad longer it might become more matured. See Sodipodi Bug#758775 for the patch. [ 841633 ] Icons problem for win32 I'd like to get confirmation that this still occurs, as I suspect the GtkButton rework may have resolved it. It doesn't cause a crash and sounds like its platform dependent, though. If the problem still exists, then it should be made high priority for the next release. [ 850936 ] .32 crashes when setting printer destination It no longer crashes but it does emit an ERROR message. This should receive high priority in the next release but may be acceptable for 0.36. [ 853804 ] SVG COMPLIANCE: Paths shown will fill when fill:none The issue is that "file: none;" and "fill:none;" behave differently for the given case. This is important for importing SVG but perhaps one we can leave 'til next release as it doesn't impact general use. [ 852619 ] XML editor crash There are a couple XML editor related bugs, but they appear unrelated. This particular bug is uncovered after a sequence of steps that may not be encountered by most users in general usage. [ 50549 ] spiral crash This is an easy bug to reproduce, however the spiral shape does not seem like one that would normally get heavy use. [ 847886 ] transformation inaccuracies The change from float to double addressed part of the bug, the remainder appears to be a legitimate issue but may not be noticeable to regular users. [ 851937 ] Postscript file output does not respect document size More of a feature request than a bug, I think. [ 851131 ] Print preview does nothing I'm not sure if print preview is implemented, as it's never worked for me. I've commented out the menu item. If this *does* work for anyone, let me know so we can leave it in but mark it a 'known issue', and get it fixed. Otherwise we should list high on the feature request list. [ 853858 ] errors when copying objects between docs Bulia estimates this will require too much effort to fix for 0.36. It's listed as a known issue on the release notes page. [ 850971 ] Crash while deleting too much using the XML editor This bug is in regards to deleting the sodipodi namedview element via the XML editor. I looked into the code to see if there was an easy way to trap it but to do it right it looks like it would take some research. Since it's an unusual error I don't think a quick fix would be appropriate, and some time should be taken during the next release cycle to find a good solution. [ 851779 ] Style property "currentColor" not used properly This is another compliance issue for importing SVG files. Specifically, from gnuplot.

4 4

RE: libgsf + Inkscape
by Bryce Harrington 10 Dec '03

10 Dec '03

On Tue, 9 Dec 2003, Dom Lachowicz wrote: > > > I'll work on getting at least the API documentation up-to-snuff during > >the > > > coming week. On the whole, the parts I envision a project like Inkscape > > > using strongly resemble STDIO's FILE operations enough for a strong > > > similarity to be found. > > I just committed a bunch of documentation. We're a bunch closer to 100% API > documentation now. Very cool. May want to think about a webpage too... at the least, a list of features. > >The Inkscape file management is one area in need of major reworking. > >Since Inkscape is at root a file editor, having powerful file management > >capabilities is important. As well, some currently only blue-sky ideas > >are brought within feasible reach by having support for things like > >WebDAV, archive access/extraction, etc. Several libs including libgfs, > >gnome-vfs, and neon have been suggested. We will be using one of these > >rather than creating our own, so we can focus our energies into SVG > >editing. ;-) > > I'm not familiar with neon, but I can definitively say that LibGSF better > fits your needs than GnomeVFS. At a bare minimum, we're able to piggyback > directly on top of GnomeVFS if you so choose, and with much less hassle. > With LibGSF, you get superb portability to other platforms and a wide > variety of inputs and outputs. Your application is inherently pluggable, at > least in terms of "file sinks." Possibly libgsf and neon would obviate any need for gnome-vfs but I haven't really looked in enough depth to say for sure. I haven't confirmed that gnome-vfs actually supports WebDAV, and if it does, how good the support is. WebDAV is composed of a number of different methods, some basic (GET, PUT, HEAD), others more advanced (MOVE, MKCOL, PROPFIND, etc.) So when a lib or app says it supports WebDAV you have to check 'how much'. Neon supports a wide range of them, according to its feature list. http://www.webdav.org/neon/ > As a side note, I've grown a bit bored with working on LibRSVG. I'll have to > check out Inkscape. We'd love to have you, we've been quite impressed with what you've done with librsvg. The project's quite fun - progress is swift, there's a good teamwork attitude, and plenty of room for new ideas. > >Alan had mentioned it also supported WebDAV? > > If GnomeVFS supports WebDAV, so would we. If not, we could add a plugin to > LibGSF probably pretty easily. Have a look at Neon and let me know what you think. Would it be feasible to use it in conjunction with libgsf? > >Cool, it sounds like this would take care of several user feature > >requests we've had such as cut and paste operability between Inkscape > >and AbiWord. There's also been interest voiced into bonobo. Most of us > >don't have much depth in the tech behind these so the more help/advice > >available, the easier it'd make it. > > Yeah, if it'd be possible to get at least image/png and image/svg on the > clipboard, that'd be awesome. And if you could make Inkscape into a > BonoboControl, that'd be sweet too. With LibGSF, you'd be able to load and > save things from BonoboStreams insanely easily. The direction we're heading is to make wrapperization of the app easier, whether that be with Python bindings (via SWIG?), Bonobo, or even a kind of SVG Canvas. Being able to plug inkscape into other things opens lots of very interesting uses of it. That, plus being able to interact with files (or svg streams generally) through network connections... I'm not sure I can imagine all the uses, but it would certainly make things possible that haven't been before. > >Yes I noticed these in the API docs, but I was wondering what the > >motivation for inclusion of them in this was? Are there special XML > >file management capabilities it provides over what'd be available from a > >generic XML library? > > Well, there is a really easy routine to create a XmlParseCtx from a > GsfInput. There are also a bunch of nice SAX utils. There is also a nice set > of functions for writing XML documents. I'm not sure if either is > appropriate for your needs, but they're there if you need them. Cool, thanks. Bryce

1 0

real world usability test
by bulia byak 10 Dec '03

10 Dec '03

Today my 5 years old daughter spent about 20 minutes in Inkscape, drawing stars. She enjoyed it a lot. She had no problem understanding the role of the selector button ("click it and then you can move your stars around"), node edit button ("click it and you can do funny things to a star by moving those small dots in it") and the star itself. She also used ctrl-z often. The main reason for joy is that the program did not crash :) There were some problems; the biggest bummer was when she accidentally grabbed the handle of the main toolbar and detached it - then she clicked on the canvas and the toolbar was gone! Bad, bad Inkscape. Also, the lack of a palette was a bit of an inconvenience, although I switched the fill&stroke dialog to HSV and she had no problems dragging the hue slider to get different colors for her stars (with two other sliders set to maximum). Overall, I think the program passed this test :) I don't think it would be that enjoyable with Sodipodi, with its myriad of confusing buttons and sinking windows... _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 1

Re: [Inkscape-devel] max undo
by bulia byak 10 Dec '03

10 Dec '03

> > One thing: right now subsequent arrow-key movements are stored as >separate > > undo steps. I'd like to combine all adjacent moves in one direction >(only > > horizontal or only vertical) in one step. Is there already a mechanism >for > > that, or do I have to dig into the undo system to implement it? > >Yes, there's already a facility present for that: >sp_document_maybe_done(). Thanks for the pointer. I tried this but it did not work until I replaced: doc->actionkey = NULL; by doc->actionkey = key; in sp_document_maybe_done(). This fix seems logical to me, but it's not my code so please confirm that it's correct. I've just committed a version that puts subsequent same-direction arrow-key movements into one undo step (in both selector and node edit) so you can test how it works. Previously, maybe_done was only used in the item properties dialog (which is planned for elimination btw). _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 1

Re: [Inkscape-devel] max undo
by bulia byak 10 Dec '03

10 Dec '03

>Realistically, are users ever going to backtrack through more than ~300 >levels of undo anyway? Easy :) Real drawing sessions may span hours and hours. Right now, however, a crash is a more likely outcome of being in Inkscape for too long, but in the future... My opinion is that a vector app must have unlimited undo, or at least very large. It's the promise of the vector: everything is preserved, no loss of information. Unlimited undo is part of that appeal. One thing: right now subsequent arrow-key movements are stored as separate undo steps. I'd like to combine all adjacent moves in one direction (only horizontal or only vertical) in one step. Is there already a mechanism for that, or do I have to dig into the undo system to implement it? _________________________________________________________________ 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…

6 11

Counting Lines
by Ted Gould 10 Dec '03

10 Dec '03

Hey, Bryce asked for this, but I thought it might be useful for other people too. There is a little utility on this page called 'lc' which counts lines. There are others too, but I've only used lc. Just so everyone doesn't have to do it, I ran it on the Inkscape codebase and threw it into the attached Gnumeric file ;) http://www.chris-lott.org/resources/cmetrics/ --Ted

1 0

Inkscape 0.36 pre-release 1
by Bryce Harrington 09 Dec '03

09 Dec '03

A pre-release version of Inkscape is available for review and testing in source and RPM forms here: http://sourceforge.net/project/showfiles.php?group_id=93438 Please download, test out, and report any significant problems you encounter to the Inkscape bug tracker. We anticipate releasing 0.36 soon, unless any show-stopper bugs (such as frequent crashes) are discovered. Thanks, Bryce

1 0

Re: Map Symbols [was Re: [Sodipodi-list] Getting lines straight]
by Jonathan Phillips 09 Dec '03

09 Dec '03

Maybe a novel idea would be to make separate project on sourceforge that is svg clipart. Like svg-clipart.sf.net would be great. The benefits would be open source designing of symbols, maps, etc for the SVG-compliant community. It might also be nice to push the artwork developed via different SVG apps to a standard, well defined place that might promote interoperability and compliance of all,or many :) ofthe different SVG drawing programs. It would be totally cool to use CVS to design with and allow ppl. from all over the world to work on designs. Thoughts? (I hope I haven't just gotten a little too utopian) Jon On Fri, 2003-12-05 at 07:03, Pat Suwalski wrote: > Áki G. Karlsson wrote: > > Hi > > > > I would be more than happy to participate in a svg map symbols project, > > contributing images like below that are most relevant for my present > > work... > > > > I am just worrying that maybe the sodipodi list doesn't want to be > > subjected to it and that it would perhaps be better served as, say, a > > part of wikitravel... > > Should I be starting a "map symbols" clipart section on the sodipodi web > site? > > Right now, I'm still a little fazed by the whole sodipodi.com thing. > > --Pat > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Sodipodi-list mailing list > Sodipodi-list(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sodipodi-list -- Jon Phillips UCSD Graduate Researcher Computational Media PO BOX 948667 La Jolla, Ca 92037 858.361.2811 www.protofunk.org jon@...15...

8 14

max undo
by bulia byak 09 Dec '03

09 Dec '03

I have increased max undo from 128 to 512, as 128 was way too low imho. In the next version it will be in preferences, but 512 may be the default. Any objections? And by the way, has anyone tried my 256x max zoom patch? _________________________________________________________________ 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…

7 6

text tool news
by bulia byak 09 Dec '03

09 Dec '03

* src/sp-text.c: fixed typing non-ascii chars; copied (with fixes) treatment of xml:space from sodipodi 0.33 * src/sp-text.h: small fix from sodipodi 0.33 * src/text-context.c: copied sp_text_context_preedit_reset and related code from sodipodi 0.33; xml:space='preserve' is added to newly created text objects; esc deselects; uncatched keys are passed on; misc fixes Please test the text tool thoroughly! What I did NOT copy from sodipodi is the new code within #ifdef SP_TEXT_NEW_CONTENT (no idea what it is, it's off by default) and the pervasive change by which SPObject now has "children" but SPText has not, so all text->children were replaced by much uglier ((SPObject *) text)->children. _________________________________________________________________ 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

xml:space default?
by bulia byak 09 Dec '03

09 Dec '03

As a result of my and mental's copying code from sodipodi, now it's possible to set xml:space=preserve via xml editor on a tspan, and the multiple adjacent spaces will not be combined into one as they are now. Does anyone else think it might be a good idea to add this attribute by default to all newly created text objects? BTW this would fix this bug: https://sourceforge.net/tracker/index.php?func=detail&aid=851005&group_id=9… _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoi…

2 1

RE: [Inkscape-devel] non-ASCII chars
by bulia byak 09 Dec '03

09 Dec '03

On the other hand, why do we have to guard against any control chars at all? If we get a string in UTF8, suffices it to check that it's valid UTF8, and complain if it's not. If it is valid, we can insert it without any further checks. Any objections? >From: "bulia byak" <archiver_1@...19...> >To: inkscape-devel(a)lists.sourceforge.net >Subject: RE: [Inkscape-devel] non-ASCII chars >Date: Tue, 09 Dec 2003 06:09:38 +0000 > >OK, I solved this one. Indeed the problem was gchar (i.e. signed) - which >was treated as less-than-zero when it run into this stupid bit of code: > >if ((spnew[i] < 32) && ((spnew[i] != 9) && (spnew[i] != 10) && (spnew[i] != >13))) spnew[i] = 32; > >which was meant to replace control chars with spaces, but ended up >replacing all non-ascii chars with spaces when used with gchar instead of >guchar. > >I'll now rewrite this brain damage properly, using g_unichar_iscntrl(). > > >>From: "bulia byak" <archiver_1@...19...> >>To: inkscape-devel(a)lists.sourceforge.net >>Subject: [Inkscape-devel] non-ASCII chars >>Date: Tue, 09 Dec 2003 05:36:50 +0000 >> >>I have merged the interesting parts of 0.33's sp-text.c and >>text-context.c, but this did not help with the cyrillic chars being >>untypeable. I started to dig into this specifically and now I have a >>strong suspicion that the culprit is the inkscape's change from guchar to >>gchar in functions that insert new chars into the string as they are >>typed. I cannot test it quickly because it requires changing in lots of >>places (and they cannot be simply cast, at least not with g++), but this >>seems likely. For example sp_text_insert used to receive the char to >>insert as a guchar, but now it gets gchar. As it is supposed to be in >>UTF8, perhaps the encoding goes wrong and the result is the space >>characters in the string (or at least something that looks like spaces). >> >>So: >> >>- Does anyone else think that guchar/gchar replacement could break this? >> >>- Why was this replacement necessary in the first place? >> >>- Is it OK if I reverse it in the text code? >> >>_________________________________________________________________ >>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… >> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: SF.net Giveback Program. >>Does SourceForge.net help you be more productive? Does it >>help you create better code? SHARE THE LOVE, and help us help >>YOU! Click Here: http://sourceforge.net/donate/ >>_______________________________________________ >>Inkscape-devel mailing list >>Inkscape-devel(a)lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/inkscape-devel > >_________________________________________________________________ >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… > > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >Does SourceForge.net help you be more productive? Does it >help you create better code? SHARE THE LOVE, and help us help >YOU! Click Here: http://sourceforge.net/donate/ >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel _________________________________________________________________ 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] non-ASCII chars
by bulia byak 09 Dec '03

09 Dec '03

>On Tue, 2003-12-09 at 01:26, bulia byak wrote: > > On the other hand, why do we have to guard against any control chars at >all? > > If we get a string in UTF8, suffices it to check that it's valid UTF8, >and > > complain if it's not. If it is valid, we can insert it without any >further > > checks. Any objections? > >Well, define "complains"? Issue a g_warning and insert nothing. Actually this cannot happen unless there's a bug somewhere else. _________________________________________________________________ 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

sodipodi diff
by bulia byak 09 Dec '03

09 Dec '03

(sorry my gaim keeps segfaulting, no idea why, never used it before... email is more reliable anyway :) I did a diff between the hydra branch and Sodipodi 0.33 (only /src). It's 450Kb so I cannot even put it on the tracker - maybe put into CVS? Where's the best place? Anyway, I would propose that everyone would review the diff and delete those parts that are already in Inkscape, or those that make to sense, or are already resimplemented differently, etc. Anything worth transferring should be transferred (and then deleted from the diff). Hopefully we can thus eventually reduce it to zero. I have already removed some small things that I copied to Inkscape. What I'd like to discuss is this: - arikkei_* functions are now used extensively all over the codebase, for things like number to string conversions. Are they worth borrowing? What are their advantages compared to atoi and snprintf used before? - Sodipodi 0.33 can type Cyrillic characters in the text tool. Inkscape cannot. Sodipodi also can display fancy chars such as em-dash (ctrl-u 2014), Inkscape cannot. I think this is due to all the Unicode new stuff in 0.33. We must have this too. Unfortunately it's quite big and complex and I'm not sure I can transfer this correctly. Any takers? - The "duplicate" checkbox in transformation dialog is nice. It looks simple so I will transfer it (after 0.36 release). _________________________________________________________________ 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 9

RE: [Inkscape-devel] non-ASCII chars
by bulia byak 09 Dec '03

09 Dec '03

OK, I solved this one. Indeed the problem was gchar (i.e. signed) - which was treated as less-than-zero when it run into this stupid bit of code: if ((spnew[i] < 32) && ((spnew[i] != 9) && (spnew[i] != 10) && (spnew[i] != 13))) spnew[i] = 32; which was meant to replace control chars with spaces, but ended up replacing all non-ascii chars with spaces when used with gchar instead of guchar. I'll now rewrite this brain damage properly, using g_unichar_iscntrl(). >From: "bulia byak" <archiver_1@...19...> >To: inkscape-devel(a)lists.sourceforge.net >Subject: [Inkscape-devel] non-ASCII chars >Date: Tue, 09 Dec 2003 05:36:50 +0000 > >I have merged the interesting parts of 0.33's sp-text.c and text-context.c, >but this did not help with the cyrillic chars being untypeable. I started >to dig into this specifically and now I have a strong suspicion that the >culprit is the inkscape's change from guchar to gchar in functions that >insert new chars into the string as they are typed. I cannot test it >quickly because it requires changing in lots of places (and they cannot be >simply cast, at least not with g++), but this seems likely. For example >sp_text_insert used to receive the char to insert as a guchar, but now it >gets gchar. As it is supposed to be in UTF8, perhaps the encoding goes >wrong and the result is the space characters in the string (or at least >something that looks like spaces). > >So: > >- Does anyone else think that guchar/gchar replacement could break this? > >- Why was this replacement necessary in the first place? > >- Is it OK if I reverse it in the text code? > >_________________________________________________________________ >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… > > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >Does SourceForge.net help you be more productive? Does it >help you create better code? SHARE THE LOVE, and help us help >YOU! Click Here: http://sourceforge.net/donate/ >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel _________________________________________________________________ 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…

1 0

RE: [Inkscape-devel] unlimited undo
by bulia byak 09 Dec '03

09 Dec '03

>Okay, unlimited undo is now in CVS. I've added that to the release notes - please check if it's correct. _________________________________________________________________ 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…

1 0

non-ASCII chars
by bulia byak 09 Dec '03

09 Dec '03

I have merged the interesting parts of 0.33's sp-text.c and text-context.c, but this did not help with the cyrillic chars being untypeable. I started to dig into this specifically and now I have a strong suspicion that the culprit is the inkscape's change from guchar to gchar in functions that insert new chars into the string as they are typed. I cannot test it quickly because it requires changing in lots of places (and they cannot be simply cast, at least not with g++), but this seems likely. For example sp_text_insert used to receive the char to insert as a guchar, but now it gets gchar. As it is supposed to be in UTF8, perhaps the encoding goes wrong and the result is the space characters in the string (or at least something that looks like spaces). So: - Does anyone else think that guchar/gchar replacement could break this? - Why was this replacement necessary in the first place? - Is it OK if I reverse it in the text code? _________________________________________________________________ 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…

1 0

unlimited undo
by MenTaLguY 09 Dec '03

09 Dec '03

Okay, unlimited undo is now in CVS. It's always kind of cool when you add a new feature by _deleting_ code. ^_^ -mental

1 0

button.c again
by bulia byak 09 Dec '03

09 Dec '03

So what's the resolution with button.c? I still cannot compile it, now with one more error: button.c:62: error: invalid conversion from `void (*)(SPAction*, int, void*)' to `void (*)(SPAction*, unsigned int, void*)' button.c: In function `void sp_button_toggle_set_down(SPButton*, int)': button.c:189: error: invalid conversion from `void (*)()' to `void*' button.c:191: error: invalid conversion from `void (*)()' to `void*' _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 1

Re: [Inkscape-devel] sodipodi diff
by bulia byak 09 Dec '03

09 Dec '03

>>I can at least have a look at it... I think as part of the merge it >>might be important to understand why it doesn't currently work, too. >> >> > >I can lend a hand looking into this a little. Though it's been ages since >I've done MSVC stuff here, I have worked in i18n on and off for the past 10 >years. That would be fantastic! This is an important issue, as it makes the program almost useless unless you only do English-language art. We must get it right. Fortunately, it may be that the Unicode fonts stuff is not relevant to the issue. This is because I can actually type cyrillic (or paste fancy chars from other programs) into the text dialog, and when applied, it is properly displayed on the canvas. This may mean that only the text tool is somehow broken, but font display works right. I will look into it but I would welcome anyone's help too. I've filed a detailed bug so we don't forget about this: https://sourceforge.net/tracker/index.php?func=detail&aid=856528&group_id=9… It would be very nice to have this fixed before the release. _________________________________________________________________ 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…

2 1

reduce, reuse, recycle
by Jonathan Phillips 09 Dec '03

09 Dec '03

In terms of getting ready for the 0.36 release of Inkscape, what do you all think about commenting out a few unimplemented features. IMO I think we should comment out: print preview (in the file menu) about modules (in the help menu) No use in confusing the new users. Jon -- Jonathan Phillips <jon@...15...>

3 3

Re: [Inkscape-devel] Ruler issues
by Michael D. Seymour 08 Dec '03

08 Dec '03

On Mon, 2003-12-08 at 13:28, Alan Horkan wrote: > > 2) The markings used in the ruler gradations aren't anti-aliased. It > > looks like Inkscape uses some sort of customized GTK ruler. > > > > One should note that the GTKRuler class is being moved out of GTK+ > > because it's too specialized/little-used. One would think that just > > Huh? > Dia, Abiword, Gimp, Sodipodi and I'm sure plenty more use rulers. That's my argument as well. > Maybe not enough projects are using the GTKRuler specifically, and when > you say moved, where to? what happens to programs that used it? Have no idea. The comment was in the GTKRuler entry in the GTK documentation: http://developer.gnome.org/doc/API/2.0/gtk/GtkRuler.html "NOTE this widget is considered too specialized/little-used for GTK+, and will in the future be moved to some other package. If your application needs this widget, feel free to use it, as the widget does work and is useful in some applications; it's just not of general interest. However, we are not accepting new features for the widget, and it will eventually move out of the GTK+ distribution." > - Alan -- Michael D. Seymour "Data is not the plural of anecdote" e-mail: michael_d_seymour@...93... -- Robert L. Park web: http://www.astro.queensu.ca/~seymour/

1 0

Re: [Inkscape-devel] button size
by bulia byak 08 Dec '03

08 Dec '03

> See what y'all think... I think the size contrast may be a bit more pronounced. However, making secondary buttons smaller is bad, they're hardly visible already. Especially the raise/lower buttons are hard to decipher, they're too complex and dark, perhaps someone will have to redraw them eventually. The main toolbar buttons may be made a bit larger, IMHO. Also, can we rearrange the toolbars so that the corner is occupied by the secondary toolbar, not the primary? Rationale: secondary toolbar may ultimately need lots of space for all its controls, so every pixel counts. The primary, on the other hand, is unlikely to grow significantly. And if you do that, can you provide a bit of separation between the toolbars by moving the primary one to the bottom a little? Ultimately I would like to see in that interval a "handle" that will let me drag the toolbar e.g. to the right edge or make it floatable, but until then, let it be just a few pixels of empty space. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

6 7

RE: [Inkscape-devel] sodipodi diff
by bulia byak 08 Dec '03

08 Dec '03

The diff is uploaded to inkscape_web cvs module as /misc/diff33.diff _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

5 6

Inkscape 0.36-pre1
by Ted Gould 08 Dec '03

08 Dec '03

There are files on Sourceforge: http://sourceforge.net/project/showfiles.php?group_id=93438 This is aimed at being an incremental build up to the final release. All of the bugs that are in the roadmap are currently fixed, with some more in the tracker. If anyone has any bugs that restrict Inkscape from being usable - this is a good time to bring them up. Also, there is work on the release notes for 0.36. The last ones weren't very good, so this time we're planning ahead so they are reasonable. If you have contributed code or bug fixes or anything to Inkscape between 0.35 and 0.36 make sure your contribution is in the Release notes. We don't want anyone's contributions to be left out. Wiki page: http://www.inkscape.org/cgi-bin/wiki.pl?ReleaseNotes I'm very excited about the 0.36 release - I hope everyone gets a chance to try this build out so that we can make it even better. --Ted

1 0

[Fwd: Re: button.c]
by MenTaLguY 08 Dec '03

08 Dec '03

Has anyone else had difficulty building button.c since I made this change? -----Forwarded Message----- From: MenTaLguY <mental@...3...> To: bulia byak <archiver_1@...19...> Subject: Re: button.c Date: Sun, 07 Dec 2003 19:07:50 -0500 On Sun, 2003-12-07 at 02:32, bulia byak wrote: > Mental, your latest button.c only compiles if I change > > g_signal_handlers_block_by_func (G_OBJECT (button), G_CALLBACK > (sp_button_perform_action), NULL); > gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (button), down); > g_signal_handlers_unblock_by_func (G_OBJECT (button), G_CALLBACK > (sp_button_perform_action), NULL); > > by > > g_signal_handlers_block_by_func (G_OBJECT (button), (void*) G_CALLBACK > (sp_button_perform_action), NULL); > gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (button), down); > g_signal_handlers_unblock_by_func (G_OBJECT (button), (void*) G_CALLBACK > (sp_button_perform_action), NULL); > > Is that the right fix? No. Casting a function pointer to a normal pointer isn't safe or portable -- you can get away with it on x86, but on many architectures (like e.g. Itanium), a function pointer is really a much larger "function descriptor" datatype. Actually, this should compile as-is (it did compile for me), so it's something funky with one of our build configurations (not sure whose yet). I'm using gcc 3.3.2 with CFLAGS="-g -Wall", and building with glib 2.2.3. What compiler, compiler options, and version of GLib are you using, and what error(s) do you get when you try to compile? -mental

3 5

Ruler issues
by Michael D. Seymour 08 Dec '03

08 Dec '03

This will get submitted as a bug, but I believe it warrants discussion. 1) It seems the ruler co-ordiante system is flipped in the y-axis w.r.t. the SVG co-ordinate system. The rulers have their origin on the bottom left of the given viewport, and the co-ordinates increase up and to the right. This goes against the SVG spec, which states that the origin of the viewport is on the top left, and co-ordinates increase to the right and down. When creating a rectangle and manually specifying the (x,y) = (0,0), the top left corner is placed at the top left of the viewport. Odd that nobody noticed this earlier. 2) The markings used in the ruler gradations aren't anti-aliased. It looks like Inkscape uses some sort of customized GTK ruler. One should note that the GTKRuler class is being moved out of GTK+ because it's too specialized/little-used. One would think that just about any drawing/display app needing co-ordinates in its display canvas would use them. -- Michael D. Seymour "Data is not the plural of anecdote" tel: (416) 545-1060 -- Robert L. Park e-mail: michael_d_seymour@...93... web: http://www.astro.queensu.ca/~seymour/

1 0

Re: [Inkscape-devel] docked toolbar steals focus
by bulia byak 08 Dec '03

08 Dec '03

>Ick. > >To be honest I still don't totally understand how events are handed off >to event contexts in Sodipodi/Inkscape. :/ Neither do I. But you have much better overall knowledge of the program's innards. I start to feel that this problem is not for me :( I'll keep poking but... _________________________________________________________________ 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…

1 0

Re: [Inkscape-devel] [Fwd: Re: button.c]
by bulia byak 08 Dec '03

08 Dec '03

>On Sun, 7 Dec 2003, MenTaLguY wrote: > > Has anyone else had difficulty building button.c since I made this > > change? Here's what I see: button.c: In function `void sp_button_toggle_set_down(SPButton*, int)': button.c:189: error: invalid conversion from `void (*)()' to `void*' button.c:191: error: invalid conversion from `void (*)()' to `void*' $ gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java,pascal --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk) Glib is 2.3.2 as far as I can see. _________________________________________________________________ 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

node edit news
by bulia byak 08 Dec '03

08 Dec '03

(Sorry if this comes in several copies, I'm having trouble sending to the list) I just did a temporary hack: now sp_document_undo emits the selection_changed signal. The node editor catches it and redraws the path. This fixes bug 848355 for now. As an unwanted side effect, selected nodes are deselected after an undo. A better solution would require figuring out what's up with selection_modified signal and using it instead (see my previous mail - attached below). On the bright side, today I implemented duplicate node in node editor (shift-d). As a regular duplicate object (ctrl-d), it places the new node(s) exactly over the previously selected ones (and selects the new node(s) instead). By using together with Tab and Ctrl-a, this makes possible some nice keyboard-only effects. Here are some ideas for eyecandy screenshots for 0.36: - create a filled star with about 30 rays, press ctrl-shift-c, F2, ctrl-a, shift-d, some arrow keys (maybe with shift).... - create a spiral with about 30 revolutions, ctrl-shift-c, F2, ctrl-a, shift-d, some arrow keys... Also, I fixed shift-b (break nodes) so that it breaks all selected nodes and only selects one end of each break (previously it selected both ends). So you can add more fun to the above examples by pressing shift-b, some arrow keys, then ctrl-a again, shift-d, more arrow keys, etc. More usefully, this allows to easily "draw" with keyboard. Use tab to move to the end node of an unclosed path and go like this: shift-d, arrows, shift-d, more arrows, etc. It's an easy way to create rectangular shapes, very useful for diagrams. So what remains in node editor is implementing the []<> keys to edit control points, and voila - a totally keyboard-driven path editor! Something I've dreamed about for long, but did not see to date in any vector editor. P.S. Looks like my previous mail was lost, here it goes: Does anyone have an idea why sp_selection_idle_handler in selection.c is constantly emitting the "selection modified" signal - even two signals, one on the selection and the other on the inkscape object??? There is indeed a constant flood of these signals even when absolutely nothing is happening, not even a mouse move. Is this by design? I'm sure there must be a better way. I was investigating why undo and XML-editor changes in node edit do not work, and found that nodepath context lacks any callback that would update the path when its repr has changed. I tried to hook it up to the "modified" signal but that rendered the program unusable because that signal is "always on" like white noise. Can someone share any insights? It seems to me that something is seriously broken here. I think that it's the repr subsystem that must issue a signal when the document is changed, but that subsystem apparently emits no signals whatsoever. _________________________________________________________________ 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

3 3

Re: [Inkscape-devel] docked toolbar steals focus
by bulia byak 08 Dec '03

08 Dec '03

> > >Grabbing focus between widgets is accomplished via > > >gtk_widget_grab_focus(). The widget will need to have the >GTK_CAN_FOCUS > > >flag set, however. (we should probably do this for the canvas) > > > > OK, I'll investigate the grabs mechanism. Maybe if the fix is simple it >will > > go into this version. > >I've taken care of the latter half in desktop.c now (setting the >CAN_FOCUS widget flag). > >I guess what remains is just determining when it would be appropriate to >call gtk_widget_grab_focus() on the canvas widget. I cannot make it work. I added gtk_widget_grab_focus (&(dtw->canvas->widget)); into sp_desktop_widget_new in desktop.c. For debugging, I also added gtk_signal_connect (GTK_OBJECT (&(dtw->canvas->widget)), "event", GTK_SIGNAL_FUNC (sp_canvas_event_handler), &(dtw->canvas->widget)); and put some debug output into sp_canvas_event_handler. With or without the grab, it looks like the canvas widget gets keypresses, but does not pass them on to the event context. That is, it does pass it to the event context but only when the mouse is within the canvas. Maybe we need to grab focus on the event context, not on the canvas? But how to do that? I think the event context is not a GTK widget. _________________________________________________________________ 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

2 2

RE: [Inkscape-devel] Gtk Buttons
by bulia byak 07 Dec '03

07 Dec '03

Also a question: if we want to restore the drop-down button lists for some tools, as were used for e.g. shape tools in SP, can we do that with the standard widget? >From: MenTaLguY <mental@...3...> >To: Inkscape ML <inkscape-devel(a)lists.sourceforge.net> >Subject: [Inkscape-devel] Gtk Buttons >Date: Sat, 06 Dec 2003 01:30:33 -0500 > >It turns out that SPIcons weren't equipped to deal gracefully with >situations where they were allocated less space than they were >requested. I fixed this, as well as adjusting the buttons' requested >size slightly. > >While I was mucking around in there, I also removed the code that drew >random garbage in icons that weren't present (it turns out to have been >a deliberate decision in Sodipodi). > >Anyway, CVS HEAD now has standard Gtk buttons. > >-mental ><< signature.asc >> _________________________________________________________________ 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…

4 3

docs/keybindings.txt
by bulia byak 07 Dec '03

07 Dec '03

That file is old. Can we set it up so that it's automatically updated from the KeyboardShortcuts wiki page? It's where I keep all shortcuts up-to-date, and it's much better categorized too. _________________________________________________________________ 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

RE: [Inkscape-devel] Marker screenshots
by bulia byak 07 Dec '03

07 Dec '03

>I put a screenshot and example svg of path arrowheads / markers on the >website... Markers are good, but have you seen my message "node edit news" with screenshots suggestions? I'd like to see them implemented instead of the second screenshot with stars. Sodipodi can do stars, too - but we need to show something only we can do :) _________________________________________________________________ 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

button.c
by bulia byak 07 Dec '03

07 Dec '03

Mental, your latest button.c only compiles if I change g_signal_handlers_block_by_func (G_OBJECT (button), G_CALLBACK (sp_button_perform_action), NULL); gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (button), down); g_signal_handlers_unblock_by_func (G_OBJECT (button), G_CALLBACK (sp_button_perform_action), NULL); by g_signal_handlers_block_by_func (G_OBJECT (button), (void*) G_CALLBACK (sp_button_perform_action), NULL); gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (button), down); g_signal_handlers_unblock_by_func (G_OBJECT (button), (void*) G_CALLBACK (sp_button_perform_action), NULL); Is that the right fix? _________________________________________________________________ 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

Marker screenshots
by Bryce Harrington 07 Dec '03

07 Dec '03

I put a screenshot and example svg of path arrowheads / markers on the website... http://www.inkscape.org/screenshots/ Bryce

1 0

[Fwd: [Sodipodi-list] [Fwd: Sodipodi bug 758775]]
by MenTaLguY 07 Dec '03

07 Dec '03

-----Forwarded Message----- From: John Stracke <francis+keyword+sodipodi.6389c0@...99...> To: Sodipodi <sodipodi-list(a)lists.sourceforge.net> Subject: [Sodipodi-list] [Fwd: Sodipodi bug 758775] Date: Sat, 06 Dec 2003 12:00:29 -0500 (I sent this to Lauris at first, but maybe he's been too busy with the 0.33 release. Anybody else have commit access?) I've just uploaded a patch for sodipodi bug #758775 (the one about export bounding box not considering stroke width). It's not complete (it doesn't do text, and it's overeager--it takes the view that it's better to err in the direction of including extra blank space than to cut off some of the diagram), but I believe it's solid enough and useful enough to check in. https://sourceforge.net/tracker/?func=detail&atid=104054&aid=758775&group_i…

1 0

RE: [Inkscape-devel] Bug priorities
by bulia byak 07 Dec '03

07 Dec '03

850971: dupe of 840375 _________________________________________________________________ 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

[Fwd: [Sodipodi-list] [Fwd: Sodipodi bug 758775]]
by Jonathan Phillips 06 Dec '03

06 Dec '03

we have this problem too...its in our bug tracker... any takers... jon -----Forwarded Message----- From: John Stracke <francis+keyword+sodipodi.6389c0@...99...> To: Sodipodi <sodipodi-list(a)lists.sourceforge.net> Subject: [Sodipodi-list] [Fwd: Sodipodi bug 758775] Date: Sat, 06 Dec 2003 12:00:29 -0500 (I sent this to Lauris at first, but maybe he's been too busy with the 0.33 release. Anybody else have commit access?) I've just uploaded a patch for sodipodi bug #758775 (the one about export bounding box not considering stroke width). It's not complete (it doesn't do text, and it's overeager--it takes the view that it's better to err in the direction of including extra blank space than to cut off some of the diagram), but I believe it's solid enough and useful enough to check in. https://sourceforge.net/tracker/?func=detail&atid=104054&aid=758775&group_i… -- Jonathan Phillips <jon@...15...>

4 4

RE: [Inkscape-devel] Bug priorities
by bulia byak 06 Dec '03

06 Dec '03

842565 - fixed, please test and close bug 846963 - I think is fixed too 848355 - fixed temporarily, a better fix needs more work, but the bug may be closed because 852973 stays, and the better fix will have to fix them both 842564 - I would mark this "feature not a bug" 843123 - fixed 848694 - again feature not a bug, a discussion is on wiki (see CurrentColorWidget) 842627 - I cannot reproduce, anyone else? 853858 - this is what we discussed recently about copying <defs>, I think it's unlikely to be fixed before the release _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoi…

2 1

Re: [Inkscape-devel] docked toolbar steals focus
by bulia byak 06 Dec '03

06 Dec '03

> > So the toolbar steals focus and won't let it go no matter how you try. >Since > > this involves moving focus not between windows but between widgets, I'm >not > > sure how to address this. > >Well, this basically arises as the buttons (by default) are set up to >accept keyboard focus on click, but the canvas widget is not. > >The toolbar buttons should probably not accept keyboard focus, though, >as they (almost) all have keyboard shortcuts anyway. I have fixed that >much in CVS. Yes, this problem is gone today - thanks a lot! >Grabbing focus between widgets is accomplished via >gtk_widget_grab_focus(). The widget will need to have the GTK_CAN_FOCUS >flag set, however. (we should probably do this for the canvas) OK, I'll investigate the grabs mechanism. Maybe if the fix is simple it will go into this version. http://sourceforge.net/tracker/index.php?func=detail&aid=854425&group_id=93… > > > > (see my comment at bottom). Basically we need all buttons to give focus >to > > the canvas at once, and all text fields must do the same on esc or enter > > (and not grab focus until you explicitly click on them). > >Well, in the case of dialogs we at least want basic standard navigation >keys like e.g. tab to advance focus to work, as well as accomodate any >IMs that might be active. With dialogs, keyboard focus now works more or less as it should: you can keyboard-navigate within a dialog, and Enter or Esc leave it. When we'll have spinbuttons and textfields in the aux toolbar, we'll need to make sure they behave consistently (tab for moving between widgets, esc to send focus to canvas, enter to set the value and send focus to canvas) and never grab focus unless clicked (or unless activated by a shortcut). As for shortcuts, I propose this: - all top-level menus must have hot-keys and be activated by alt-hotkey, e.g. alt-f must open the File menu - all text labels next to spinbuttons and textfields in the aux toolbars must also have hotkeys (underscored letters), and: -- either we make sure that these hotkeys never clash with the top menu hotkeys, and both are called by alt-hotkey -- or we can use independent hotkeys for the aux toolbar and use a different modifier (e.g. alt-shift-hotkey) for them Ideas? _________________________________________________________________ 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

Inkscape website above soft quota
by Bryce Harrington 06 Dec '03

06 Dec '03

There is a 100M soft-limit for project files on SourceForge. We're at 124M. 3.4M backup 0 cgi-bin 0 htdocs 9.1M inkscape 544K inkscape_project 106M inkscape_web 296K wiki 4.1M wiki_db 19M inkscape_web/cvs-snap 40M inkscape_web/doc 40M inkscape_web/doxygen 3.3M inkscape_web/inkscape_web 1.8M inkscape_web/magnethead 2.3M inkscape_web/screenshots Perhaps the doxygen files could be trimmed down? Or else maybe we should consider hosting them from another location? Bryce

1 0

Re: [Inkscape-devel] a few bugs I need tested...
by bulia byak 06 Dec '03

06 Dec '03

>I think I tend to prefer having the feature requests end up in Wiki, >since that allows them to be elaborated on, discussed, revised, >etc. which is valuable to do in order to make them implementable, and >that's exactly the sort of thing Wiki's are good for. The RFE tracker >works good as an "inbox" since it gives a consistent way for users to >submit to, along with bugs and patches. I think any small and unconnected requests may go to the tracker, but any larger requests that need discussion, or groups or interrelated requests, must be on wiki under "New features discussion" (hierarchized and categorized if possible). _________________________________________________________________ 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…

1 0

Bug priorities
by Bryce Harrington 06 Dec '03

06 Dec '03

I've gone through the non-prioritized bugs in the SF bug tracker and assigned them priorities of 9, 6, or 3. We should not release until all priority 9 bugs are resolved. We should also seek to close as many of the priority 6 bugs as we can within the time available. Priority 3 bugs can be left until after the release, although many will be quick fixes and would be nice to get resolved. I've assigned a few bugs to people, and would encourage everyone to look through the list for ones they know how to fix, and take them if they're not taken already. There are seven priority 9 bugs, none of which have owners yet. Most have to do with saving/opening, and thus can impact user confidence a great deal. Many of the priority 6 bugs are crashes, and are thus important for that reason, even if they occur infrequently. Bryce

1 0

a few bugs I need tested...
by Jonathan Phillips 06 Dec '03

06 Dec '03

Hello, Well, I've finished transferring as many bugs that still have problem in the most recent build of inkscape-20031203, to the inkscape bug tracker on sf.net. There are still a few I need help with either because I do not know how to test them, or they require win32/mac os X. The ones to check from http://sf.net/projects/sodipodi bug tracker: #642384 Misrendered file -- text not aligned #834520 Crash when using a huge R1/R2 value for star shape #830980 LandScape Printing #768804 Sodi doesn't refresh font list; crashes reading deleted font #751439 UTF8 in font names creates problems Please report back to me which one you looked at and the outcome because I'm trying to keep track of the transfer with a spreadsheet. Also, if the bug still exists, please post the outcome on the bug tracker. Thanks, and after these 5 are looked into, the transfer of bugs is complete. Then we need to hack on them ;) Thanks, Jon -- Jonathan Phillips <jon@...15...>

2 3

Re: [Inkscape-devel] [Fwd: [Sodipodi-list] [Fwd: Sodipodi bug 758775]]
by bulia byak 06 Dec '03

06 Dec '03

> > It's actually not as simple as just taking the stroke width into > > account, either -- when you have mitred corners, they can stick out FAR > > beyond the stroke width. > >Markers too. > > > SVG filters will also make finding the real bounding box increasingly > > interesting, when we implement them. Maybe the renderer subsystem can give us the true bounding box of an object? I think this would make sense. _________________________________________________________________ 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…

2 1

RE: [Inkscape-devel] rotate/scale transformation crash
by bulia byak 06 Dec '03

06 Dec '03

>Draw a line/curve >Bring up transform dialog >Enter a value to rotate or scale >Apply >Apply again. > >This causes a segfault for me. Anyone else? Works for me, no segfault _________________________________________________________________ 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

style.c crash
by bulia byak 06 Dec '03

06 Dec '03

Latest cvs crashes when doing convert to curves, I localized this crash to: /* markers */ p += g_snprintf (p, c + BMAX - p, "marker:%s", from->marker[SP_MARKER_LOC]); p += g_snprintf (p, c + BMAX - p, "marker-start:%s", from->marker[SP_MARKER_LOC_START]); p += g_snprintf (p, c + BMAX - p, "marker-mid:%s", from->marker[SP_MARKER_LOC_MID]); p += g_snprintf (p, c + BMAX - p, "marker-end:%s", from->marker[SP_MARKER_LOC_END]); in style.c. Bryce, I guess this is your recent code, so perhaps you can guess how to fix this. _________________________________________________________________ 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 2