Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
Author: younes
Date: Sun Dec 2 18:50:08 2007
New Revision: 21923
URL: http://www.lyx.org/trac/changeset/21923
Log:
* BufferView:
- dispatch(): transfer LFUN_FILE_INSERT to GuiView::dispatch()
- menuInsertLyXFile(): split in BufferView::insertLyXFile() and
GuiView::insertLyXFile()
LFUN_FILE_INSERT is typically a function that should be handled by
Text or Buffer(View).
Replace 'is' by 'should' and I would perhaps agree. Up to now the *only*
way to trigger LFUN_FILE_INSERT was via a LyXView: We *must* have a LyX
view. So either we split the LFUN in two or we just accept that
LFUN_FILE_INSERT is not useful right now without a LyXView.
Am I right that you move it just because of the
need for the FileDialog?
You say "just because of FileDialog" while a see a major design problem.
A core function should not be able to launch a FileDialog. So this
cleanup is more important to me than the theoretical ideal placement of
this LFUN.
Note that I only moved the GUI specific part of the code. I've let the
cursor and buffer dependent code in BufferView. One way to solve this is
to put this LFUN also in BufferView::dispatch() (without the
FileDialog); then GuiView::dispatch() will dispatch the LFUN only if
there's no argument to it, otherwise it will call the global dispatch
again with the new argument. I personally prefer to just call the
relevant BufferView method (like I've done in my commits) and I don't
find any advantage of adding a new indirection. This is worth absolutely
nothing and it complicates debugging in addition. A BufferView cannot
exist without a GuiView so what is the point? I agree that these LFUNs
should be also in Text (without the FileDialog calls) but that's
completely orthogonal to my cleanup.
If so, I do not think it is the right way to
do it (but it is only my opinion).
The above is also only my opinion. I'll tell you what, let's wait for
others to express their opinions on the matter. I know already that
Andre' and Alfredo agree with me (please correct me if I am wrong).
Unfortunately there are not many others that have an insight on the
matter. Juergen or Georg maybe?
If there's a general agreement with you that we should keep the global
dispatch method in any case then I will do the change outlined above. If
not, then I'll continue with what I think is a cleaner design.
Abdel.
