Re: Problem with popup menu cache system
- From: RUAUDEL Frédéric <ruaudel embl fr>
- To: Alexander Larsson <alexl redhat com>
- Cc: grumz grumz net, nautilus-list gnome org
- Subject: Re: Problem with popup menu cache system
- Date: Fri, 16 Jun 2006 13:53:47 +0200
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 :
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
org:EMBL Grenoble Outstation;Computer & Network Team
email;internet:ruaudel embl fr
] [Thread Prev