What I especially like about your update is that you care to have the “Zeitgeist in one sentence” bit. Far too often I see somebody announcing libsplat or a new version of qmwehj or somesuch and I have no idea what it is or if I should care. (In this particular case, I know what Zeitgeist is, so it doesn’t apply to me here, but it’s a good thing in general.)

About Nautilus integration, I think that it is really just a matter of time… To my knowledge no one has looked at this, but the idea seems so obvious that it is bound to happen…

The simplest use case would be:
Having a most used for documents/applicatons of any mimetype. Nothing provides this service.
This can be used to sort search results. Or sort the “recently used” by popularity.

I like your points alot and I will be preparing a big example of apps that are using zeitgeist and how they use it. It would be cool if u can hang out with us at #zeitgeist on freenode

The reason why people keep asking is because you put up ‘fake’ examples like replacing gtkrecentmanager, which indeed is only recent files in general, but per app it’s actually recent document,recent video etc.. That code also serves a very specific use case, it might be slow but i’m sure it could be fixed easily (with time).

I know you talk about a gtkrecentmanager, not recent files, but as long as you keep ‘recent’ i’m will keep bitching about it..
Recently used items is not about anything temporal, it’s taking advantage of
* associative memory humans are equipped with
* the ability to quickly compare and choose among short lists
* The idea (thoroughly tested) that we tend to use the documents we used the last time. Not yesterday or last week, but whatever we did last time we had an app (task) open.

However there are still no actual problems to be solved? If you wan’t people to buy in. They need to see that actual problems for actual users are solved, and especially how this implementation is great for this.

PS: I don’t see any black magic at all. Really. If other people are claiming hand-wavy, it’s lack of communication on your part
PPS: I have seen nemo and gnome activity journal.
PPS: You don’t need to answer, i’m just trying to explain why you need actual users and cases to begin with.

Also, I’ve never said that we intend to show a huge list of recent items where we only show a smaller list now. This is a matter of UI design. I am talking about the capabilities of the daemon. The daemon will provide a highly effient GtkRecentManager and also enable a range of temporal analysis for use in smart GUIs.

And – we are not only talking recent files. We are talking about a log of _all_ your recent activity. IM, email, browsing, tagging, etc. I might have come off with the wrong impression here because I really tried hard to keep it simple and not talk too much about hypothetical use cases.

The daemon can power new GUI types such as the Gnome Activity Journal or Nemo-like interfaces. [links needed, sorry]

While Zeitgeist is to some degree cursed with an aura that we are doing all sorts of hand-wavy black magic the fact is that it is really simple stuff powering all of this. This is also why we will prevail in the end!

How is the ‘list of recent stuff’ with a complete history helpful? The point of recent files 7+-2 elements that any user can quickly manage instead of searching for files, exploring vs. lookup. If we have 50 recent elements the user ends op exploring instead of a simple lookup.

I doubt showing 3 weeks of recent files is helpfull for more than a few. It might even confuse a larger group than it helps. If the problem is that recent manager shows too few, maybe the problem can be fixed somewhere else? My guess is searching, maybe tracker is better for this problem?

Contextual relevance:
If contextual relevance is the only reason for related events, and we don’t know yet how to express contextual relevance or visualize it, then the related events is quite a implementation cost for a journal viewer? I do think a journal viewer is cool – but it’s not for everyone and shouldn’t it be doable without related events? Maybe a journal can be supported by a library API without the need for separate process? It’s not like you need to add a million words a day.

Relating data always gives a nice fuzzy feeling (for some of us, me included), but sometimes we get stuck in data(bases) and not actual use cases… You end up implementing cool databases, without user justification .

Please don’t let the above stop your progress in anyway.