Re: Problem with popup menu cache system

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.


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]