Re: Problem with popup menu cache system

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

Hi again,

The new patch proposal is available in bugzilla :

http://bugzilla.gnome.org/show_bug.cgi?id=339273

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 :

ftp://ftp2.grumz.net/grumz/nautilus-actions.dev_rc2.tar.gz

Best regards,

Fred

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