On Mon, 2008-06-30 at 22:13 -0300, bulia byak wrote:
Since this thing is helper display, i.e. not an object in a document, you create a CanvasItem for it. There are several kinds of them, what you need for this is CtrlRect in display/sodipodi-ctrlrect.cpp. It is used for example for the rubberband and selection rectangle. You can set the fill color and opacity level for such a rect. You can't make a hole in it, though, so you probably need to manage 4 such rects to surround the letter box; it may be a good idea to create a new kind of canvasitem for such "mask with hole". Alternatively, you can use display/canvas-bpath.cpp, which can display any path, then you can just make the hole as a subpath, same as in SVG. However the bpath may be slower to render because it uses cairo, whereas ctrlrect just bit-flips the rectangle. I'm not sure the difference would be noticeable, though.
I wouldn't worry about speed yet at this point. Creating a new canvasitem type for "mask with hole" seems like a good idea. For now, just do enough that it can have a rectangular hole and don't make it overcomplicated, but in the future we might extend it to have other kinds of hole.
In addition to that, you will probably need to lock all objects other that the glyph you're editing. Since the glyph will be in defs, you just need to temporarily lock all regular layers. This is easy to do with item->setLocked, but the problem is that this must not be permanent locking that gets written to SVG - when you quit and reload the file, it must have its layers in the original locked/unlocked state. Mental, can you suggest a solution to this?
Well, we definitely *don't* want to be locking things at the SPItem level and then having to "fix up" SVG data to hide that fact. Ideally it should be a strictly canvas-level or arena-level thing.
I think we may need to back up and do a redesign of the way click sensitivity/canvas picking is handled. It's likely to be less work than the gymnastics required to hack something this up with the current approach.
My current idea is to have each arena object carry with it a set of "pick flags", some of which are defined to make an arena item eligible for picking, and some of which are defined to definitively exclude both an item and its descendants from being picked.
Rather than having a single "transparent" flag, we could then have at least two flags: "simple object" (which makes an object eligible for picking), and "locked" (which excludes an object and its descendants from picking).
Normal arena items would have "simple object" set, but layer arena items would not, so that a pick would not consider a layer, but would still examine any eligible descendants.
Any locked arena item would simply have the "locked" flag set, excluding it and any descendants from picking even if they'd otherwise be eligible. This approach would remove the present need to recursively set/clear "transparent" flags on lock/unlock transitions.
How this scheme would be applied to "<defs> editing" depends a great deal on where the <defs> object's arena items are to be put in the arena item tree. Probably we would set additional flags on a few key arena items and possibly modulate which flags picking paid attention to.
-mental