xfdesktop menu is getting awesomer

[Jannis Pohlmann]

On Mon, 19 Mar 2007 16:33:06 -0700, Brian J. Tarricone wrote:

> On Mon, 19 Mar 2007 21:20:39 +0100 Jannis Pohlmann wrote:
>
> >On Mon, 19 Mar 2007 11:26:39 -0700, Brian J. Tarricone wrote:
> >
> >> On Mon, 19 Mar 2007 19:05:35 +0100 Jannis Pohlmann wrote:
> >>
> >> >On Mon, 19 Mar 2007 11:02:18 -0700, Brian J. Tarricone wrote:
> >> >
> >> >> On Mon, 19 Mar 2007 14:15:47 +0100 Jannis Pohlmann wrote:
> >> >>
> >> >> [snip: Jannis did stuff.]
> >> >>
> >> >> Cool, so everything's working now?  I didn't have time to svn up
> >> >> and check it before I left this morning.  Seriously, this is
> >> >> great.
> >> >
> >> >Indeed, hehe. Yeah, everything should be working. In fact, I'm
> >> >already running it here and the only crashes I had were related to
> >> >switching the menu filename (which probably is caused somewhere
> >> >deep in your code, so I didn't investigate this any further).
> >>
> >> Do you have a bt?  That worked fine for me.  (I.e., I had xfdesktop
> >> running, and copied a new xfce-applications.menu to
> >> ~/.config/menus/, and it switched to the new menu file
> >> automatically.)
> >
> >==23356==    at 0x1C3D01D4: g_type_check_instance_is_a (gtype.c:3115)
> >==23356==    by 0x1C85C7BE: desktop_menu_add_items
> >(desktop-menu.c:210) ==23356==    by 0x1C85CCE5: _generate_menu
> >(desktop-menu.c:319) ==23356==    by 0x1C85CE36:
> >_generate_menu_initial (desktop-menu.c:371) ==23356==    by
> >0x1C41D450: g_idle_dispatch (gmain.c:4096) ==23356==    by
> >0x1C419F3A: g_main_context_dispatch (gmain.c:2061) ==23356==    by
> >0x1C41B914: g_main_context_iterate (gmain.c:2694) ==23356==    by
> >0x1C41BC39: g_main_loop_run (gmain.c:2898) ==23356==    by
> >0x1BD92D12: gtk_main (in
> >             /usr/lib/libgtk-x11-2.0.so.0.1000.6)
> >==23356==    by 0x804EB61: main (desktop-menu-plugin.c:1090)
> >==23356==  Address 0x6C706D6B is not stack'd, malloc'd or (recently)
> >           free'd
>
> Not sure that's a bug in my code.  Are you sure the pointers returned
> in each gslist node from frap_menu_get_layout_items() is always valid?
> I've seen crashes in those kinds of cases when the object gets
> unreffed and destroyed but there's a stale pointer lying around.
>
> As a side check, the only things I'm unreffing or freeing from
> FrapMenu are:
>
> 1.  g_object_unref() on the FrapMenu pointer returned from
> frap_menu_new().
> 2.  g_slist_free() on the GSList pointer returned from
> frap_menu_get_layout_items(), frap_menu_get_menus(), and/or
> frap_menu_get_items().
>
> Is that correct?

That's completely ok. In your version of FrapMenu, *all* menus (except
for the root menu) and menu items have a refcount of 2, so it's
unlikely that something gets released anywhere ... (that's the 300k
memory leak I was talking about in the commit logs, hehe).

Dunno why it crashes this way.

> >> Oh, I did notice something weird, and I'm not sure if this is my
> >> fault or FrapMenu's.  Try this:
> >>
> >> Copy one of our X-Xfce-Toplevel .desktop files to
> >> ~/.local/share/applications/ (be sure to change the file name when
> >> you copy).  The new entry shows up in the toplevel menu as it
> >> should, sorted in aplha order with the <Merge type="all"/> items
> >> as it should.
> >>
> >> Now, open the copied .desktop file, change the Name= line, and
> >> save.  If you watch xfdesktop output, it does notice the file
> >> changed (I see FrapMenu-DEBUG statements), but the entry in the
> >> menu still has the old name.  Restart xfdesktop, and it uses the
> >> right name.  Is FrapMenu doing any caching, even across calls to
> >> frap_menu_new()?  Or did I do something wrong again?
> >
> >Yeah, FrapMenu does runtime caching. That is, all menu items are
> >stored in a (desktop-file ID => menu item) hash table
> >(FrapMenuItemCache):
> >
> >   http://svn.xfce.org/svn/xfce/libfrap/trunk/libfrap/menu/frap-menu-item-cache.c
> >
> >As a workaround you could perhaps call
> >
> >   frap_menu_shutdown();
> >   frap_menu_init("XFCE");
> >
> >if that's possible for you.
>
> Bah, that sounds slow, no?  It's fine to cache, but you need a way to
> invalidate the cache... either let the user do it with API, or do it
> in frapmenu by keeping around a list of mtimes and stat()ing the files
> when you next go to use the cached data.
>
> I don't have anything right now that requires having more than one
> root FrapMenu allocated at a time, so your workaround should be ok
> for the time being.

Most time is spent on parsing the desktop entries, so invalidating the
cache shouldn't be much faster than restarting FrapMenu completely.
There's going to be some kind of monitoring inside FrapMenu which will
do what you need soon.

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