November 2004 - Inkscape Devel

Layers dialog
by Bryce Harrington 20 Nov '04

20 Nov '04

Mental, I've got most of the layer rename dialog thingee set up. Could you put the code needed to rename a layer into the apply() routine in layer-properties.cpp? Bryce

1 0

assert in xml editor
by bulia byak 20 Nov '04

20 Nov '04

Every time I select a node in XML editor, I get (inkscape:14979): GLib-GObject-CRITICAL **: g_value_get_uint: assertion `G_VALUE_HOLDS_UINT (value)' failed Anyone else seeing this?

3 5

test ignore
by vellum 19 Nov '04

19 Nov '04

1 0

slow rendering when zoomed in
by David Christian Berg 19 Nov '04

19 Nov '04

I'm kinda confused, that rendering takes a lot longer, when I zoomed in to a place, while when zoomed out moving objects was quite fast, but well, is not a accurate of course. Any explanation for the really annoying slow down when zoomed in? David

3 4

layer testing
by Gazal, Geraud (GE Healthcare) 19 Nov '04

19 Nov '04

tested with 17-nov-2004 build on win2k, here is a sum up some feedback ? preliminary In Layer1, draw a rectangle Then lock the layer chapter 1 a) toggle to selector tool, try to select the rectangle by clicking on it -> impossible (cool) b) try to select object with click-drag ctrl-click or shift-click -> possible (don't know if it is cool or not...) and try to modify then -> possible (not cool) c) open the XML editor, select the rectangle, go back to canvas, the rectangle is selected and can be modified scaled, filed, transformed... (cool) d) toggle to rectangle tool, try to select the rectangle -> possible (not cool), and the rectangle can be modified toggle again to selector tool -> the rectangle is selected (not cool) and can be modified chapter 2 in the same (locked) layer toggle to any shape tool and try to draw another shape -> possible (don't know if it is cool or not) then toggle to selector tool and try to select them -> same as in chapter 1 -> objects can be selected by click-drag ctrl-click or shift-click, but not by click They can then be modified (transformed, filled, ...) or aligned.... regards, matiphas

5 8

layers and locking
by MenTaLguY 19 Nov '04

19 Nov '04

FWIW, what most people expect from layer locking is just "make this layer safe so I don't accidentally change it (or the objects on it)". After some thought, I think the best set of behaviors are these: * tools capable of selection only select objects if they are visible, unlocked, and all of their parents are unlocked * drawing tools can only draw if the current layer and all its ancestors are visible and unlocked * locking a layer unselects all selected descendants of that layer, but locking an object does not unselect that object Per Peter's suggestion, "locked" may not be the most appropriate label for the per-object locking (since it doesn't render the object immutable, really), although I think "insensitive" is marginally too jargony. Inverting the meaning and labeling it "selectable" might be most appropriate. Layer locking ought to remain called "locking", though, since that is the common and expected term. -mental

3 2

patch tracker > text in shape
by john cliff 19 Nov '04

19 Nov '04

Hi all, Theres a patch in the tracker I'd really like to get in the codebase before 0.40, its a pretty simple bit of code, just wasn't sure on sunday if we were meant to have been in freeze or not so rather than commit it I put it in the tracker (its also pretty much the first thing I've done with the codebase since july, so was feeling a bit rusty, thought a second set of eyes going over it wouldnt hurt) Its a simple right click menu entry for "add text to shape" which creates a flowRoot structure containing clones of the selection. The text itself still erquires editing with the XML editor, but it takes the pain out of trying to create the structure. Just seemed a waste to have the rendering for a feature thats requested so much, but to make it so hard to actually use. Patch number is 1066358. Cheers John

2 1

RE: [Inkscape-devel] layer testing
by Gazal, Geraud (GE Healthcare) 19 Nov '04

19 Nov '04

OK, thanks a lot for the quick reaction and code update. I plan to test again this WE on WinXP, win2k, mdk10.1 (if i manage to build) and debian (ubuntu) Regards, Matiphas > -----Original Message----- > From: MenTaLguY [mailto:mental@...3...] > Sent: vendredi 19 novembre 2004 07:35 > To: bulia byak > Cc: Gazal, Geraud (GE Healthcare); Inkscape ML > Subject: Re: [Inkscape-devel] layer testing > > > On Thu, 2004-11-18 at 23:30, bulia byak wrote: > > > Mental: I now fixed that by traversing the chain of all parents in > > SPItem::isLocked(). Please review this fix. It works but may not be > > optimal. > > I can't think of a better approach. When I realized the > problem earlier > today I was going to do that myself. > > > Perhaps better if you can make it inherited in the setter, > > not getter. > > I wouldn't try that unless the getter was unacceptably slow. > > Currently, the setter is O(1), and the getter (with inheritance) is > O(log n). Doing it the other way around would make the > getter O(1), at > the expense of making the setter O(n), which would suck much worse for > large trees. > > It might not be such a big disadvantage if SVG trees were > typically deep > and narrow, but shallow and broad is the normal case: it's not too > unusual to have e.g. 200 children of a single parent, but > nesting deeper > than 3 or 4 levels is unusual. > > Under those circumstances, traversing upwards (even multiple times) is > much cheaper than recursively visiting all descendants. > > > > chapter 2 > > > in the same (locked) layer toggle to any shape tool and > try to draw > > > another shape > > > -> possible (don't know if it is cool or not) > > > > I think it's not cool but it needs fixing in many places, > so unlikely > > to be ready for the release. > > Hmm. I'd still like to look into it if we could. It's a > pretty visible > bug. > > -mental >

1 0

Re: [Inkscape-devel] "Lock" vs "Sensitive"/"Insensitive"
by Joshua A. Andler 19 Nov '04

19 Nov '04

> On Wed, Nov 17, 2004 at 10:19:12PM -0500, MenTaLguY wrote: > > > We can investigate whether it makes sense to separate them in 0.41, > > but for now we need to fix the tools etc to treat such objects and > > layers as immutable, at least as far as the mouse tools are concerned. > > Brisgeek was saying that offhand he couldn't think of a situation where > he'd want to mark objects as read-only/immutable (other than having the > whole diagram be immutable, as in inkview). > > Brisgeek and other drawing people, can you think a bit more about this? My thought are that if I lock a layer, I shouldn't be able to do anything to that layers' objects until it is unlocked (other than change visibility, which is a layer level option). And my reasoning goes based on experience with other vector drawing apps... essentially it's the expected behavior. > To me (as a non-artist) it doesn't seem very useful to prevent > modification with the mouse tool of already-selected objects, as it's > easy to deselect them if you've just made them insensitve. Whereas it > does seem useful to be able to modify things that you've gone to the > trouble of selecting despite them being insensitive. To tell you the truth, more artists will end up using Inkscape than non-artists. And it is quite useful to be able to know that you can lock a layer, do a rubberband across the canvas to select all objects of my unlocked layers and not have to worry about anything in my locked layer getting selected as well. In Illustrator & Freehand (as well as others) that is the behavior. Also, as I just tested in Illustrator, if you have an object selected and lock the layer it's on, it is automatically deselected (as you can't modify something that is locked). That makes sense to me as well. If I click lock, it's because I'm don't want to edit that layer (or anything on it) and it saves me a click with the having to deselect manually (minor, but functionally it makes sense with how lock works in Illustrator). > I'd note that it's less work for it to mean merely insensitive rather > than insensitive and immutable from mouse tools. I'd suggest that at > least for 0.40, we keep it as meaning merely affecting > canvas-selectability. > > > Most drawing applications combine both behaviors (unselectable and > > immutable) into their notion of "lock". > > We'll keep that in mind, though Inkscape's general policy is that we > should find the most useful behaviour, and let other programs catch up. This, quite honestly, is where the other guys (Adobe, Macromedia, etc) set the standard and people coming over will expect certain things to function in the same way. I'm not saying it's necessarily right, but layers are very important and people will get turned off if they're "broken" in their view. If we separate unselectable and immutable into separate layer-level options it would make sense to all of us geeks. But most artists aren't really geeks and don't want separate functions, it just needs to do what they expect. I guess the best way to explain it, is that a lock is for protection. The best analogy I have for the lock doing both functions is that if you have your front door locked on your house, people shouldn't be able to A) come in and B) rearrange your furniture. But you unlock it and it's all fair game. Basically the object is a house (properties being furniture), and we're the random people. Just my .02 on the layer subject. -Josh

2 1

sp_repr_position() optimization
by MenTaLguY 19 Nov '04

19 Nov '04

I comitted a small optimization for SPReprs tonight; essentially sp_repr_position() and sp_repr_n_children() are now cached in SPReprs. The way it's actually accomplished is with SPRepr::_n_siblings, which is the number of siblings counting from that particular repr (inclusive) to the end of the sibling list. Looking at it from the parent's perspective, SPRepr::_n_siblings of a its first child will == sp_repr_n_children(), and the sp_repr_position() of a specific child will be: ( sp_repr_n_children(parent) - child->_n_siblings ) Normally, only the first child's SPRepr::_n_siblings will be kept up-to-date; there is a boolean flag (SPRepr::_child_counts_complete) in the parent indicating whether the remainder of its children also have up-to-date _n_siblings members. That flag is checked when sp_repr_position() is called, and the children scanned and updated "lazily" at that time if necessary. This permits node addition and removal to remain constant-time activities. The beneficial effect is that sp_repr_n_children() is always constant-time, and all calls but the first to sp_repr_position() are also constant-time. This will be important later for things like the "sort by overall z-order" facility that bulia asked for (we may need it for some finer points of the 0.40 release), as well as Gtk treeview models (which would necessarily heavily query sp_repr_position() to build GtkTreePaths) later. -mental p.s. Note that sp_repr_nth_child() isn't any faster, but I don't think it's necessary to further optimize at this time. p.p.s. _child_counts_complete sucks as a name. any better ideas?

3 4