Here’s a screenshot of testaction test showing the GtkRecentAction action for use with the GtkUIManager. The action is bound to a menuitem tag inside the UI definition markup.
The code needs cleaning up and the hooking up of the GtkRecentChooser interface virtual methods, but it’s not a big issue; setting all the recent chooser knobs using the recent chooser API is not the most beautiful approach I could come up with, though. But so is setting all the properties using specially crafted functions.
The next issue is inlining the list inside a menu (to make the Gedit maintainers happy ;-)). The current (and soon to be deprecated) EggRecent code used the awful EggRecentViewGtk object and its evil spawn (EggRecentViewUIManager and the most devilish EggRecentViewBonobo). The GtkRecent approach “get the list from the recent manager and build the menu items” works for hand-built menus, but for menus created using the UI manager there’s no real option, as there’s no way to create a list of items from a GtkAction. One way to implement it might be adding a GList * (*create_menu_items) (GtkAction *action); virtual method inside GtkActionClass.
Update 2006-04-18@03:51: the tracking bug with my initial draft for the GtkRecentAction is #338843
Now listening: Belle and Sebastian, The Life Pursuit
I don’t see where exactly the problem is: can’t “GtkRecentViewUIManager” just maintain a GtkActionGroup containing a GtkAction for each (visible, after filtering) item in the model, updated whenever that list changes? And given the UI path where to merge its UI, clean & (re)build its UI with a fresh merge ID whenever the list of visible items changes? I don’t think that’s “messy” at all, in fact that’s how we do it in epiphany for menus with dynamic content.
How would your idea above work with the activate signal? That gets only the action, so there’s no way to know from which menu item it was activated and therefore no way to get which recent file to open…
chpe: I know how the current users of the EggRecentViewUIManager do that (I did maintain that code for almost a year, after all), and I think that the involved machinery is awful, code-wise. The amount of hackery involved in such an object is why the egg-recent code sucks so much; if possible, I’d like to avoid that, in favour of a cleaner approach. extending the UIManager is not a problem: it can be done without too much hassle.
actions can have multiple signals: the GtkRecentAction class has an “item-activated” signal which is fired each time an item in the sub-menu (which is a GtkRecentChooserMenu) is activated.