Re: Learning about BonoboControls/NautilusViews

[hckx netscape net (M)]

Thanks for the answers (to all)

Michael Meeks <michael ximian com> wrote:
>    Why do you not want to be activated ?

Simple. I was thinking about an editor/viewer. (texteditor, formula
editor, whatever). E.g. it would be usefull to embed the formulaeditor
as an editable component (menus have been merged, the view/edit area
has been made "sensitive", etc), but in nautilus it just has to show
its contents... Therefore the control should not be activated. But I
assume there are other and better ways to achieve something like
that?

>    Sounds very odd; what is the control doing ? you're not doing a
>sleep(5) somewhere ;-) then again, perhaps the nautilus adaptor is
>causing grief; although it shouldn't. Try re-building ORBit2 with
>--enable-debug=yes; from clean; and doing export ORBIT2_DEBUG=traces,
>and running your component from the console - you should see lots of
>output on what is happening - see if that helps locate the slow piece,
>or use gdb.

Well, although my time is limited i will play with the debug mode in
the weekend or something. But my sample control is really a toy example.
It really doesn't do anything except displaying a "custom widget" (wich
is imho already a big word for what it actually is) inherited from VBox,
containing 2 Labels. The control has menu items for the edit menu. And you
if click them, the label messages change. Not really a cpu intensive
somehting :) I've put my little toy online, but I don't think it is
interesting to take a look at. It's rather boring :) (maybe it's just
the way i use the nautilusview class)

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.

Well, I'm going to play some more with my toy example.
(http://win-www.ruca.ua.ac.be/~s005562/code/bonoboplay)

BTW: sorry, I forget to fill in the CC field the first time. Ahum  :)


Kind regards, Steven.

__________________________________________________________________
Try AOL and get 1045 hours FREE for 45 days!
http://free.aol.com/tryaolfree/index.adp?375380

Get AOL Instant Messenger 5.1 for FREE! Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455