Re: Problem with popup menu cache system

Hi again,

The new patch proposal is available in bugzilla :

Indeed, the use of the NautilusSignaller API is much cleaner and require less code :)

You can test the code with the following development tarball of nautilus-actions if you wish :

Best regards,


Alexander Larsson wrote:

On Fri, 2006-06-16 at 11:02 +0200, RUAUDEL Frédéric wrote:
Thanks for the review,

> +    /* Signals */
> +    void (*items_updated)          (NautilusMenuProvider *provider,
> +                    GtkWidget            *window,
> +                    gpointer             *data);
> This adds a member to an interface implemented by others, which is a
> binary incompatible change. Fortunately its not needed, as the
> implementations have no need for a default handler for the signal, they
> are the ones that omit it anyway.

Ok, I can remove it. I put it in the end of the structure to avoid having to recompile other extensions. But for my general knowledge, when can we change the binary compatibility ? in the CVS head or in any version before a feature freeze scheduled date ?

Well, we don't really have a strict policy here. We'd like to do
backwards incompatible changes as seldom as we can, as that would
require us to bump the soname on libnautilus-extension and force all
extensions to be rebuilt. But if we feel some change is important we can
of course do this.

Its debatable whether adding the signal to the end like that is
backwards compat or not. For an old extension they will be passing a
vtable that has an undefined pointer for items_updated. However, in
practice that signal is not likely to be emitted for the object, since
its normally emitted by the extension...

Anyway, we just don't need it there.

> Also, i see no need to pass in the window. Keeping track of that should
> not be needed by the extensions.

This was to find back the view which have the current selected menu in nautilus but maybe I can find another way. Do you have any tips for that ? Is there a get_current_view() function anywhere ? Or maybe should I have to update all views ?

With the NautilusSignaller (or similar) approach you don't have this
problem, because a visible view will update itself when it gets the
signal it connected to. No need to "find" it.

Alexander Larsson Red Hat, Inc alexl redhat com alla lysator liu se He's a leather-clad devious inventor from the 'hood. She's a mistrustful tempestuous fairy princess prone to fits of savage, blood-crazed rage. They fight crime!

fn:Frederic RUAUDEL
org:EMBL Grenoble Outstation;Computer & Network Team
email;internet:ruaudel embl fr
title:System Administrator

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]