This is an old revision of the document!
Garcon Thoughts
There are some issues in garcon (previously libxfce4menu, with API changes and GIO support) that needs some discussion, most important: file monitoring support.
Specifications: Desktop Menu, Desktop Entry.
Sources: Garcon, Alacarte.
File Monitoring
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.
GarconMenuItem
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).
GarconMenuItem::changed (VOID:VOID)
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 ~/.local/share/applications/
.
Misc
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_init()
andgarcon_shutdown()
- Implement
GarconMenuSeparator
andGarconMenuItemCache
as a singleton. - Get rid of
g_thread_init()
. This should be possible if we useGStaticMutex
instead ofGMutex
. - People only need to call
garcon_set_environment()
, this will 'leak' once if they don't callgarcon_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.