On Thu, Aug 15, 2002 at 09:35:54PM +0100, Angus Leeming wrote:
> This breaks the "everything has an LFUN and goes through dispatch" rule and
> means further that modifying existing insets using (shock!) the LyX server is
> impossible.
I still don't understand the big deal here. So what ?
This will not provide anywhere near the needed support for
scriptability. Why is a half solution worthwhile ?
> I have been thinking about a Better Way. It will result in far fewer LFUNs
Well I like that idea.
> We can tell LyX to open an inset dialog when no inset exists, the idea being
> that the user can then subsequently create an inset by apply()ing the
> dialog's parameters. We'll need LFUNs for each inset type:
> LFUN_BIBTEX_DIALOG_OPEN
> LFUN_CITATION_DIALOG_OPEN
> LFUN_TABULAR_DIALOG_OPEN
What use is there in allowing lyxserver to do this when the dialogs
cannot be scripted ?
> What we lose
> ===========
> The ability to create new insets directly from the minibuffer. Currently
> citation-insert Baker
So you want to replace some very handy functionality with something
awkward and not seemingly useful ?
> The only real problem with this whole approach lies with INSET_ID. What
> should I use? The inset address?
How about the inset id() ?
> What do you think about the plan? Is it feasible? I think that it will clean
> up the whole area and will adapt automatically as LyX evolves.
Can you explain a bit further what it's really cleaning up ?
regards
john
--
"It is unbecoming for young men to utter maxims."
- Aristotle
