Andre Poenitz wrote:
> It is fairly exact as it describes how it works in mathed not outside.
>
> When mathed currently gets a click, the cursor is positioned as close as
> possible and the event is passed up along the cursor path until some inset
> is willing to handle it.
I'm confused now in your former mail you said it works from the
innermost one to the outermost and now you are telling me that it's
exactly the opposite.
> Yes, that's exactly the opposite as it works outside but that means that
> insets only have to be aware of events they want do handle and simply
> ignore the rest, whereas "oustside" every inset has to pass down all
> "unknown events".
I don't understand this claim and I don't believe it. Can you please
explain this for dummies like me and maybe make a real-world example so
that I'm able to follow what you mean.
> I am aware of these problems but I think they are solvable. I have
Well I think most stuff is solvable so we think the same here :)
> pre-alpha code for a \parbox implementation that would exactly do that.
> But this is far from finished, so mathed is currently no replacement for
> InsetText.
\parbox is very different as it too has a "fixed" size doesn't it? What
you have similar in a parbox is that you need to do automatic row
breaking, but still for the outside world the inset will always have a
fixed with, if you don't change it in a layout and then you have to
rebreak it only one time.
> I believe that this was not easy to get right in InsetText and I believe it
> won't be easy to get right in mathed. But there is no evidence that it is
> technically not possible.
Did I say so?
> Bottom up along some iterator which in most cases is the one representing
> the cursor position in *mathcursor.
What happens if you don't have a cursor? I mean what handles if I have
size changes and no cursor inside the mathed inset (think of undo!)
> So the events are handle by the innermost inset as well. I am doing exactly
> the same. The only difference is that enclosing inset does not do anything
> at all if the event is handled by some deeper nested inset. No big deal.
Well that's the same in all insets (see the handle of pre_events in
insettabular), but most events have to pass the innermost InsetText as
we don't know if it wants to handle it or not. We could also in lyxfunc
put some functions before the call to LocalDispatch of the inset, but it
really isn't important as if the inset does not handle the event in time
cosumation it is negligible if we enter there and do nothing or if we
don't, IMO on the other hand we are on the safe side if we enter as we
then are sure the inset does not handle it.
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39050 Steinegg Web: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
