xfdesktop menu is getting awesomer

[Brian J. Tarricone]

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?

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

	-brian