Zeitgeist status update

[Mikkel Kamstrup Erlandsen-2]

Hi,

With the 2.30 module deadline passed it seems appropriate that we give
a status report from the Zeitgeist team.

Since there have been a good deal of confusion about what Zeitgeist
is, and isn't, about I will try clear this up in this mail as well. I
will try to stay low on the buzz word factor and leave some of the
more exotic use cases out to avoid too much speculation.


    * Zeitgeist in 1 sentence

Zeitgeist is an event logging framework used to keep a log of user
activity in a structured way.


    * What new services do we provide for UIs and applications

Zeitgeist provides a DBus API to query and update the activity log.
Clients can query on time ranges, the acting applications, mimetypes,
and Nepomuk classifications of the subjects and events. Sorting can be
done on various criteria such as usage frequency and recent usage.

Concrete examples could be "Get me most used files of mimetypes x,y or
z between the months January till March"

One can also query for documents that are used in context with others.
As in "Which documents/websites are used with http://youtube.com
within the last week".

It is also possible for the applications to get notified when the log
is updated. This is for instance used by the Parental Control
application as well as the GNOME Activity Journal.


    * What Problems can we solve

The straight forward use case is as a GtkRecentManager on drugs.
Zeitgeist removes the need for each application to parse a big XML
file to retrieve recently used documents. It also removes the need to
ever truncate your usage history, our database format is compact and
can easily contain years of history. My estimation is that 1M log
entries will take up about 80mb (give or take 20mb).

Open up for a range of query capabilities that GtkRecentManager
doesn't provide. Instead of simply storing the most recent usage event
on a resource we store all usage events. This way we can not only
answer when the most recent use case was, but also account for the
entire usage history.

One use case that is already in the works is having the most used
resources within the last 3 weeks for an app in the context menu in a
window list. This is for example done in Docky.

Looking past just logging resource usage we will also start monitoring
window and document focus times. This opens up to a whole new world of
contextual relevancy that I wont elaborate on here. I am trying to
stick to the more down to earth aspects of Zeitgeist.


    * Which processes/daemons do we run

Zeitgeist itself is a single DBus daemon. Where the picture gets a
little more fuzzy is how we collect events. The long term goal is for
apps to submit events, maybe hooking directly into GtkRecentManager,
or in any case provide a very convenient way for apps to do this. Apps
like Pidgin or Empathy would probably need some plugin for logging
usage statistics of your contacts.

Right now we resort to less elegant ways of collecting events, like
running a separate daemon harvesting Firefox's history,
GtkRecentlyUsed's and other applications' history (this daemon is also
known as the datahub). The datahub is already on its way to becoming
redundant now that a Firefox extension is in the works (and one for
Epiphany already exist). It is our intent that the datahub should
eventually go away as application support becomes widespread, but it
may eventually still prove useful for usage together with online
service.


    * How resource hungry are we

Normal memory usage is around 5-10mb for the core Zeitgeist daemon.
The datahub process (and I repeat; we want to get rid of this) is
about 12mb.


    * What dependencies

Right now the daemon depends on SQLite, Python 2.5, python-gobject,
python-xdg, and python-dbus. For the datahub we additionally need
python-gconf and python-gtk2, but the datahub is optional.


    * Future plans

We have spend a lot of time planning and designing lately. When we
have a stable reference implementation of our design in Python we plan
to use that as a template for a C implementation. To be clear - the C
version will be log-format and API compatible with the Python version.

We plan to make good use of the upcoming Zeitgeist hackfest and should
have a 0.3 development release ready shortly after. If we are happy
about the 0.3 series we will rename it to 0.9 and go for a 1.0.

Regarding Gnome 3.0 I think we are in a situation much like Owen
Taylor recently outlined for Gnome Shell on the release-team mailing
list[1]. If we are desperate for Zeitgeist to be included in a Gnome
3.0 this March I believe it would be doable. It will require that we
really bust our backs and cut some corners, but it's doable.
Personally (not speaking for the Zeitgeist team here) I am not sure it
would be a very good idea for the same reasons Owen mention.


    * Relation to Tracker and Other Semantic Technologies

The very short version of this is that Tracker and Zeitgeist does not
depend on each other in any way. The catch however is that either one
becomes a whole lot more powerful when working together. To take an
example consider tagging. Zeitgeist is just a log so we don't manage
your tags, we are however fully equipped to understand events
concerning your tags. So you manage the tags via Tracker and track
their usage in Zeitgeist. The combined power enables one to reason
about what tags relate to resources in a temporal manner, even with
resources that are not tagged.

In the Zeitgeist world we call an application like Tracker a
Repository. Nepomuk or Desktop-CouchDB might work as other
Repositories. If there is some confusion in this area it is
understandable, since we do have some Repository-like features in our
0.2 series. This is however removed from the 0.3 series. It is still
undecided if we want to define a minimal Repostiory DBus API for
Zeitgeist and then ship a reference impl. of this API (which would run
in a separate process). Any full fledged Repository would be able own
the Repository service on the bus and Zeitgeist would not run its own.
But again let me stress that a Repository is not needed for the
Zeitgeist Log daemon to be useful.

Cheers,
Mikkel

[1]: See the "Time considerations" section on
http://mail.gnome.org/archives/release-team/2009-November/msg00019.html
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Paul Cutler-3]

Semi-related question:

Zeitgeist is currently hosted on Launchpad.  Are there plans to use GNOME's infrastructure?

Paul

On Tue, Nov 3, 2009 at 4:49 PM, Mikkel Kamstrup Erlandsen <mikkel.kamstrup@...> wrote:

Hi,

With the 2.30 module deadline passed it seems appropriate that we give
a status report from the Zeitgeist team.

Since there have been a good deal of confusion about what Zeitgeist
is, and isn't, about I will try clear this up in this mail as well. I
will try to stay low on the buzz word factor and leave some of the
more exotic use cases out to avoid too much speculation.


   * Zeitgeist in 1 sentence

Zeitgeist is an event logging framework used to keep a log of user
activity in a structured way.


   * What new services do we provide for UIs and applications

Zeitgeist provides a DBus API to query and update the activity log.
Clients can query on time ranges, the acting applications, mimetypes,
and Nepomuk classifications of the subjects and events. Sorting can be
done on various criteria such as usage frequency and recent usage.

Concrete examples could be "Get me most used files of mimetypes x,y or
z between the months January till March"

One can also query for documents that are used in context with others.
As in "Which documents/websites are used with http://youtube.com
within the last week".

It is also possible for the applications to get notified when the log
is updated. This is for instance used by the Parental Control
application as well as the GNOME Activity Journal.


   * What Problems can we solve

The straight forward use case is as a GtkRecentManager on drugs.
Zeitgeist removes the need for each application to parse a big XML
file to retrieve recently used documents. It also removes the need to
ever truncate your usage history, our database format is compact and
can easily contain years of history. My estimation is that 1M log
entries will take up about 80mb (give or take 20mb).

Open up for a range of query capabilities that GtkRecentManager
doesn't provide. Instead of simply storing the most recent usage event
on a resource we store all usage events. This way we can not only
answer when the most recent use case was, but also account for the
entire usage history.

One use case that is already in the works is having the most used
resources within the last 3 weeks for an app in the context menu in a
window list. This is for example done in Docky.

Looking past just logging resource usage we will also start monitoring
window and document focus times. This opens up to a whole new world of
contextual relevancy that I wont elaborate on here. I am trying to
stick to the more down to earth aspects of Zeitgeist.


   * Which processes/daemons do we run

Zeitgeist itself is a single DBus daemon. Where the picture gets a
little more fuzzy is how we collect events. The long term goal is for
apps to submit events, maybe hooking directly into GtkRecentManager,
or in any case provide a very convenient way for apps to do this. Apps
like Pidgin or Empathy would probably need some plugin for logging
usage statistics of your contacts.

Right now we resort to less elegant ways of collecting events, like
running a separate daemon harvesting Firefox's history,
GtkRecentlyUsed's and other applications' history (this daemon is also
known as the datahub). The datahub is already on its way to becoming
redundant now that a Firefox extension is in the works (and one for
Epiphany already exist). It is our intent that the datahub should
eventually go away as application support becomes widespread, but it
may eventually still prove useful for usage together with online
service.


   * How resource hungry are we

Normal memory usage is around 5-10mb for the core Zeitgeist daemon.
The datahub process (and I repeat; we want to get rid of this) is
about 12mb.


   * What dependencies

Right now the daemon depends on SQLite, Python 2.5, python-gobject,
python-xdg, and python-dbus. For the datahub we additionally need
python-gconf and python-gtk2, but the datahub is optional.


   * Future plans

We have spend a lot of time planning and designing lately. When we
have a stable reference implementation of our design in Python we plan
to use that as a template for a C implementation. To be clear - the C
version will be log-format and API compatible with the Python version.

We plan to make good use of the upcoming Zeitgeist hackfest and should
have a 0.3 development release ready shortly after. If we are happy
about the 0.3 series we will rename it to 0.9 and go for a 1.0.

Regarding Gnome 3.0 I think we are in a situation much like Owen
Taylor recently outlined for Gnome Shell on the release-team mailing
list[1]. If we are desperate for Zeitgeist to be included in a Gnome
3.0 this March I believe it would be doable. It will require that we
really bust our backs and cut some corners, but it's doable.
Personally (not speaking for the Zeitgeist team here) I am not sure it
would be a very good idea for the same reasons Owen mention.


   * Relation to Tracker and Other Semantic Technologies

The very short version of this is that Tracker and Zeitgeist does not
depend on each other in any way. The catch however is that either one
becomes a whole lot more powerful when working together. To take an
example consider tagging. Zeitgeist is just a log so we don't manage
your tags, we are however fully equipped to understand events
concerning your tags. So you manage the tags via Tracker and track
their usage in Zeitgeist. The combined power enables one to reason
about what tags relate to resources in a temporal manner, even with
resources that are not tagged.

In the Zeitgeist world we call an application like Tracker a
Repository. Nepomuk or Desktop-CouchDB might work as other
Repositories. If there is some confusion in this area it is
understandable, since we do have some Repository-like features in our
0.2 series. This is however removed from the 0.3 series. It is still
undecided if we want to define a minimal Repostiory DBus API for
Zeitgeist and then ship a reference impl. of this API (which would run
in a separate process). Any full fledged Repository would be able own
the Repository service on the bus and Zeitgeist would not run its own.
But again let me stress that a Repository is not needed for the
Zeitgeist Log daemon to be useful.

Cheers,
Mikkel

[1]: See the "Time considerations" section on
http://mail.gnome.org/archives/release-team/2009-November/msg00019.html
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Mikkel Kamstrup Erlandsen-2]

2009/11/4 Paul Cutler <pcutler@...>:
> Semi-related question:
>
> Zeitgeist is currently hosted on Launchpad.  Are there plans to use GNOME's
> infrastructure?

Everyone: Please don't let this turn into a VCS flamefest

Note that this is my own view of things and not the official opinion
of the Zeitgeist team. We've talked a bit about moving. I think the
consensus is that most of the Zeitgeist developers (read: all) prefer
Bazaar over Git, and that time pressure has mandated us to stick to
the tools we work fastest with.

That said we probably have to move our infrastructure if we want to
become an official part of Gnome, no matter the development time it
will cost us (and thus Gnome as a whole). It has just not been a high
priority.

Cheers,
Mikkel
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Olafur Arason]

Are you looking into some situation integration, like integrating information
from Hamster. A course example of that would be that you use different
application, documents in work that at home. A more fine grate example
would be if you are working on art, surfing, finance you would get
programs that you use in that situations.

That could be integrated into NetworkManager where it would try to see
patterns based on situational information, from Hamster or other
application that log these kinds of things. VPN, Proxy, preferred Internet
connections are a couple of examples of that. NM could ask the Zeitgeist
demon what configurations to use.

Then you could search "The document I was working on at work around
10 am"

Regards,
Olafur Arason

On Tue, Nov 3, 2009 at 9:49 PM, Mikkel Kamstrup Erlandsen
<mikkel.kamstrup@...> wrote:

> Hi,
>
> With the 2.30 module deadline passed it seems appropriate that we give
> a status report from the Zeitgeist team.
>
> Since there have been a good deal of confusion about what Zeitgeist
> is, and isn't, about I will try clear this up in this mail as well. I
> will try to stay low on the buzz word factor and leave some of the
> more exotic use cases out to avoid too much speculation.
>
>
>    * Zeitgeist in 1 sentence
>
> Zeitgeist is an event logging framework used to keep a log of user
> activity in a structured way.
>
>
>    * What new services do we provide for UIs and applications
>
> Zeitgeist provides a DBus API to query and update the activity log.
> Clients can query on time ranges, the acting applications, mimetypes,
> and Nepomuk classifications of the subjects and events. Sorting can be
> done on various criteria such as usage frequency and recent usage.
>
> Concrete examples could be "Get me most used files of mimetypes x,y or
> z between the months January till March"
>
> One can also query for documents that are used in context with others.
> As in "Which documents/websites are used with http://youtube.com
> within the last week".
>
> It is also possible for the applications to get notified when the log
> is updated. This is for instance used by the Parental Control
> application as well as the GNOME Activity Journal.
>
>
>    * What Problems can we solve
>
> The straight forward use case is as a GtkRecentManager on drugs.
> Zeitgeist removes the need for each application to parse a big XML
> file to retrieve recently used documents. It also removes the need to
> ever truncate your usage history, our database format is compact and
> can easily contain years of history. My estimation is that 1M log
> entries will take up about 80mb (give or take 20mb).
>
> Open up for a range of query capabilities that GtkRecentManager
> doesn't provide. Instead of simply storing the most recent usage event
> on a resource we store all usage events. This way we can not only
> answer when the most recent use case was, but also account for the
> entire usage history.
>
> One use case that is already in the works is having the most used
> resources within the last 3 weeks for an app in the context menu in a
> window list. This is for example done in Docky.
>
> Looking past just logging resource usage we will also start monitoring
> window and document focus times. This opens up to a whole new world of
> contextual relevancy that I wont elaborate on here. I am trying to
> stick to the more down to earth aspects of Zeitgeist.
>
>
>    * Which processes/daemons do we run
>
> Zeitgeist itself is a single DBus daemon. Where the picture gets a
> little more fuzzy is how we collect events. The long term goal is for
> apps to submit events, maybe hooking directly into GtkRecentManager,
> or in any case provide a very convenient way for apps to do this. Apps
> like Pidgin or Empathy would probably need some plugin for logging
> usage statistics of your contacts.
>
> Right now we resort to less elegant ways of collecting events, like
> running a separate daemon harvesting Firefox's history,
> GtkRecentlyUsed's and other applications' history (this daemon is also
> known as the datahub). The datahub is already on its way to becoming
> redundant now that a Firefox extension is in the works (and one for
> Epiphany already exist). It is our intent that the datahub should
> eventually go away as application support becomes widespread, but it
> may eventually still prove useful for usage together with online
> service.
>
>
>    * How resource hungry are we
>
> Normal memory usage is around 5-10mb for the core Zeitgeist daemon.
> The datahub process (and I repeat; we want to get rid of this) is
> about 12mb.
>
>
>    * What dependencies
>
> Right now the daemon depends on SQLite, Python 2.5, python-gobject,
> python-xdg, and python-dbus. For the datahub we additionally need
> python-gconf and python-gtk2, but the datahub is optional.
>
>
>    * Future plans
>
> We have spend a lot of time planning and designing lately. When we
> have a stable reference implementation of our design in Python we plan
> to use that as a template for a C implementation. To be clear - the C
> version will be log-format and API compatible with the Python version.
>
> We plan to make good use of the upcoming Zeitgeist hackfest and should
> have a 0.3 development release ready shortly after. If we are happy
> about the 0.3 series we will rename it to 0.9 and go for a 1.0.
>
> Regarding Gnome 3.0 I think we are in a situation much like Owen
> Taylor recently outlined for Gnome Shell on the release-team mailing
> list[1]. If we are desperate for Zeitgeist to be included in a Gnome
> 3.0 this March I believe it would be doable. It will require that we
> really bust our backs and cut some corners, but it's doable.
> Personally (not speaking for the Zeitgeist team here) I am not sure it
> would be a very good idea for the same reasons Owen mention.
>
>
>    * Relation to Tracker and Other Semantic Technologies
>
> The very short version of this is that Tracker and Zeitgeist does not
> depend on each other in any way. The catch however is that either one
> becomes a whole lot more powerful when working together. To take an
> example consider tagging. Zeitgeist is just a log so we don't manage
> your tags, we are however fully equipped to understand events
> concerning your tags. So you manage the tags via Tracker and track
> their usage in Zeitgeist. The combined power enables one to reason
> about what tags relate to resources in a temporal manner, even with
> resources that are not tagged.
>
> In the Zeitgeist world we call an application like Tracker a
> Repository. Nepomuk or Desktop-CouchDB might work as other
> Repositories. If there is some confusion in this area it is
> understandable, since we do have some Repository-like features in our
> 0.2 series. This is however removed from the 0.3 series. It is still
> undecided if we want to define a minimal Repostiory DBus API for
> Zeitgeist and then ship a reference impl. of this API (which would run
> in a separate process). Any full fledged Repository would be able own
> the Repository service on the bus and Zeitgeist would not run its own.
> But again let me stress that a Repository is not needed for the
> Zeitgeist Log daemon to be useful.
>
> Cheers,
> Mikkel
>
> [1]: See the "Time considerations" section on
> http://mail.gnome.org/archives/release-team/2009-November/msg00019.html
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list@...
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Mikkel Kamstrup Erlandsen-2]

2009/11/4 Olafur Arason <olafra@...>:
> Are you looking into some situation integration, like integrating information
> from Hamster. A course example of that would be that you use different
> application, documents in work that at home.

To my knowledge we have not tried to integrate directly with Hamster
yet, although that seems like a very obvious are where we could
cooperate.

That said, Hamster has been kept in mind when designing our internal
framework. So I think that Hamster would be able to use Zeitgeist as
backend. This needs further investigation though.

> A more fine grate example
> would be if you are working on art, surfing, finance you would get
> programs that you use in that situations.

There has already been sample implementations of apps using Zeitgeist
to come up with very good guesses of apps, people, or documents that
would be relevant in your current context. Fairly successful I might
add, but mostly done as pilot projects (read: I am not sure there are
public repos with code).

> That could be integrated into NetworkManager where it would try to see
> patterns based on situational information, from Hamster or other
> application that log these kinds of things. VPN, Proxy, preferred Internet
> connections are a couple of examples of that. NM could ask the Zeitgeist
> demon what configurations to use.

I am not convinced that this would be a good idea, but in theory it
should be possible to do something like that.

> Then you could search "The document I was working on at work around
> 10 am"

This is a straight forward application of the query API we expose.

Cheers,
Mikkel

> On Tue, Nov 3, 2009 at 9:49 PM, Mikkel Kamstrup Erlandsen
> <mikkel.kamstrup@...> wrote:
>> Hi,
>>
>> With the 2.30 module deadline passed it seems appropriate that we give
>> a status report from the Zeitgeist team.
>>
>> Since there have been a good deal of confusion about what Zeitgeist
>> is, and isn't, about I will try clear this up in this mail as well. I
>> will try to stay low on the buzz word factor and leave some of the
>> more exotic use cases out to avoid too much speculation.
>>
>>
>>    * Zeitgeist in 1 sentence
>>
>> Zeitgeist is an event logging framework used to keep a log of user
>> activity in a structured way.
>>
>>
>>    * What new services do we provide for UIs and applications
>>
>> Zeitgeist provides a DBus API to query and update the activity log.
>> Clients can query on time ranges, the acting applications, mimetypes,
>> and Nepomuk classifications of the subjects and events. Sorting can be
>> done on various criteria such as usage frequency and recent usage.
>>
>> Concrete examples could be "Get me most used files of mimetypes x,y or
>> z between the months January till March"
>>
>> One can also query for documents that are used in context with others.
>> As in "Which documents/websites are used with http://youtube.com
>> within the last week".
>>
>> It is also possible for the applications to get notified when the log
>> is updated. This is for instance used by the Parental Control
>> application as well as the GNOME Activity Journal.
>>
>>
>>    * What Problems can we solve
>>
>> The straight forward use case is as a GtkRecentManager on drugs.
>> Zeitgeist removes the need for each application to parse a big XML
>> file to retrieve recently used documents. It also removes the need to
>> ever truncate your usage history, our database format is compact and
>> can easily contain years of history. My estimation is that 1M log
>> entries will take up about 80mb (give or take 20mb).
>>
>> Open up for a range of query capabilities that GtkRecentManager
>> doesn't provide. Instead of simply storing the most recent usage event
>> on a resource we store all usage events. This way we can not only
>> answer when the most recent use case was, but also account for the
>> entire usage history.
>>
>> One use case that is already in the works is having the most used
>> resources within the last 3 weeks for an app in the context menu in a
>> window list. This is for example done in Docky.
>>
>> Looking past just logging resource usage we will also start monitoring
>> window and document focus times. This opens up to a whole new world of
>> contextual relevancy that I wont elaborate on here. I am trying to
>> stick to the more down to earth aspects of Zeitgeist.
>>
>>
>>    * Which processes/daemons do we run
>>
>> Zeitgeist itself is a single DBus daemon. Where the picture gets a
>> little more fuzzy is how we collect events. The long term goal is for
>> apps to submit events, maybe hooking directly into GtkRecentManager,
>> or in any case provide a very convenient way for apps to do this. Apps
>> like Pidgin or Empathy would probably need some plugin for logging
>> usage statistics of your contacts.
>>
>> Right now we resort to less elegant ways of collecting events, like
>> running a separate daemon harvesting Firefox's history,
>> GtkRecentlyUsed's and other applications' history (this daemon is also
>> known as the datahub). The datahub is already on its way to becoming
>> redundant now that a Firefox extension is in the works (and one for
>> Epiphany already exist). It is our intent that the datahub should
>> eventually go away as application support becomes widespread, but it
>> may eventually still prove useful for usage together with online
>> service.
>>
>>
>>    * How resource hungry are we
>>
>> Normal memory usage is around 5-10mb for the core Zeitgeist daemon.
>> The datahub process (and I repeat; we want to get rid of this) is
>> about 12mb.
>>
>>
>>    * What dependencies
>>
>> Right now the daemon depends on SQLite, Python 2.5, python-gobject,
>> python-xdg, and python-dbus. For the datahub we additionally need
>> python-gconf and python-gtk2, but the datahub is optional.
>>
>>
>>    * Future plans
>>
>> We have spend a lot of time planning and designing lately. When we
>> have a stable reference implementation of our design in Python we plan
>> to use that as a template for a C implementation. To be clear - the C
>> version will be log-format and API compatible with the Python version.
>>
>> We plan to make good use of the upcoming Zeitgeist hackfest and should
>> have a 0.3 development release ready shortly after. If we are happy
>> about the 0.3 series we will rename it to 0.9 and go for a 1.0.
>>
>> Regarding Gnome 3.0 I think we are in a situation much like Owen
>> Taylor recently outlined for Gnome Shell on the release-team mailing
>> list[1]. If we are desperate for Zeitgeist to be included in a Gnome
>> 3.0 this March I believe it would be doable. It will require that we
>> really bust our backs and cut some corners, but it's doable.
>> Personally (not speaking for the Zeitgeist team here) I am not sure it
>> would be a very good idea for the same reasons Owen mention.
>>
>>
>>    * Relation to Tracker and Other Semantic Technologies
>>
>> The very short version of this is that Tracker and Zeitgeist does not
>> depend on each other in any way. The catch however is that either one
>> becomes a whole lot more powerful when working together. To take an
>> example consider tagging. Zeitgeist is just a log so we don't manage
>> your tags, we are however fully equipped to understand events
>> concerning your tags. So you manage the tags via Tracker and track
>> their usage in Zeitgeist. The combined power enables one to reason
>> about what tags relate to resources in a temporal manner, even with
>> resources that are not tagged.
>>
>> In the Zeitgeist world we call an application like Tracker a
>> Repository. Nepomuk or Desktop-CouchDB might work as other
>> Repositories. If there is some confusion in this area it is
>> understandable, since we do have some Repository-like features in our
>> 0.2 series. This is however removed from the 0.3 series. It is still
>> undecided if we want to define a minimal Repostiory DBus API for
>> Zeitgeist and then ship a reference impl. of this API (which would run
>> in a separate process). Any full fledged Repository would be able own
>> the Repository service on the bus and Zeitgeist would not run its own.
>> But again let me stress that a Repository is not needed for the
>> Zeitgeist Log daemon to be useful.
>>
>> Cheers,
>> Mikkel
>>
>> [1]: See the "Time considerations" section on
>> http://mail.gnome.org/archives/release-team/2009-November/msg00019.html
>> _______________________________________________
>> desktop-devel-list mailing list
>> desktop-devel-list@...
>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>

--
Cheers,
Mikkel
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Richard Henwood-2]

Hi All,

Following the thread, re: Zeitgeist and Hamster, I thought I would introduce myself and a small project I've been working on, called (unashamedly)
gnome-workspacetime
http://sites.google.com/site/richardhenwood/gnome-workspacetime

I wrote the tool to audit my desktop activities automatically - particularly for the purposes of identifying exactly how much time I spend doing 'work'. It achieves this requirement in my case.

Surprising, my colleagues have been far from enthusiastic about auditing their own daily activities. However, the recent discussion on Zeitgiest and the related Hamster made me this that I should advertise my (modest) efforts in this area.

This project is in slow development, and I look forward to my work being eclipsed by other established projects.

Best regards,
Richard


     
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Andreas Nilsson]

On 11/03/2009 10:49 PM, Mikkel Kamstrup Erlandsen wrote:
>      * Zeitgeist in 1 sentence
>
> Zeitgeist is an event logging framework used to keep a log of user
> activity in a structured way.
>
> It is also possible for the applications to get notified when the log
> is updated. This is for instance used by the Parental Control
> application as well as the GNOME Activity Journal.
>    
These seems like the interesting part (as it's actual user experience,
not just data-blah), the rest is pretty much over my head. :)

Looking around a bit I was able to find:
* Parental Control: http://live.gnome.org/Parental-Control
* Activity Journal: https://launchpad.net/gnome-zeitgeist

What happened to the zeitgeist/gnome-shell integration [1]?

1.
http://socghop.appspot.com/student_project/show/google/gsoc2009/gnome/t124022404309
- Andreas
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Siegfried-Angel Gevatter Pujals]

Hi,

2009/11/5 Andreas Nilsson <nisses.mail@...>:
> These seems like the interesting part (as it's actual user experience, not
> just data-blah), the rest is pretty much over my head. :)

Well, what's currently available in the form of GUIs is only the tip
of the iceberg of what the engine will make possible :).

> What happened to the zeitgeist/gnome-shell integration [1]?

I've got a working branch with some features (fetching recent docs
from Zeitgeist instead of GtkRecentlyUsed -Zeitgeist has way more
data-, showing relevant documents when an application was selected,
tagging, etc.; there are a couple videos on YouTube if you're curious)
but it doesn't apply against the current code-base anymore.

Some weeks ago I proposed a first reworked patch for the basic
integration (replacing GtkRecentlyUsed) and I planned to continue
submitting patches for the remaining features once that was accepted,
but it's still waiting to be reviewed. Anyway, given that we are
currently discussing some big changes for the next Zeitgeist release,
I think I'll wait until said new Zeitgeist version is out before doing
any more work on Shell.

Cheers,

--
Siegfried-Angel Gevatter Pujals (RainCT)
Free Software Developer       363DEAE3
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Olafur Arason]

I know it's probably a mean question because you cant compare
two different things together. But is Zeitgeist like Nat's Dashboard?
I only ask because the parent control thing looks awfully like
what Dashboard was doing.

Regards,
Olafur Arason

On Thu, Nov 5, 2009 at 9:37 PM, Andreas Nilsson <nisses.mail@...> wrote:

> On 11/03/2009 10:49 PM, Mikkel Kamstrup Erlandsen wrote:
>>
>>     * Zeitgeist in 1 sentence
>>
>> Zeitgeist is an event logging framework used to keep a log of user
>> activity in a structured way.
>>
>> It is also possible for the applications to get notified when the log
>> is updated. This is for instance used by the Parental Control
>> application as well as the GNOME Activity Journal.
>>
>
> These seems like the interesting part (as it's actual user experience, not
> just data-blah), the rest is pretty much over my head. :)
>
> Looking around a bit I was able to find:
> * Parental Control: http://live.gnome.org/Parental-Control
> * Activity Journal: https://launchpad.net/gnome-zeitgeist
>
> What happened to the zeitgeist/gnome-shell integration [1]?
>
> 1.
> http://socghop.appspot.com/student_project/show/google/gsoc2009/gnome/t124022404309
> - Andreas
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list@...
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Mikkel Kamstrup Erlandsen-2]

2009/11/6 Olafur Arason <olafra@...>:
> I know it's probably a mean question because you cant compare
> two different things together. But is Zeitgeist like Nat's Dashboard?
> I only ask because the parent control thing looks awfully like
> what Dashboard was doing.

To be clear Zeitgeist here is just the engine, a dbus service, so
there is no GUI.

That said we have experiented with something similar to Dashboard and
the engine is indeed capable of driving such a thing, if one adds
another layer of voodoo to the logic. Seif is really the expert here
so I shall omit the details.

But such use cases are not very high priority right now. We focus on
getting the simple things to work.

Cheers,
Mikkel

> On Thu, Nov 5, 2009 at 9:37 PM, Andreas Nilsson <nisses.mail@...> wrote:
>> On 11/03/2009 10:49 PM, Mikkel Kamstrup Erlandsen wrote:
>>>
>>>     * Zeitgeist in 1 sentence
>>>
>>> Zeitgeist is an event logging framework used to keep a log of user
>>> activity in a structured way.
>>>
>>> It is also possible for the applications to get notified when the log
>>> is updated. This is for instance used by the Parental Control
>>> application as well as the GNOME Activity Journal.
>>>
>>
>> These seems like the interesting part (as it's actual user experience, not
>> just data-blah), the rest is pretty much over my head. :)
>>
>> Looking around a bit I was able to find:
>> * Parental Control: http://live.gnome.org/Parental-Control
>> * Activity Journal: https://launchpad.net/gnome-zeitgeist
>>
>> What happened to the zeitgeist/gnome-shell integration [1]?
>>
>> 1.
>> http://socghop.appspot.com/student_project/show/google/gsoc2009/gnome/t124022404309
>> - Andreas
>> _______________________________________________
>> desktop-devel-list mailing list
>> desktop-devel-list@...
>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list@...
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list