Re: Bonobo UI code feedback

[Martin Baulig <martin home-of-linux org>]

Darin Adler <darin eazel com> writes:

> Hi Michael. Here are my current thoughts on the Bonobo UI code. I posted
> them here in the interest of greater openness, but we can continue this
> discussion either privately or publicly.
> 
> ================
> 
> The top priority for the Nautilus team (and for Eazel) is to get a suitable
> Bonobo release for our PR2 release. Beyond what's in PR2, the main things we
> need are fixes for:
> 
>     1) The problem that you, Maciej, and Martin discussed (way to make the
> UI container work properly with our component adapter), which is covered by
> our bugzilla.eazel.com bug 3691.

Hi Darin,

When do you want to make the PR2 release ? I'll try hard to have this done
in time and to also provide you a working and tested patch for the zoomable
interface in Nautilus.

>     2) Translatoin of text in XML files. Maybe this won't require any Bonobo
> changes, but I'm still not 100% clear how to handle it in Nautilus; I'd like
> some "exemplary" module to copy.
>     3) The bug that's in bugzilla.eazel.com bug 3705. Some of our bookmark
> icons aren't showing up and we need to figure out if it's a bug in Nautilus
> or in Bonobo.
> 
> If we can get these three resolved, and get another Bonobo release, then I
> think we're OK for the Nautilus PR2 release.

I'm really looking forward to finally kill netscape and use /usr/bin/nautilus
instead :-)

> ================
> 
> I'm on the record saying that I think it was late to make such a big change
> to Bonobo. Here's a big part of the reason. These are my thoughts on the
> current Bonobo UI API given a few weeks experience with it. I think that
> addressing all of these problems is far too much work to be undertaken for
> Gnome 1.4, and I'd suggest doing it for Gnome 2.0 instead. But as I
> understand it, Miguel wants to freeze the Bonobo API between Gnome 1.4 and
> Gnome 2.0, so perhaps we just can't address these.
> 
> ================

Hopefully you won't kill me when I now propose this, but can we please remove
all traces of the old UI handler code from Bonobo before making the release ?

I already commented them out in my local tree and Nautilus still compiles
without any problems.

> API thoughts (big and small):
> 
> *_get_remote_ui_container is not a good function name. In the old days we
> had to distinguish the remote UI handler from the local one. Now there is
> only one UI container, so this should be named *_get_ui_container. The
> "remote" is just confusing now.
> 
> BonoboWin is not a good class name. It should be BonoboWindow to be
> consistent with all the other class names in Bonobo and Gtk.

Hmm, this sounds reasonable to me. Michael ?

> BonoboControl automatically creates a BonoboUIComponent. But it does not
> connect it to the BonoboUIContainer. It should do that work inside
> bonobo_control_set_control_frame. Controls with fancier UI requirements
> could just use their own BonoboUIComponent. This is tied to the strange
> automerge feature. This area needs to be cleaned up. It's unnecessarily
> confusing.

Well, if I understood Maciej's idea how to fix 1.) correctly, then the
control must not access the BonoboUIContainer when it is not activated
(since we want to allow the container to change when the control is
deactivated).

So I think the right thing is to connect/unconnect the container in
impl_Bonobo_Control_activate() .... oops, that's the way it already works.

> The calls in Bonobo*Frame interfaces are still called "get_ui_handler" but
> should be called "get_ui_container".

That's really confusing.

> [snip]
>
> The gnome-ui-compat.[ch] files and gnome-ui-handler.h should be removed
> before the 1.0 release. There is very little code left using it, and we can
> get that down to nothing very easily.

Oh, you won't kill me for proposing this, you already proposed it yourself :-)

Well, I can confirm that at least Nautilus and Gnumeric will work fine.

> [snip]
> 
> Radio item menus are missing the convenient interface that we have for
> command-type menus. They shouldn't require the explicit signal handler the
> way they do.

Yeah, I started to work on this, but I'm still discussing with Michael how
this is done best.

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)