Re: Learning about BonoboControls/NautilusViews

[Michael Meeks <michael ximian com>]

Hi Steven,

On Tue, 2003-04-22 at 21:03, M wrote:
> Therefore the control should not be activated. But I
> assume there are other and better ways to achieve something like
> that?

	I suppose we have not been overly strict about the semantic difference
between activated and non-activated controls; AFAIR the activation phase
is intended to allow the menus to be merged etc.

> And back about the BonoboPersistFile: inheriting from BonoboPersist
> and implementing the methods from the Bonobo::PersistFile is very
> easy. Neverteless, more in reaction of Jens his comment about not
> using a working peace of code: Maybe an alterntive for the current
> BonoboPersistFile GObject would be an Abstract class with 2 abstract
> methods load and save. The epv mehtods should call these
> abstract GObject methods. That way the user would be obliged to
> inherit from BonoboPersistFile and is not confronted by the epv
> and stuff. Or is this just plain stupid? :) The abstract BonoboPersistFile
> could also have "file-loaded" and "file-saved" signals (emitted when the epv mehtods are called of course), just to give it a little more functionallity and use besides abstracting away the epv stuff. Just a
> thought.

	We used to have such evilness in BonoboPersist* but essentially we had
a CORBA method, and it _needed_ to pass all it's arguements (including
the CORBA_Environment etc.) to the virtual method (which in several of
these kinds of wrapper it didn't), and the whole thing became just one
vast ugly mess.

	WRT signal connections - yes it could be done that way - but IMHO it's
better to get people to implement a BonoboPersistFile interface
themselves - if only to see that it's easy enough. Cluttering Bonobo
with redundant wrapper code is not ideal IMHO.

	Of course - we could perhaps make a macro that would do everything for
you; sub-classing etc. etc. but ...

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot