On Mon, Mar 10, 2003 at 11:25:52AM +0000, Angus Leeming wrote:
> > Ideally, I don't have Insets, only InsetBases.
> 
> Sure. That would work too.

So can you change that to InsetBase?


And the rest now is idle talk:

> > 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.

What would it add 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.

Together with an  InsetBase *  if I understand correctly.
For "mailing strings" alone, a FuncRequest looks reasonable, doesn't it?

> I also pass/store an InsetBase* in the Dialogs class but I'd rather not
> :-(

Because you need to figure out to which Inset the Dialog belongs. Ok, I
think I understood that.

> You suggested some sort of InsetID before...

Something string-like at least... but I still don't have a clue what would
be a proper solution.  Maybe an external (Dialog::static) map   Inset ->
active Dialog  would do...

I don't think I would like numeric InsetIDs too much.

> > 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.

I know, that's why I am trying to device a way to pass the  Inset<->Dialog
association without actually passing Inset pointers. Just losing the
association and re-create it by some kind of lookup/search if needed seems
to be one option.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Reply via email to