Aggregating document events through window focus

Registered by Seif Lotfy

Aggregating document events through window focus. This way we can determine document context usage better!

Blueprint information

Seif Lotfy
Seif Lotfy
Seif Lotfy
Pending Approval
Series goal:
Needs Infrastructure
Milestone target:
Started by
Seif Lotfy



Basically we monitor when a window gets the focus. Try to figure out the title and the app. Format a string and compare with the DB "Which subject was last triggered from application "xxx" that has the title "yyy"". We then insert an a focus event into th main log. This feature is done but has to be adjusted for each app. It is not a big deal though.

It will allow us to:
- calculate a focus lifetime of each document. This would be neat since search engines would be able to prioritize their results over how long was something in focus,.
- the contextual relevancy depends on it.

The focus events will be stored in 2 new tables
| from_app | from_doc | timestamp | to_app | to_doc | ==> for querying what was mostly focused to/from from/to documents x
| app | doc | focus_in | focus_out | ==> for querying how long did document x have the focus

Now we the development of new external dataproviders i would to suggest every external dataprovider exposing also subscribing to wnck and when it figures out it has the focus it just pushed what it has in focus into zeitgeist. Problem is what happens if the app in focus does not support pushing into Zeitgeist. This will manipulate the focus stuff in zeitgeist.

The other solution would be having a wnck monitor that is signaled with every monitor switch and the extracts the title and the app from the signal and look for the latest "OPEN" or "MODFIY" event in the database whose subject and app resemble that of the signal. This would take care of the window focus. I managed to get gedit to tell me when a tab swtich happens and we should do the same with firefox and other apps.

*** Approval:
I think this is essential: +1 for approval
RainCT: +1 as long as it's in a separate table/DB
kamstrup: +1 (see comments below)

*** Comments:
kamstrup: As consensus is we keep the graph in a separate db, this is ok to start out with. But it troubles me that people crop up with needs to create custom dbs every now and then. Zeitgeist should be able to create "private" logs and maybe also other private data structures (fx. "graph storage" doesn't fit smoothly into our normal log structure so we might have to come up with something here as well). But the finer details better wait until we have a working event graph - so we know what we are dealing with.


kamstrup: Just a reminder - nothing that matters for the approval of this blueprint; but the Gnome Shell team is working on something to be able to figure out which tab an app is showing to be able to do breadcrumbs in the panel. From our POW tab==document, so we are very interested in having a non-hackinsh way of extracting what document an app is viewing. Perhaps we need to track their progress and maybe influence them to ensure that the solution is useful to us as well... Just a thought...


Seif: I am setting this blueprint as closed since i think our apriori approach is good enough for now. Later when we see progress form the shell side i will reopen this blueprint

UPDATE: I will be implementing an extension with a new DB for this... Will upload the design ASAP


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.