On Tue, Feb 18, 2003 at 03:15:21PM +0000, Angus Leeming wrote:
> Andre Poenitz wrote:
> > Not sure. I personally would lean to the first option, as the InsetBase
> > ideally does not know anything about dialogs
> >
> > (which, of course is not true, as it has to declase 'hideDialog'...).
>
> Not true. hideDialog need not be virtual if we adopt your 'guiding
> principle', above.
True...
> We could have:
>
> class InsetBase {
> virtual ~InsetBase() {}
> };
> class InsetCommand {
> virtual ~InsetCommand() { hideDialog() };
> /** classes derived from InsetCommand all have dialogs, each with
> its own unique name. */
> virtual string const & name() const = 0;
> ///
> void hideDialog() {
> BufferView * bv = cached_bufferview...;
> bv->owner()->getDialogs().hide(name);
> }
> };
So that's probably the way to go.
> The only problem that remains is extracting the cached_bufferview (which is
> a problem common to all these 'solutions').
I am starting to believe that all insets should cache a bufferview or some
"context" after e.g. draw() is called ...
> Am I correct in saying that you
> store it in the mathed insets?
Yes. But I always thought of this as a kludge. But maybe it is not as much
of a kludge afterall.
It certainly cleans up the rest of the interface a lot as the BufferView
does not have to be passed around all the time. On the other hand, it makes
things a bit more fragile...
> Could you move this store into InsetBase?
Sure. Should I? This would certainly help IU a lot...
But maybe one or two of the others could give there opinions as this is a
rather serious architectural change, at least for inset/*. math used to
work like that all the time AFAIK, so it is technically feasible, even if
it's not really "nice"...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
