XDG menu implementation

[Benedikt Meurer]

Stephan Arts 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?

Ehm, no thread-safe doesn't mean that the caller does the locking, and
it also doesn't mean that the lib cannot be used in single-threaded
applications - after all a single-threaded app is just a threaded app
with only one thread. ;-)

> Stephan

Benedikt