Andre Poenitz wrote:
> 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.

Well this seems indeed VERY strange. How would you do that? As much
as I know of the structure BufferView gets the click and delegates
it to the topmost inset, which then delegates it to it's childs if
necessary (click really hit a child). I guess that as you know from
the top-level-inset with your cursor the innermost inset you could
then jump from the outermost to the innermost and then return outside
could you explain a bit better how this works in mathed, as the above
explanation is not really exact, is it ;)

> 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. 

I think here is the real difference between InsetText and Mathed. Mathed
has more or less fixed sizes while the InsetText depending on the 
outside world may have to rebreak it's rows and adapt it's sizes and not 
only it but has to delegate this also to all child insets as they too 
may change sizes. And this was the big difficuly in getting the Inset
in it's now more or less working state and this is also the main problem 
why we still see that nested insets are slower to update the normal 
text. You have a lot more stuff to do for which you don't care in normal 
text.

> 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".

Well this is the same for all inset! I see no difference in the handling
here.

>>I have found the existing inset locking method to be very difficult to
>>understand,
> 
> So have I.

Well maybe I don't see it so because I wrote that code and it seems 
pretty easy to understand to me. For me it's much more difficult to 
understand how mathed does the same stuff and how delegation works 
there. In InsetText I have a top down delegation and then a down top
back tracking. This means that I go to the innermost inset first and if 
that doesn't want to handle the event I return from there always one 
level up till the outermost inset.

             Jug

-- 
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen Vigna        E-Mail:  [EMAIL PROTECTED]
Kravoglstrasse 4        Tel/Fax: +39 0471 564172 -  +39 0471 564122
I-39100 Bozen           Web:     http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Reply via email to