On Fri, 4 Aug 2000, Angus Leeming wrote:
[...BufferView::Dispatch()...]
I'm still not sure it's the right place but then I also haven't looked at
your patch ;-)
> Well then, we have three choices.
>
> 1. We keep the code as it was, with the "move around the ducument"
> functionality in the dialog. As I understand it, this is contrary to
> the "keep functionality out of the dialogs and in the kernel" approach
> that I've had thrown at me in the past.
That's correct. It also means there is no code sharing between
implementations
> 2. I can try and convince you that this "all lyxfuncs should take
> arguments which are expressed as strings" argument is self-imposed
> rubbish. In this case we have a LyXParagraph pointer to hand and
> LyXText::SetCursor() requires just that. If we were using xtl, then I
> could obviously convert the pointer to a string and extract it in
> Dispatch, but we're not so this restriction is clearly daft IMO.
Ahhhhh (that's a big sigh by the way) XTL would make many things nicer.
> 3. You can give me a suggestion on "best practice" or "how to proceed" because
> I confess myself thick/unimaginative/pissed off!
In the short to medium term you can pile things like this into the Liason
namespace. That way it gets shared between the different toolkit
implementations and while it doesn't make all the functions available via
LyXFuncs those functions in Liason namespace will eventually be moved into
some Dispatch function somewhere once we either get XTL back in the loop
or find a suitable alternative.
After all, XTL was going to allow us to shift the Communicator class from
lyx module into LyXFunc. Now we use a namespace instead and a better name
IMO (well it's the one I decided was better than Communicator but decided
not to mess up the history in the lyx module by changing to it back then).
Allan. (ARRae)
