Andre Poenitz wrote:
On Wed, Sep 27, 2006 at 03:17:34PM +0200, Jean-Marc Lasgouttes wrote:
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? 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?
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.
I recently wondered whether the current Cursor is The Right Thing.
It has 'model' parts (points to a place in a doc), yet also conveys
'view' information in .bv().
I guess in the long run this is not ideal...
/me neither. I prefer simple class that do simple thing good. Cursor
should not be a gateway to everything in the LyX memory structure.
And yes, I know who's to blame...
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.
Indeed. This is no advantage. Better pass stuff down as arguments
instead of relying on globals.
Wait, there is a misunderstanding here. I am not using the theApp to
look for the current view, only to get access to the LyXFunc. It is my
understanding that there shall be one unique LyXFunc and that
theApp->lyxFunc() is the official way to access it.
The origin of the misunderstanding is that LyXFunc still depends on one
(unique) LyXView. I will get rid of that assumption when FuncRequest
contains a pointer to the relevant LyXView a.k.a the LyXView ID given by
the Gui class.
theApp->xxx is indeed current_view in disguise.
Only temporary.
Abdel.
