This is an old revision of the document!
There are some issues in garcon (previously libxfce4menu, with API changes and GIO support) that needs some discussion, most important: file monitoring support.
We'd like the give the library build-in support for monitoring menu changes. This means we monitor the .menu file(s) for changes (for example made by Alacarte) and the .desktop file directories for added/removed/changed desktop files. When something changed we don't want to rebuild everything, but rather update and trigger some signals and notify properties.
Description: URI → GarconMenuItem item relation (hash table).
Description: Desktop-ID → GarconMenuItem item relation (hash table).
Description: The desktop file.
We're not going to implement file monitoring on this level. However there will be some new API to reload a desktop entry (possibly from a new location) and the possibility to watch changes (signal, property notifications).
Always triggered then the item is reloaded.
void garcon_menu_item_reload (void)
Reload the menu item from the same GFile. This will notify the changed properties and trigger the 'changed' signal.
void garcon_menu_item_reload_from_file (GFile *file)
Will do the same as
garcon_menu_item_reload() but from another location, useful when a user changed a desktop file in a read-only location and the menu editor moved the file to
A couple of tasks that need to be done:
- Always return a reffed object in the _get_ functions and mention this in the API docs.
- A couple of structs need to move to the header.
- Personally I find the gio helpers a bit ugly in the public api, maybe we can make this private (preferred) or rename them to start with garcon_.
- Possibly drop
garcon_shutdown(). Still needs some thoughts, but it would be nice if we can simplify this as much as possible.
GarconMenuItemCacheas a singleton.
- Get rid of
g_thread_init(). This should be possible if we use
- People only need to call
garcon_set_environment(), this will 'leak' once if they don't call
garcon_set_environment (NULL), but I don't think we really care.
- Don't know about
g_type_init()yet. Probably not needed 99% of the time, so I think if we mention this in the API docs we're pretty much safe.