Vincent van Ravesteijn wrote:
We use the LFUNs to communicate from the GUI to the core. So, it's not
necessary to communicate from a Widget (which has a view_ member) to
the GuiView by means of an LFUN.
3) then I would call a GuiView::findAdv() method, which would
implement the "scope" functionality and buffer switch by repeatedly
calling lyx::findAdv(), as found in lyxfind.cpp.
Well, this is approximately the same situation for which people told
you to use an LFUN.
Would it be ok ? I don't want to mess-up with the LFUNC dispatching
stuff.
No, then you're back at calling lyxfind.cpp directly from the frontend.
I was thinking to have the widget ask the view to perform the search by
direct call, and the view performing the search in various buffers by
multiple LFUN calls. However, I'll see if it can all be handled directly
from within the widget.
Well there is a way to do this. See the attached patch.
However, I'm not sure whether everyone likes this approach. Anyway, I
think the concept of the LFUN being dispatched or not is what you
need: did I get a result or didn't anything happen.
well, you are "encoding" in the dispatched() boolean the result of the
search. However, you're probably raising semantic issues on the meaning
of "result().dispatched()": does it mean "the operation was performed
(because directed to the right model element) and something happened",
or does it mean "the operation was performed -- stop" ? I was thinking
it were the second one, i.e., if I search for something that cannot be
found, then I would get "LFUN dispatched, but no match found", but this
is a custom dispatching machinery (not the standard Qt one), so all
depends on the meaning we want to give it.
Anyway, I can survive with such an approach -- should I need a finer
information to be returned back from the search in the model to the
widget/GUI, then I'll try to use the DispatchResult stuff.
Thanks,
T.
