GNOME Bugzilla – Bug 649380
extend GtkRecentManager for GNOME 3
Last modified: 2014-12-22 22:29:22 UTC
We may want applications to push more data into the system for GNOME 3's "Finding and Reminding" work. It makes sense to extend GtkRecentManager to do this. This bug is about implementing the new API.
Can't Zeitgeist take care of that?
AWESOME... So one thing that has to be changed is changing the meaning of the 1) visit timestamp: now its (open + close) and it should be (open) only) 2) modified timestamp: now its (modify + close) is should be (close only) Also you need to add a leave timestamp which happens when some1 closes a document or movie or so... Now my question is do you want recently used to overwrite the timestamps or keep adding extra timestamps. I hope its the first one else its gonna be reinventing what Zeitgeist is doing as well as adding more complexity that you actually want... cheers Seif
(In reply to comment #3) > AWESOME... > > So one thing that has to be changed is changing the meaning of the > 1) visit timestamp: now its (open + close) and it should be (open) only) > 2) modified timestamp: now its (modify + close) is should be (close only) > > Also you need to add a leave timestamp which happens when some1 closes a > document or movie or so... Okay. > Now my question is do you want recently used to overwrite the timestamps or > keep adding extra timestamps. I hope its the first one else its gonna be > reinventing what Zeitgeist is doing as well as adding more complexity that you > actually want... Well...the design here should probably be that we don't break fallback mode (roughly GNOME 2). So that would imply probably adding new timestamps. But can you link me to an example patch for an application? You mentioned a movie; is there a patch for totem?
sure https://bugzilla.gnome.org/show_bug.cgi?id=640365 I would recommend not storing every timestamp. But actually overwriting the 4 timestamp slots open/close/modify/created Cheers Seif
Please keep in mind that zeitgeist does not handle the content of a file. Zeitgeist is just a big log of everything that ever happened. It is a more structured and extended version of the gtk.recentlmanager.
Note we don't necessarily need to store added data from the new API in ~/.recently-used. We could send some to zeitgiest, and some to the file.
Good Idea. But I would prefer Gtk not depending on Zeitgeist. Its better for you guys TBH. My preference would be just add those timestamp slots in Gtk and Zeitgeist will do the monitoring over gtkRecentlyUsed.
(In reply to comment #8) > Good Idea. But I would prefer Gtk not depending on Zeitgeist. The GtkRecentlyUsed object can talk to anything over DBus; there doesn't have to be any hard shared library dependency. It could be an extension point. > Its better for > you guys TBH. Getting applications to use GTK+ as much as possible is better for us; it provides a coherent developer story. GTK+ gets more API review and more testing. Also there is no "you guys" here - we're working on GNOME.. > My preference would be just add those timestamp slots in Gtk and > Zeitgeist will do the monitoring over gtkRecentlyUsed. Again, the implementation details are less important to me than getting the API in GTK+.
Colin, you may want to look at the Zeitgeist API and its data model to see just what you can feed it (http://zeitgeist-project.com/development/documentation/). Personally I don't think we need to mirror this in GTK+. A commonly-useful subset may be interesting, but we'd need to see what that subset is. A Zeitgeist event has stuff like subject(s) - What is being described? actor - What app made this happen? timestamp - obvious interpretation - What does this mean? manifestation - How did this happen? In turn, the subject has things like URI, mime-type, origin ("web page from which this file was downloaded"), storage medium (UUID of a removable volume). So, it is pretty specific, and something that should be either simplified carefully for GTK+, or not mirrored at all.
About Seif's bug - the problem, as far as I can see it is this: 1. Zeitgeist ideally wants to store fine-grained events. You created a file. You opened a file. You closed the file. You modified the file, etc. - all with a timestamp. Zeitgeist uses this info to compute relevance of related files, useful lifetime of documents, etc. 2. GtkRecentManager, AFAICT, doesn't deal with timestamps at all. Instead it assumes that GBookmarkFile will provide timestmaps as needed --- when you add a bookmark item for a new URI, GBookmarkFile sets its "added" and "modified" timestamps to NOW. It keeps the "visited" timestamp as a default -1, and later, when the bookmark file is being written out, a -1 is turned again into NOW (but by then the visited timestamp may be different from the added/modified ones from creation time). Now, that sounds wrong. Maybe it works in a simplistic way because the recent-files menus so far just sort by any of those timestamps and things happen to work. But this will undoubtedly make Zeitgeist's life harder. It would certainly be nice if apps took care of logging the kind of fine-grained events that Zeitgeist prefers. It's easy to do this directly with the Zeitgeist API. Maybe we can add easy functions for the most common actions - opened a file, closed it, saved a modification, etc., and leave less-common cases as direct calls to Zeitgeist...
I've put our notes from the BoF at the Desktop Summit in Berlin here: https://live.gnome.org/GTK%2B/GtkRecentManagerAndZeitgeist They are pretty raw right now; I'll start detailing them out.
we obviously went a different way with finding and reminding