XDG menu implementation

[Jannis Pohlmann]

On Thu, 27 Jul 2006 12:25:49 +0200, Benedikt Meurer wrote:

> Jannis Pohlmann wrote:
> >> a) It should be thread-aware (not necessarily thread-safe). That is
> >>queries on the tree must be possible from various threads (not
> >>necessarily on the same XfceMenu/Frap, as that would probably add
> >>too much locking overhead).
> > 
> > Yes, that's something I didn't care about until now. But it should
> > be doable. Perhaps you can point me to some thread-safe library
> > code where I can get inspirations from? That would be cool, as I
> > still only have a vague image of how this needs to look like.
> 
> Maybe start off with some "Operating System" lecture notes to get the
> big picture. It's not really something that can be learned by looking
> at other peoples code.
> 
> But in general, for the library to be thread-aware:
> 
>  1) Non-singleton GObject's aren't protected by the library.
>  2) Singleton GObject's and all shared data (most probably the desktop
> database, etc.) will need to be locked for every access (read/write).

Yep, I already thought so. Currently I have some static shared data
which isn't exported yet and thus is not used globally. I'll look into
how to do this and add mutex locks for globally shared data afterwards.

> >> b) Thunar (currently the "Open With" dialog) needs a way to query
> >> all
> >>installed applications (-> .desktop files) that claim to handle
> >>atleast one MimeType (the condition can be checked in Thunar, once
> >>we have the application list). Currently, there's no clean way to
> >>retrieve this list and structure it according to the menu
> >>definition. This will also be needed for the application browser.
> > 
> > Of course, something like this will be implemented. All
> > XfceMenuItems (which represent application desktop entries) will be
> > stored in a kind of cache (database, DesktopFile-Id hash table) and
> > it shouldn't be hard to add mime query functions for this.
> 
> Maybe just add a generic query interface, where the caller specifies a
> callback predicate that is invoked on all desktop entries, and only
> those are returned for which the predicate returns TRUE.

Sounds good.