Re: Module Proposal: Zeitgeist

I've talked to several of my coworkers, and they just think Zeitgeist
is the right technology for anything they're trying to do. A number of
people thought the time-based approach wasn't neat enough. They
brought up the recent flames over the "Recently Used" selection by
default in the GtkFileChooser. We have a design and a plan for finding
and reminding, and Zeitgeist doesn't seem like the right technology to
implement that plan. Some didn't like that Zeitgeist tried to record
practically everything you did, they found it creepy.

There might be an stigma against Zeitgeist, sure. But on the whole,
I'm going to agree with them: Zeitgeist *isn't* the right technology
for our finding and reminding strategy.

On Sat, Apr 21, 2012 at 12:42 PM, Seif Lotfy <seif lotfy com> wrote:
> I would like to quote Allan Day (from another public mail thread):
> ---
> I realise that you're frustrated by the lack of Zeitgeist adoption in
> GNOME, Seif. As I explained privately, the best way for you to pursue
> this is to talk to maintainers who might need it for search results.
> The decision to use Zeitgeist is really up to them.
> Allan
> ---
> I won't deny my frustration but I leared to live with it :P
> So let me ask a direct question:
> Is there any objections for a GNOME application/library/service
> whether core or not, to have a full dependency on Zeitgeist whether
> for technical reasons (optimization or features) or a UX reasons?
> If yes, then the chicken and egg problem is solved (for example Web is
> blessed to use Zeitgeist as its history storage)
> If no, what are the reasons? If the answer for that is propose a
> feature, (then we are back in the chicken and egg loop)
> Sometimes technical issues should be considered valid. So application
> maintainers don't have to take care of their logs (some technical
> outsourcing :P)
> Cheers
> Seif
> On Tue, Apr 17, 2012 at 10:47 PM, Seif Lotfy <seif lotfy com> wrote:
>> Purpose:
>> Zeitgeist is an event logging framework. It stores user activity in a
>> structured manner and provides a powerful DBus API to query and monitor the
>> log. Zeitgeist as such does not have a graphical component, but is intended
>> to integrate wherever it makes sense. Just like Tracker, Folks and
>> GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by
>> the user directly, but rather would allow developers to harnest the feature
>> it provides and make something useful out of it in their UX.
>> Preamble:
>> It has been 3 years and 8 month since Zeitgeist started under the GNOME
>> umbrella. We proposed Zeitgeist for inclusion in 2010 but we got rejected
>> due to several reasons including but not limited to:
>> Not enough integration with GNOME applications
>> Project hosting difficulties
>> Immaturity of the project.
>> Zeitgeist is not meant for searching through your files and folders, but
>> rather as a log for user activities. This can be used for:
>> Sorting search results according to frequency/recency
>> Populating dashboards
>> Finding files/contacts/etc... that are used together
>> History browser
>> Associating locations to items (used at location X or Y)
>> scheduling activities (files/contacts/et...) can be set (See Task pooper)
>> People have expressed interest in using it within GNOME, we want to help and
>> make it happen. We think all these use cases could be address.
>> We already have GNOME specific developments:
>> We already log everything that pushes into Gtk.RecentlyUsed.
>> For better logging we have Totem, Rhythmbox, and gedit deploying loggers as
>> a soft-dependency in the form of plugins.
>> We worked with gedit and some GNOME designers to develop the Dashboard
>> plugin [1] to address the empty slate problem.
>> Additionally, the team wrote several plugins for GNOME Shell [2][3][4]
>> Integration with telepathy-folks is currently under development.
>> Discussion about a possible Gtk Recenet Manager revamp with an optional
>> Zeitgeist backend. [5]
>> Another deployment in development is a feature that we think would enrich
>> the developer story for folks, which is giving folks the ability to actually
>> provide developers with some interaction details for each individual. [6]
>> This is under development and hopefully can be merged soon.
>> We also provide a logger for Telepathy as part of the zeitgeist-datasources
>> package. It will soon be shipped directly with Telepathy-Logger as a
>> soft-dependency.
>> We have moved to so we can play nicely with GNOME, KDE,
>> Ubuntu as well as others. [7]
>> Since we are not a GNOME dependency some projects hesitate to integrate with
>> us.
>> It is a chicken and egg problem. Applications don't want to depend on us
>> since we are not GNOME upstream (thus only soft-dependencies) and GNOME
>> hesitates to accept Zeitgeist since no application fully depends on it.
>> For example: We want to use Zeitgeist in GNOME Clocks will to store "alarms"
>> as scheduled activities. However we are not sure if we can do that without
>> Zeitgeist being an external dependency.
>> Another example, Epiphany integration: Zeitgeist could take over
>> storing Epiphany history. However due to the uncertain state of Zeitgeist in
>> GNOME we can not move on.
>> I would like to quote Xan Lopez: if GNOME decides to use it throughout I'd
>> be happy to add support for it in Epiphany.
>> Some interesting facts about Zeitgeist:
>> It is a dependency for Ubuntu Unity
>> Many application specific plugins that make use of what Zeitgeist has got to
>> offer.
>> Integration into Phonon, the KDE multimedia framework and
>> various deployments within KDE
>> Deploying in Dawati [0]
>> Paid dedicated developers
>> Previously ported from Python to Vala without breaking API
>> Proposal to become a blessed dependency
>> With this appliation I would like to address the possibility of accepting
>> Zeitgeist as a blessed dependency.
>> Dependencies:
>> Vala
>> Sqlite
>> Xapian (Soft)
>> python-rdflib (only for compiling the ontologies)
>> Resource usage:
>> Bug tracker:
>> VCS:
>> Other notes:
>> What most people think of as Zeitgeist is split in two processes
>> zeitgeist-daemon and zeitgeist-datahub. The daemon does not do any active
>> monitoring for events, it only manages the log database and exposes a DBus
>> interface for inserting, deleting, querying events, and monitoring for
>> changes. The datahub monitors the system and pushes events into the daemon.
>> This architecture makes the datahub expendable if we one day move to an
>> architecture where apps themselves (or something else) push events into
>> Zeitgeist. Indeed it's already the case that we have plugins for some apps
>> that makes them push events into the daemon.
>> [0]
>> [1]
>> [2]
>> [3]
>> [4]
>> [5]
>> [6]
>> [7]
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]