XDG menu implementation

[Stephan Arts]

On 7/27/06, Jannis Pohlmann <info at sten-net.de> wrote:
> 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

Perhaps i am wrong here, but if you make your library thread-safe
instead of just thread-aware (in which case the app itself needs to
handle locking), it would not be possible to use the lib in a
single-threaded environment right?

With this in mind, shouldn't thread-awareness be better then thread-safety?

Stephan