On Monday 10 March 2003 11:11 am, Andre Poenitz wrote:
> On Mon, Mar 10, 2003 at 10:01:38AM +0000, Angus Leeming wrote:
> > Incidentally, the Tabular dialog now expects a string so you should now
> > be able to have a woking dialog for math arrays. See insettabular.C for
> > the details, but basically it expects to extract the current active cell
> > and stuff generated by Tabular::Write. Is this good enough for you?
>
> class MailInset {
> [...]
> protected:
> ///
> virtual Inset & inset() const = 0;
> [...]
>
> Ideally, I don't have Insets, only InsetBases.
Sure. That would work too.
> The reason of using these MailInsets instead of LFUNs directed to the some
> high level dispatch() (the one in lyxfunc?) is to be able to pass an inset
> reference around, isn't it?
The reason I created MailInset was simply to avoid adding yet more shit to the
Inset classes. SInce there function is clear, it made sense to create a class
to encompass it. I don't pass a MailInset anywhere but use it to create a
string and mail that string to the Dialogs class. I also pass/store an
InsetBase* in the Dialogs class but I'd rather not :-( You suggested some
sort of InsetID before...
> If so, wouldn't it be easier to put a weak_ptr<InsetBase*> in the
> FuncRequest and pass ordinary FuncRequests by ordinary dispatches instead
> of implementing all these Mailer classes?
Then effectively you are saying that storing InsetBase* in the frontends is
the way to go. The whole point of doing this stuff was to try and move away
from that.
Angus
