Re: Problem with popup menu cache system

[RUAUDEL Frédéric <ruaudel embl fr>]

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 ?

> 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 ?

>  static void
> +menu_provider_items_updated_handler (NautilusMenuProvider *provider, 
GtkWidget* parent_window, gpointer dat
> a)
> I don't like this at all. You're hardcoding lots of knowledge about the
> implementation of windows and views in a general place. A better
> approach would be to create a new signal "menu_extensions_changed" in
> NautilusSignaller and have the windows and views listen to that signal
> and re-read their extension menus when its emitted.

Indeed it is not very clean. I didn't see this NautilusSignaler stuff. I 
will try to use this instead, thanks.

Regards,

Fred

begin:vcard
fn:Frederic RUAUDEL
n:RUAUDEL;Frederic
org:EMBL Grenoble Outstation;Computer & Network Team
email;internet:ruaudel embl fr
title:System Administrator
x-mozilla-html:FALSE
version:2.1
end:vcard