On Thu, Aug 15, 2002 at 09:35:54PM +0100, Angus Leeming wrote:
> Communicating info to the GUI frontend
> ===============================
> We can tell LyX to open or close the dialog for an existing inset:
> LFUN_INSET_DIALOG_OPEN
> LFUN_INSET_DIALOG_CLOSE
>
> Note that we need just two LFUNs here. LyX will find the next inset following
> the current cursor position and apply the LFUNs to it.
>
> This is similar to the toggle scheme that JMarc and I played with some time
> ago (and that I'm going to resurrect). Indeed I think we should also have
> LFUN_INSET_DIALOG_TOGGLE
> that invokes the two LFUNs above.
>
> 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
Hm... this means an extra LFUN for each inset.
Why not some LFUN_INTERPRET which takes as an argument a string that gets
interpreted as if it came from a .lyx file? A dialog's "apply" would just
call
dispatch(LFUN_INTERPRET, "Formula $a+b$")
But your approch is certainly simpler to implement right now and once it
works we could have a look whether we can make it a bit slimmer.
> Both LFUNs will go through dispatch (of course) and so the data must be in
> the form of a string. I propose using the inset::write method for this too
Yes.
> LFUN_INSET_CREATE would result in
>
> buffer BUFFER_ID
> \lyxformat 220
> \begin_inset LatexCommand \citet{Butler:Tsuda97,Tsuda:etal99}
>
> \end_inset
>
> being passed through dispatch. The lyxformat data will enable us to read data
> from eg pybliographer that hasn't quite kept up with us or wishes to support
> a few LyX versions. We just send the string to Jos� and Dekel's python
> scripts before passing it to the inset::read method.
>
> LFUN_INSET_MODIFY needs also the INSET_ID to be passed
>
> buffer BUFFER_ID
> inset INSET_ID
> \lyxformat 220
> \begin_inset LatexCommand \citet{Butler:Tsuda97,Tsuda:etal99}
>
> \end_inset
>
> What we lose
> ===========
> The ability to create new insets directly from the minibuffer. Currently
> citation-insert Baker
> will insert a citation to Baker directly in the text. I think that's just
> hard-coding useless code for the sake of it. It can't be scaled to complex
> parameters and is neither generic nor powerful.
Why do we lose that ability? citation-insert Baker still could insert a
citation "Baker" at cursor position.
> Problems
> =======
> The only real problem with this whole approach lies with INSET_ID. What
> should I use? The inset address? Will it be expensive to find the inset?
No inset id please. The cursor (or some other kind of iterator for that
matter) should be moved to the place in question and the lfuns should
operate at the cursor position.
> (Currently we store the inset pointer in the frontend and apply() directly,
> but that circumvents dispatch() and isn't very nice, as I've already
> mentioned.)
Insets could hold a "temporary id" while they are edited (and if we edit
just one inset at a time this might as well be a binary flag) but please
no global id that needs to be maintained.
> What do you think about the plan?
Go!
> Is it feasible?
I think so. I was a bit sceptical regarding the LFUN stuff all the time but
now that I've seen how much they can simplify interface things in mathed it
should help the core as well...
> Thoughts welcome and good night ;-)
Sleep well ;-)
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
