Tommaso Cucinotta schreef:
Vincent van Ravesteijn wrote:
So, if you think about this, you'd say that it's already "wrong" that
you want to have this information about a buffer in lyxfind.cpp.
Maybe it's already "wrong" to do this buffer management in lyxfind.cpp.
I'm sure it is wrong, I'm only trying to proceed incrementally, given
my availability constraints.
Don't worry, I'm not blaming you. I'm just thinking aloud.
Why don't you do all this in the FindAndReplaceWidget ? If you have
found the scope S_OPEN_BUFFERS, you step through all open buffers,
and for each you call lyx::dispatch(LFUN_WORD_FINDADV...).
In fact, I was thinking to intercept the LFUN at a higher level
(perhaps GuiView level), and move all the buffer switching logics
there. However, I'm not sure about how to exactly move in this
direction, i.e.:
1) currently we have in BufferView::dispatch():
case LFUN_WORD_FINDADV:
findAdv(this, cmd);
break;
2) I would move the "case" into GuiView::dispatch() (and I would
remove the LFUN_WORD_FINDADV interception from BufferView::dispatch() ?)
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.
However, in order to implement this, I would need to call the
GuiWorkArea * GuiView::workArea(Buffer & buffer)
on a related note, what is the "Buffer::gui_" field ? What is the
purpose of those "gui delegate" ? If I call "hasGuiDelegate()", is
that equivalent to checking that the buffer has an associated view
(workarea and bufferview) ?
I can't explain what the bufferGuiDelegate and the BufferViewGuiDelegate
exactly do, but you can see in src\frontends\Delegates.h what kind of
info is passed to the frontend.
You can't use this for checking whether a buffer has an associated view.
You can see this in GuiView::on_currentWorkAreaChanged: each time you
switch from workarea, the buffer and bufferview get disconnected from
the gui.
In one of the first `findadv' patches, I used to call directly
lyxfind.cpp from the F&RWidget, then I was told to use LFUNs, and now
that I use LFUNs there is another issue I raised some time ago of how
to retrieve "return values" from LFUNs. The interaction between the
F&RWidget and the actual findAdv() logics (in lyxfind.cpp) would be
two-way, not one-way.
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.
Vincent
Index: BufferView.cpp
===================================================================
--- BufferView.cpp (revision 32729)
+++ BufferView.cpp (working copy)
@@ -1504,7 +1504,10 @@
}
case LFUN_WORD_FINDADV:
- findAdv(this, cmd);
+ if (findAdv(this, cmd))
+ cur.dispatched();
+ else
+ cur.undispatched();
break;
case LFUN_MARK_OFF:
Index: frontends/qt4/FindAndReplace.cpp
===================================================================
--- frontends/qt4/FindAndReplace.cpp (revision 32729)
+++ frontends/qt4/FindAndReplace.cpp (working copy)
@@ -189,6 +189,10 @@
oss << opt;
LYXERR(Debug::FIND, "Dispatching LFUN_WORD_FINDADV");
dispatch(FuncRequest(LFUN_WORD_FINDADV, from_utf8(oss.str())));
+ if (view_.documentBufferView()->cursor().result().dispatched())
+ LYXERR0("dispatched");
+ else
+ LYXERR0("NOT dispatched");
}
