[Xfce4-commits] r26505 - in xfdesktop/trunk: . modules/menu

[Jannis Pohlmann]

Am Wed, 26 Dec 2007 14:02:21 -0800
schrieb "Brian J. Tarricone" <bjt23 at cornell.edu>:

> 
> 
> On Wed, 26 Dec 2007 19:30:09 +0100 Jannis Pohlmann wrote:
> 
> > Hey Brian,
> > 
> > Am Wed, 26 Dec 2007 06:59:39 +0000 (UTC)
> > schrieb "Brian Tarricone" <kelnos at xfce.org>:
> > 
> > > Author: kelnos
> > > Date: 2007-12-26 06:59:39 +0000 (Wed, 26 Dec 2007)
> > > New Revision: 26505
> > > 
> > > Modified:
> > >    xfdesktop/trunk/configure.ac.in
> > >    xfdesktop/trunk/modules/menu/desktop-menu.c
> > > Log:
> > > invalidate .desktop file cache when something changes, disable
> > > adding per-file monitors (per-directory is enough), tho there
> > > appears to be a bug in the menu directory monitor code in
> > > libxfce4menu
> > 
> > I've tested this update on my laptop and monitoring indeed does not 
> > seem to work. 
> > 
> > I wrote a small test program which is the same as
> > test-display-menu.c from libxfce4menu/trunk/tests/ but which adds
> > ThunarVFS support. Like xfdesktop it only monitors directories and
> > rebuilds the whole menu on filesystem changes. Maybe you can get
> > some inspirations from it, dunno. If not, I can debug xfdesktop
> > again to see if I can find the problem. I don't think it's a bug in
> > libxfce4menu, but of course I might be wrong.
> 
> Here's what I get on xfdesktop startup:
> 
>  $ xfdesktop 2>&1 | grep -E 'desktop(-|_)menu'
> DBG[desktop-menu.c:291] _generate_menu(): menu file name
> is /home/brian/.config/menus/xfce-applications.menu
> TRACE[desktop-menu.c:173] desktop_menu_xfce_menu_monitor_directory():
> exiting (/opt/xfce4-svn/share/applications), returning 0x0x100976b0
> TRACE[desktop-menu.c:173] desktop_menu_xfce_menu_monitor_directory():
> exiting (/usr/local/share/applications), returning 0x0x10097850
> TRACE[desktop-menu.c:173] desktop_menu_xfce_menu_monitor_directory():
> exiting (/usr/share/applications), returning 0x0x100974c8
> TRACE[desktop-menu.c:173] desktop_menu_xfce_menu_monitor_directory():
> exiting (/home/brian/.local/share/applications), returning
> 0x0x10097718 TRACE[desktop-menu.c:120]
> desktop_menu_something_changed(): entering
> (2,/usr/local/share/applications) TRACE[desktop-menu.c:185]
> desktop_menu_xfce_menu_remove_monitor(): entering (0x0x100976b0)
> TRACE[desktop-menu.c:185] desktop_menu_xfce_menu_remove_monitor():
> entering (0x0x10097850) TRACE[desktop-menu.c:185]
> desktop_menu_xfce_menu_remove_monitor(): entering (0x0x100974c8)
> TRACE[desktop-menu.c:185] desktop_menu_xfce_menu_remove_monitor():
> entering (0x0x10097718) DBG[desktop-menu.c:291] _generate_menu():
> menu file name is /home/brian/.config/menus/xfce-applications.menu
> 
> So it looks like what's happening is it's adding directory monitors
> for everything, then getting a _DELETED message for
> /usr/local/share/applications (which doesn't exist, weird), which
> causes all the monitors to be removed.  The menu gets re-generated,
> but the directory monitors don't get re-added.
> 
> If I re-add the code that sets a file monitor as well as a directory
> monitor, things sorta work.  The same thing happens -- all the
> monitors (file and dir) get added, then the 'something changed'
> callback gets called, which removes all monitors.  Then the menu gets
> regenerated, but only the *file* monitors get re-added.  The
> directory monitors still don't get added.

Oops, my bad:

 * libxfce4menu/xfce-menu-monitor.c: Use the KEY, not the VALUE
   pointer to remove items from the shared handle hash table. In this
   case, use the directory string instead of the shared handle. This
   should fix the issue we've had with monitoring directories only.

Mind to try again? Works fine now over here with both, xfdesktop and
menu-test.c.

  - Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20071227/7163d19a/attachment.pgp>