On Wed, Jul 10, 2002 at 04:08:48AM +0100, John Levon wrote: > Actually I was after a description of your architecture, not how you > plan to introduce it. For example, how does it handle a click on a URL > inset inside an note inside a minipage,
Events are handled bottom-up. The most nested inset that claims the ability to handle the event, wins. [Well, currently it's like that only for mouse clicks and hard-wired for things like 'add row to array' but I intend to extend that consistently to all "events"]. So when clicking on a URL in a minipage the URL can handle the click first. > how are redraws that affect containing inset done, Redraw is "always redraw everything" but uses cached sizes of nested stuff. I fiddled a bit with more selective redrawing and it was not too bad except for the macro editing, so I decided to leave it as it is for the time being. I have a gut feeling that this is possible anyway. > how does owner-ownee delegation of things like > checkInsertChar() work etc. I don't really no what checkInsertChar() does ... ok, had a quick look. There are no back references from the ownees to the owner. But as the insertion of a char is handled by the innermost inset that claims to be able to handle the insertion of _a_ char, this inset can check whether it wants to handle _this_ char and e.g. do nothing but return a "I handled this" or do nothing and return a "I do not want to handle this". > I have found the existing inset locking method to be very difficult to > understand, So have I. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
