Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> No, add() do need to know what the current Buffer is, it
Abdelrazak> just need some FuncRequest status via
Abdelrazak> theApp->lyxFunc().getStatus().
Yes, but getStatus knows what the current buffer is.
Yep. And I need to make some change so that it does not crash when there
is no current buffer.
However, some other functions need this buffer passing because
theApp won't tell what the current buffer is. Aren't we
reintroducing the dreaded current_view thingy?
Abdelrazak> AFAIS, these functions needs this Buffer passing for
Abdelrazak> specific purpose:
Abdelrazak> - expandFormats needs to know if there is an opened
Abdelrazak> document currently and for the need of Exporter functions.
Abdelrazak> - expandFloatListInsert() and expandFloatInsert() need
Abdelrazak> some float list from the buffer. Actually they just need a
Abdelrazak> BufferParams.
The question is: how are we sure that the buffer that is passed as
parameter is the same than the one theApp knows about?
You have a point here. But this is very specific to the MenuBackend
which is directly related to the LyXView. In the case of add(), this is
really the Cursor that you need.
What are the
semantics of these two buffers? If we are doing some processing on a
document which is not the current one, how do we make sure that all
functions rely on the right document?
In principle if the processing is asked to be done following some GUI
interaction. There could be also cases where the asked processing should
be done on a buffer that is not visible on screen currently.
For example, on a multipart document it would be a good idea to navigate
to whatever part of the document. So you don't want to restrain the
MenuBackend to be usable only for the currently visible Buffer but for
any Buffer that you pass to it.
On nice way of providing context is to pass a cursor. It conveys a lot
of information related to this. But it is not always practical.
Yes, I think it could be done here. But let's skip that for now.
Abdelrazak> But in the feature there would be indeed a notion of
Abdelrazak> "current Buffer" accessible through:
theApp-> currentView()->currentWorkArea()->bufferView()->buffer()
This is what I mean when I say that theApp knows these things.
Abdelrazak> You don't want to use that ;-) I prefer to pass
Abdelrazak> explicitely what I need and not rely on some indirection
Abdelrazak> that may change in the feature.
This makes sense only if you are sure that those two informations are
the same.
Abdelrazak> You may have noticed that most of my cleanup work is about
Abdelrazak> removing the need for these indirections. You don't want
Abdelrazak> me to re-introduce that do you? ;-)
In the case of MenuBackend, you remove the explicit view argument and
use (hidden) indirection via lyxApp instead. It might not be the
wisest thing to do after all.
In the case of the cursor position, you're right but you need the Buffer
information in any case.
For the expandFloatList etc, cases, my point is: I want information that
is depending on the document structure. So I just need to pass a Buffer.
Abdel.
