Abdelrazak Younes <[EMAIL PROTECTED]> writes: > 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.
But if we have a bufferview, we have a LyXView, don't we? >> 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. The BufferView knows that a GUI exists, doesn't it? What can't this GUI include file dialogs? > 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. Since it operated on a buffer and requires a view, I thing that BufferView is a good place. If we separate into with arg and without arg cases, then the nogui version should go to Text. There is no need to BufferView since the view is not relevant any more (or am I wrong?) > 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? I do not have so strong feelings about this particular lfun. I am asking primarily to try to see where we are heading. > 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. Yes, I like the robustness of the global dispatch. JMarc
