- Inkscape Devel - Inkscape Mailman

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

pre3 needed, status
by bulia byak 19 Nov '04

19 Nov '04

I think we need a pre3 today. Several important fixes went in, and Mrdocs promised to (finally!) make static RPMs for it. Just a precious few things remain to be done before we can enter freeze: 1 add a dialog asking for a name of a new layer to create, with a couple of checkboxes "Make a sublayer" and "Move selection to the new layer" (I think Mental could use help on this one, it's a simple task for someone) 2 fix two crasher bugs: - 1056658 win98: crash on save (msvcrt error box) (JonCruz) - 1059059 crach autopackage 0.4, may be a dupe of 1064399 3 fix the several portability bugs (actually I think mental handled them already) That's the minimum, the more bugs we fix the better. But this minimum is minimal enough already, which is good news. Let's all make one final push.

4 4

Recent error messages
by Joshua A. Andler 19 Nov '04

19 Nov '04

First I've noticed that the log window has been popping up frequently with recent builds... unfortunately I've been really tied up the past week and a half and have only skimmed the lists (so I'm sorry if this has been discussed), anyway since this stuff started it says: ----- (inkscape.exe:2720): Gdk-CRITICAL **: file gdkdraw.c: line 1351 (gdk_drawable_re al_draw_pixbuf): assertion `width >= 0 && height >= 0' failed ----- And it seems to happen if I switch to a different program and then when I pull inkscape back up it spits that out. The really bad thing though is that Inkscape got caught in a loop here this morning. Using the most recent build in the Win32-snap dir, It just kept spewing the following into the log window: ----- (inkscape.exe:952): Gdk-WARNING **: gdkgc-win32.c:935: SaveDC failed: Not enough storage is available to process this command. (inkscape.exe:952): Gdk-WARNING **: gdkdrawable-win32.c:1493: CreateCompatibleDC failed: Not enough storage is available to process this command. (inkscape.exe:952): Gdk-WARNING **: gdkgc-win32.c:1074: RestoreDC failed: The pa rameter is incorrect. ----- Unfortunately I wasn't able to figure out what triggered it. And also I could not control inkscape whatsoever as it would just pull the log window ontop. Anyway, it just continually repeated those 3 lines non-stop until I finally killed it. Any ideas on either one? And on a side note I'll be posting the tracing quick-start in probably an hour or so for review.

5 12

rename layers dialog runtime error
by bulia byak 19 Nov '04

19 Nov '04

(inkscape:599): Gtk-WARNING **: Attempting to add a widget with type gtkmm__GtkHBox to a gtkmm__GtkDialog, but as a GtkBin subclass a gtkmm__GtkDialog can only contain one widget at a time; it already contains a widget of type GtkVBox and the dialog is empty, tiny sized, not modal, and jumps up in the corner of the screen...

1 0

fr.po error
by bulia byak 19 Nov '04

19 Nov '04

I get this when doing make: file=./`echo fr | sed 's,.*/,,'`.gmo \ && rm -f $file && /usr//bin/msgfmt -o $file fr.po fr.po:1:2: parse error fr.po:985:8: invalid multibyte sequence fr.po:1144:59: invalid multibyte sequence /usr//bin/msgfmt: found 3 fatal errors

2 1