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
I'd have thought that the main purpose of sodipodi:insensitive (at least as applied to ordinary objects other than layers) is to allow selecting things under the insensitive objects rather than to prevent them from being modified.
I'm not very familiar with using layers in drawings, though I'd have thought that the same would apply to layers, to allow editing lower layers.
Once one has selected an insensitive object somehow (Select All, Find, etc.), I'd guess that one would want to edit it (though I'm not an artist, so ask others). A separate read-only attribute might in some circumstances be useful, though I'd suggest that it not be in 0.40, and I suggest that insensitive is more useful than read-only.
The naming and icons for insensitive is another issue (see "Lock vs Sensitive/Insensitive" thread).
pjrm.
Thanks for this testing.
b) try to select object with click-drag ctrl-click or shift-click -> possible (don't know if it is cool or not...)
I'd say that ctrl-click and shift-click shouldn't select, and am inclined to think drag shouldn't either.
d) toggle to rectangle tool, try to select the rectangle -> possible (not cool)
am inclined to agree
toggle again to selector tool [with the rectangle already selected with the rectangle tool] -> the rectangle is selected (not cool)
I think it's fine for it to remain selected here.
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 this is fine (assuming "locked" actually means insensitive).
pjrm.
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...)
Must be impossible of course. The reason is that arenaitems inherit sensitivity from parents while SPItems do not. Click selection works through arenaitem while most other ways to select work through SPItem. For visibility, inheritance is handled by SPstyle, but sensitivity is not a style property.
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. Perhaps better if you can make it inherited in the setter, not getter.
and try to modify then -> possible (not cool)
Once you manage to select it, it's modifiable as usual. That's OK, so long as insensitivity is honored by all selection methods, taking inheritance into account.
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
That's fixed too
toggle again to selector tool -> the rectangle is selected (not cool) and can be modified
Again, if you manage to select it, you win. You can modify it to your heart's content. Our goal is to prevent you from selecting it :)
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.
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
(replying to own message)
On Fri, 2004-11-19 at 01:34, MenTaLguY wrote:
I wouldn't try that unless the getter was unacceptably slow.
...and the setter really isn't called often. The assumption being that it's more OK for the setter to be very slow than it is for the getter to be very slow.
But since the setter would be exponentially slower than the slow getter, perhaps that still wouldn't be a good tradeoff.
-mental
On Wed, Nov 17, 2004 at 01:56:42PM +0100, Gazal, Geraud (GE Healthcare) wrote:
b) try to select object with click-drag ctrl-click or shift-click -> possible (don't know if it is cool or not...)
brisgeek thought that it would be useful to have some way of selecting insensitive objects (temporarily overriding sodipodi:insensitive). He said he'd never used Alt-select ("select under", i.e. select the second thing in the stack of objects at the click point), so thought Alt-select should be changed to mean "select ignoring sodipodi:insensitive attriutes" (or possibly even inverting the meaning of sodipodi:insensitive if the click point has an insensitive object covered by sensitive objects).
Btw, this was just what arose in conversation after ~a minute's discussion, it isn't the fruit of long reflection.
pjrm.
--- Peter Moulder <Peter.Moulder@...38...> wrote:
On Wed, Nov 17, 2004 at 01:56:42PM +0100, Gazal, Geraud (GE Healthcare) wrote:
b) try to select object with click-drag ctrl-click or shift-click -> possible (don't know if it is cool or not...)
brisgeek thought that it would be useful to have some way of selecting insensitive objects (temporarily overriding sodipodi:insensitive). He said he'd never used Alt-select ("select under", i.e. select the second thing in the stack of objects at the click point)
I use it fairly regularly, very handy when working with multiple levels of transparent objects.
__________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
On Fri, Nov 19, 2004 at 04:42:40AM -0800, John Cliff wrote:
I use [alt-select for `select under'] fairly frequently, very handy when working with multiple levels of transparent objects.
Useful for working with 2-3 levels of transparent objects, maybe not so useful when working with more than that.
pjrm.
participants (5)
-
bulia byak -
Gazal, Geraud (GE Healthcare) -
John Cliff -
MenTaLguY -
Peter Moulder