- Inkscape Devel - Inkscape Mailman

can't compile
by bulia byak 31 Dec '03

31 Dec '03

There's a mismatch in declarations: desktop-snap.h has the last argument of _free_snap as const, but *.cpp has it without const. Please fix one way or the other. _________________________________________________________________ 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…

6 12

SPOffset
by MenTaLguY 30 Dec '03

30 Dec '03

I've been playing with SPOffset today -- great stuff! It has some awesome potential as an artistic tool. That said, there are a few issues that bug me: 1. something's going a bit wonky with the associated NRArenaItem -- an assertion keeps triggering about the object's bounding box. Unfortunately, until I figure out what NRArenaItem::state actually means, I'm not sure of the best way to fix this. 2. I think perhaps Inset/Outset should modify the original path, rather than making a duplicate. Its behavior of duplicating the path and leaving them both selected surprised and frustrated me. 3. I'm not sure the use of xlink:href is really SVG-compliant in this case ... also, the behavior of following the original path was also a little surprising and frustrating, once I managed to get the original path selected without selecting the outset. -mental

3 3

node edit now listens!
by bulia byak 30 Dec '03

30 Dec '03

I finally added repr listener to the node editor, which means it now updates its nodes when an object is modified outside of its control (by undo, in XML editor, in another view etc.) This fixes 857997, 852973, 865627, and re-fixes 848355 properly (previous hack in document_undo is removed). "Works for me" but I'd appreciate if it is tested really thoroughly, as the code is still somewhat flakey. E.g. instead of the closed bug I'm now submitting two other bugs related to the new code which I still need to fix. Any insights are appreciated. Some issues: - When to regenerate the nodepath? Not always when a repr is changed, because the majority of such changes are from the node editor itself. One approach: compare the actual repr with a "fake" repr temporarily created from the current nodepath; if different, recreate nodepath. Another approach: When updating repr from within node editor, set up the local_change flag. The listener checks this flag and if it's set, does not recreate nodepath (but zeroes the flag). Right now my code uses both these approaches, the first for the nodepath and the other for knot_holder (the structure used to edit ellipses, spirals etc). Does anyone have an opinion on which approach is more preferable? - Preserving selection is a hack: before regenerating nodepath, I save the list of the numbers of selected nodes, and then re-select them in the new nodepath. This does not always work (see bug 867525). Can anyone propose a better idea? - Objects within groups: they can be transformed via their group, without their repr being changed at all (see bug 867521). What to do with them? _________________________________________________________________ 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] Nudge control
by bulia byak 29 Dec '03

29 Dec '03

>Ok. I know it's the silly season but can someone tell me where the nudge >control distance setting for the arrow keys is located? I want to control >the distance setting as the current default one is too high. There must a >control surely but I cannot find it. It's not in the UI yet. Maybe in the next version. For now you can change it in your ~/.inkscape/preferences.xml, by setting e.g. <group id="nudgedistance" value="10"/> (the value is in points). >While I'm on nudge I notice that operation of nudge seems a bit erratic on >occasion. Sometimes an object does not nudge with the arrows until it has >been moved manually with the mouse. When it happens none of the arrows >work. >I'll try and document more precisely when it occurs. Most likely the arrows don't work when the mouse is not over the canvas. It's documented here: http://inkscape.org/cgi-bin/wiki.pl?EventContextGrab If the misbehavior you experience is different, please file a detailed bug report. _________________________________________________________________ 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] Ungroup All Command
by bulia byak 29 Dec '03

29 Dec '03

>On Tue, 30 Dec 2003, vellum wrote: > > In the real world of drawing pictures I often group objects and then put > > groups within groups etc sometimes many times over. Commonly I have many > > composite groups floating around. Now, if I need to modify something >buried > > in a composite group it can be a real pain getting back down to it. It >would > > be very useful to have an "Ungroup All" command to complement "Group" >and > > "Ungroup". No, "Ungroup all" is not necessary, Ungroup must simply ungroup _all_ selected groups (now it only works if one group is selected). This way you'll be able to ungroup any nested group(s) down to atoms by pressing ctrl-u sequentially. It's in my todo list already. _________________________________________________________________ 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

Gtkmm
by Daniel Borgmann 29 Dec '03

29 Dec '03

Hello, I have just changed the save confirmation dialog to use Gtkmm. For this to work, I also had to change gtk_init (&argc, (char ***) &argv); to Gtk::Main kit = Gtk::Main(&argc, (char ***) &argv); in main.cpp, otherwise it would crash with lots of "quark" errors. I don't really understand the reasons to be honest, but it seems somewhat logical and it works well. My question is, should I commit this or should the Gtkmm stuff rather happen in a branch? Daniel

4 4

Re: [Inkscape-devel] selection news
by bulia byak 28 Dec '03

28 Dec '03

>On the other hand, you're getting experienced with this code now. Do >you have ideas for how best to make these selected items draggable >directly? Actually it turned out to be quite easy. Please test now. Still, I'd like to hear your opinion on whether it's acceptable to keep extending the item_at_point machinery in select-context as opposed to canvas code. Are we perpetrating ugly hacks, or is this the right way that should have been followed from the start? _________________________________________________________________ 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 2

RE: [Inkscape-devel] RE: offset width modifying
by bulia byak 28 Dec '03

28 Dec '03

> > commit it; otherwise >done Thanks! I will test it. >a note on knot editing of objects: when doing >modifications directly in the xml tree, the knots are >apparently not refreshed (see the spiral and the >sodipodi:t0 attibute for an example). Yes, this is because node context has no listeners for repr changes, it's a cause of several bugs and is described here: http://www.inkscape.org/cgi-bin/wiki.pl?SelectionModifiedSignal It's in my near-term plans to fix this. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

RE: offset width modifying
by bulia byak 28 Dec '03

28 Dec '03

>looking in the inkscape code, seems to me that this >requires the creation of a SPShape derivative, like >the SPSpiral is, and the storing of the path whose >offset is considered as a attribute. i already coded a >working solution with a SPOffset object, and a >sodipodi:original attribute (the width is stored as a >sodipodi:radius), but i dunno what clearance i need to >do such additions: is it OK to add attribute types and >objects classes at will? is there a guide explaining >what behavior is expected for these? Please clarify: As I understand it, you plan to change the current inset/outset menu commands and shortcuts so that: - when applied to an arbitrary shape, they convert it to SPOffset and set some initial offset attribute value, - when applied to an SPOffset, they simply modify its offset attribute and regenerate the visible shape from the same original shape? Is this your plan? If so I think it could work, and would provide a nice solution to the problem of "shape degradation" when in/outset commands are applied multiple times. One problem that I see (but may be you already took care of that): our SVG must always remain renderable, and it must render the same in any other SVG renderers. This means the d="" attribute of the SPOffset object must store the _already offset_ path, not the original path. For storing the original path, you'll need a separate attribute in the inkscape: namespace. Other questions: It would be very nice to be able to edit the _original_ path with the node editor without losing the SPOffset status of the object, i.e. have the visible offset contour to be updated automatically when I edit the nodes of the original contour. Is this possible or if not, do you think it's easy to implement? Also, it would be very nice to be able to convert any other SPShape derivative to an SPOffset without losing its original status. For example, being able to edit a rect (e.g. rounding its corners) and see the outset contour updated at once. And it would be extremely useful to be able to apply SPOffset to text objects without converting them to path first. Is this possible with your current model? Well, even if not (i.e. if node-editing of an SPOffset loses its offset status and original shape, and if SPOffset can only be created from a path), I think it's still useful, so let's try it out. Whether to commit it depends on how disruptive it is; if you didn't change much outside of your domain and don't expect other things to break, go ahead and commit it; otherwise please create a branch for your code (see Wiki for instructions) so we could test it. P.S. Please cc: your replies to the list so that everyone else can participate in the discussion. Also, please add yourself to the AUTHORS file if you didn't already, and please document your changes in the ChangeLog. _________________________________________________________________ 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] selection news
by bulia byak 28 Dec '03

28 Dec '03

>On Sat, 2003-12-27 at 02:31, bulia byak wrote: > > Ctrl-click now selects within groups, ctrl-shift-click adds to selection > > disregarding grouping. Multiple and nested groups work. Special care was > > taken to preven double grouping when both a group and one of its >descendants > > are selected. Please test. > >Good work! > >One thing -- as it is currently, you can select things within a group, >but not e.g. move them around when they are selected -- probably >contrary to user expectations. I thought about that but didn't implement it yet, partially because I myself almost never use dragging to move objects, but only arrow keys (they work within group). This will involve another instance of ignoring the item passed with the event and using the selected-within-group items instead in item_handler. Looks like with this approach, the canvas code which does its own item picking will be eventually left unemployed. I don't know if it's good or bad from the architectural viewpoint, but at least my own way of fiddling with items is much easier to implement for me than any changes to the canvas code, so I tend to choose the easy route. >I guess this means the next phase of my layers work just became more >important -- making groups that have selected children (descendants) >automatically 'transparent' (in the SPArenaGroup sense). Oh yes, if you can do this, then mousedragging selected-within items will be enabled automatically. Perhaps that's a better approach. >On the other hand, you're getting experienced with this code now. Do >you have ideas for how best to make these selected items draggable >directly? I think the code I originally had in mind to do >selection-dependant "event transparency" could get nasty to implement. As outlined above, I think I can basically re-implement most if not all of selector's functionality using my own item_at_point functions and their variants, disregarding the item argument of the event. This is one approach; the other is your changes to canvas code to make partially-selected groups auto-transparent. As to which one is easier, I don't know; I can try to do the first one but I have very little idea of how difficult is the second for you (it's likely to be very difficult _for me_). _________________________________________________________________ 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