"Vincent van Ravesteijn - TNW" writes:
> Looking at the AtPoint code I realize that I might have forgotten to
> call cur.undispatched(). Without this call, the lfun is never relayed to
> the current inset after it has been dispatched to the next inset.
Yes, this point is important.
> If this is
"Vincent van Ravesteijn - TNW" writes:
> P.S I'm also annoyed by the difference between dispatch() and
> getStatus(). Namely one of them returns a bool to indicate whether a
> definitive decision has been made, whereas the other uses the
> cur.dispatched_ member.
What I'd like even is to have get
>"Vincent van Ravesteijn - TNW" writes:
>> 1. If we want to use the AtPoint mechanism for this, we should take
>> this argument into account when deciding to which Inset to relay.
This
>> would mean to put lfun-specific code into LyXAction::dispatch (IIRC),
>> which is ugly.
>
>The note inset
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes writes:
Vincent van Ravesteijn - TNW wrote:
3. Yet another way is to introduce a new LyXAction flag that says that
this lfun should be dispatched both to the current inset as to the next
inset. In that case, we could process the argument i
Jean-Marc Lasgouttes wrote:
"Vincent van Ravesteijn - TNW" writes:
1. If we want to use the AtPoint mechanism for this, we should take this
argument into account when deciding to which Inset to relay. This would
mean to put lfun-specific code into LyXAction::dispatch (IIRC), which is
ugly.
Abdelrazak Younes writes:
> Vincent van Ravesteijn - TNW wrote:
>> 3. Yet another way is to introduce a new LyXAction flag that says that
>> this lfun should be dispatched both to the current inset as to the next
>> inset. In that case, we could process the argument in Inset::dispatch.
>> That wo
"Vincent van Ravesteijn - TNW" writes:
> 1. If we want to use the AtPoint mechanism for this, we should take this
> argument into account when deciding to which Inset to relay. This would
> mean to put lfun-specific code into LyXAction::dispatch (IIRC), which is
> ugly.
The note inset can look at
Vincent van Ravesteijn - TNW wrote:
3. Yet another way is to introduce a new LyXAction flag that says that
this lfun should be dispatched both to the current inset as to the next
inset. In that case, we could process the argument in Inset::dispatch.
That would mean AtPointAll (or something like t
>> I don't see a way to use this with the AtPoint LyXAction flag. I
>> either have to revert this, or discard the use of this argument.
>
>Sorry, I probably missed one of your messages, could you tell me
>again why they cannot be used together? Is that a technical problem
>or a UI problem?
This
"Vincent van Ravesteijn - TNW" writes:
> So, do you have any ideas what to do with the argument of inset-settings
> ? The only place where this is used is the Edit menu, e.g.
> 'inset-settings note'
This version with argument is useful AFAIK to have a personalized menu
entry "Note Settings...". I
>> 2. the status of LFUN_INSET_SETTINGS is handled by
>> BufferView::getStatus() and the dispatch is handled by
>> Text::dispatch(). This looks at least a bit awkward. Shouldn't these
>> be handled by the same class ?
>
>Why not all of them in the relevant inset class?
>
>> 3. when Text::dispatch
11 matches
Mail list logo
