After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 535863 - D-Bus interface for tracking events
D-Bus interface for tracking events
Status: RESOLVED FIXED
Product: hamster-applet
Classification: Deprecated
Component: general
unspecified
Other Linux
: Low enhancement
: ---
Assigned To: J. Félix Ontañón
hamster-applet-maint
Depends on:
Blocks: 529112
 
 
Reported: 2008-05-31 00:59 UTC by Anders Feder
Modified: 2008-09-28 21:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Hamster-DBus Screenshot (75.59 KB, image/png)
2008-07-30 19:39 UTC, J. Félix Ontañón
  Details
Patch from HEAD version (at r369) with DBUS branch (6.14 KB, patch)
2008-08-12 12:28 UTC, Juanje Ojeda
none Details | Review

Description Anders Feder 2008-05-31 00:59:36 UTC
Implement a D-Bus interface that will allow other programs to add "facts" to
Hamster, so e.g. a word processor can add an entry when the user begins editing a document, or a stand-alone program can add entries when the user leaves (x minutes of inactivity) and returns to the computer, for instance.

Program should only add entries to Hamster when that feature is explicitly enabled by the user, to avoid clogging the log.

Possibly ask similar Linux software projects to collaborate on such a interface, for the sake of compatibility.
Comment 1 Toms Bauģis 2008-05-31 12:11:50 UTC
Hi Anders,

I don't really see any practical implementations of such interface. 
Although hamster is not tracking open applications, because i doubt value of this information, still, if it would have to - then there are plethora of ways, figuring out, what's currently going on with the desktop.

Another application, or plug-in, that would command hamster, i see as a hack, and should be solved in hamster itself.
Comment 2 Anders Feder 2008-05-31 12:27:36 UTC
Hamster often would not have access to anywhere near the same range of information about the user's context as an application would.

Exactly because there is a plethora of ways to figure out what is going on on the desktop, Hamster should allow third parties to assist, with the user's acceptance - it's not possible to include every possible way of tracking user activities in Hamster itself.

For instance, an e-mail application could automatically add an entry reading "Composing e-mail for John Doe", while a time tracking application might at best add an entry reading "Running e-mail client", which would be of little use.

Plug-ins are the exact opposite of a hack in my opinion. It elegantly counters bloat, lets the user pick only the exact features she wish and gives the main program access to a wider range of information.

Just a suggestion, of course, but I do feel that a third-party API would be perfect for Hamster.
Comment 3 Toms Bauģis 2008-06-02 10:55:27 UTC
It seems to me, that sometimes with plugins one solves organizational questions, not really questions related to product. Also, as it goes for all user-configurable options - plugins can emerge when a compromise can not be achieved for personal reasons, or when developer hasn't moved his brain tooo much - "How much sugar should we add to the coffee? - Let's make it a slider from 0-10! So everyone of our users would be happy, although the recent survey, which we didn't make, clearly states that everybody uses exactly 1 tea-spoon of sugar." (not related to actual word, but just trying to make a point here)

This is what i would be afraid of.

Anyway - i might be wrong as well, so let's keep this bug.

Comment 4 Anders Feder 2008-06-02 19:25:52 UTC
I see your point, but in cases where a comprise can not be achieved anyway, is the alternative not usually to abandon the idea altogether?

Besides, in most cases, an interface like this would be used in professional-grade applications (e.g. Evolution) that themselves have a broad customer base and the ensuing usability concerns to tend to.
Comment 5 Sandy Armstrong 2008-07-30 13:55:09 UTC
I happen to really like Anders's idea.  In addition, it is becoming almost expected of GNOME apps to offer a dbus interface to let other apps interact with them.

Using hamster through dbus does not mean that the hamster UI is failing in any way, it just opens the door for other interactions.  For example, I use dbus so that when I change my nick in xchat-gnome to indicate that I'm away, it updates my pidgin status and pauses Banshee for me.  The key here is *automation*.

In addition, looking at bug #529112 (writing a gnome-do plugin), there is a whole class of users emerging that wants to do their simple tasks from Do or a similar app.  These users may love hamster, but don't want to remember yet another hot key.  They become used to executing simple actions through the Do launcher interface.  Again, usage of the dbus interface is not a failure in hamster; it just enables additional usage patterns.

I think supporting automation and remote control via dbus is a key part of being a good citizen on the GNOME desktop.  Just my 2 cents.  ;-)
Comment 6 J. Félix Ontañón 2008-07-30 19:39:50 UTC
Created attachment 115581 [details]
Hamster-DBus Screenshot

Using the DBus Debugger D-Feet you can see how the get_activity dbus method works showing the current activity and time.
Comment 7 J. Félix Ontañón 2008-07-30 19:40:12 UTC
Hi all!

It happens that i've been working to add "read-only" dbus interface for hamster with the pruporse of export the current activity and other interesting data.

My own goal it's to be able to write plugins that using these exported values via dbus can communicate hamster with other applications as Pidgin.

Right now i've added a functional dbus interface that has a get_activity() dbus-method for get the current activity and i'm finishing the Pidgin status-message plugin based on AmarokPlugin (not so easy 'cause it's dcop based).

A minimal change on applet.py it's needed and import my hamsterdbus.py that encapsulates the dbus methods and logic.

I can free this modifications if you think it's interesting.

I attach a screenshot to ilustrate it.

Just my 2 cents too :)
Comment 8 J. Félix Ontañón 2008-07-30 19:50:44 UTC
I forgetted to tell that the my hamster dbus interface can be enabled/disabled via it's own hamster gconf boolean key.

I added the code for this key in the Configuration.py file
Comment 9 Sandy Armstrong 2008-07-30 20:28:49 UTC
(In reply to comment #7)
>
> I can free this modifications if you think it's interesting.

I think it's interesting, and would love to see the patch.  I'm not a Hamster dev, though.

I would also want to be able to *set* my Hamster status via dbus for use cases similar to what Anders described in the original report.

Anyhoo, cool stuff!
Comment 10 J. Félix Ontañón 2008-07-31 19:32:59 UTC
#9 
(In reply to comment #9)
> (In reply to comment #7)
> >
> > I can free this modifications if you think it's interesting.
> 
> I think it's interesting, and would love to see the patch.  I'm not a Hamster
> dev, though.

All right.

I'm creating my own hamster-applet ppa in launchpad:

https://launchpad.net/~fontanon/+archive

So i hope you can soon get my modifications.
Comment 11 Juanje Ojeda 2008-08-01 07:49:18 UTC
Well, I think the best way to start with this feature without stop or make trunk unstable is to create a branch and work on it.

For this purpose I've created one on Launchpad on the Hasmter team and I've already pushed up the current code from trunk. Now Felix or whoever person who wants to play with d-bus integration can mess with it there.

Btw, Felix, I've added to the Hamster team on LP in order to you can manage this branch and upload your code.

This is the branch:
https://code.launchpad.net/~hamster.support/hamster-applet/d-bus

Comment 12 J. Félix Ontañón 2008-08-03 12:13:56 UTC
Thanks Juanje i'll work on this branch and left my hamster ppa for playing pruporses.
Comment 13 J. Félix Ontañón 2008-08-05 20:29:55 UTC
I've fully commited my contributions for hamster d-bus enhacements on:
https://code.launchpad.net/~hamster.support/hamster-applet/d-bus

Now you have a d-bus method and a d-bus signal to check for the current activity on demand and only when it changes!.

Based on AmarokPidgin i've builded my HamsterPidgin complement using this new hamster d-bus powered. I'm trying to publish in in my https://code.launchpad.net/~fontanon/hamster-applet/plugins branch, so, everyone interested: stay on!
Comment 14 Juanje Ojeda 2008-08-06 11:49:18 UTC
Hi Felix,

I hope you don't mind but I did yesterday a merge with the main branch to put into yours the changes that Patryk and me made on mainstream. There were no conclicts so I pushed to the d-bus branch again.

In other hand, I built the package and installed but I realized the installed packaged was failling. This was because your new file "hamsterdbus.py" wasn't present in "configure.ac".

I added it, I rebuilt and installed the package and no more error like before trying to add the applet to the panel. (I've already pushed that change, to fix the problem, to the branch)

My problem is that I've already installed the package with the dbus stuff but I can't see a thing. I mean, if I start the d-feet, I can't see the hamster-applet debus channel or so.
I don't know if I'm doing something wrong or I need doing smething special.

Could you tell us how to check if everything is ok with your patch? and how to test it and use it?

Thanks a lot :-)
Comment 15 J. Félix Ontañón 2008-08-06 12:18:13 UTC
Yes, it needs to be configured. So, you have to "enable" the d-bus gconf key in your ~/.gconf/apps/hamster-applet/general/%gconf.xml as you can see here:

        <entry name="dbus" mtime="1217167930" type="bool" value="true">
        </entry>

By default it's disabled. We need something like a check box in preferences.glade to be more "human", i think.
Comment 16 Juanje Ojeda 2008-08-06 14:00:59 UTC
Thank you Felix :-)

I tried and works fine.

Btw, I've made two changes:

 * I've changed the dbus PATH from 'org.hamster' to 'org.gnome.hamster'
I think it could be a good idea because now Hamster is going to be into Gnome.
 * Also I've added a key for the dbus. I've added it the key in the gconf scheme so it will be setting on the hamster gconf. And I've setting to 'true'.

I think we should set the key to 'true' by default (so I did), because it is not a thing the user need to know about but which is interesting to more applications and the desktop itself.
And now the applications (at least in Gnome) use to use dbus to communicate with the desktop or more applications.

I hope you see fine my changes (already pushed up to the branch). Feel free to rollback the changes.
Comment 17 J. Félix Ontañón 2008-08-06 15:25:37 UTC
Well, while developing i don't care about the d-bus PATH at all, so consider 'org.hamster' as a develop-path. The 'org.gnome.hamster' seems the right way.

I think it's good to include the dbus gconf key in the scheme with 'true' as value. I setted it 'false' by default 'cause while developing i tried to be the less intrusive with the code as i can.

All your changes are fine, and i'm glad to see that my contributions are so wellcomed.

I'm going to release the HamsterPidgin plugin as soon as i can push it into my https://code.launchpad.net/~fontanon/hamster-applet/plugins so you can see the hamsterdbus enhacements applied in action.
Comment 18 J. Félix Ontañón 2008-08-09 19:23:54 UTC
I've added a new signal an method for tracking "fact" changes.

The "fact" method does not shows the activity's running time and the signal only triggers on "fact" changes, and not at running time changes as "activity" signal does.

Changes are already pushed so, feel free to rollback if their not wellcomed.

Also, i've pushed an updated HamsterPidign plugin with activity-or-fact status message updating: https://code.launchpad.net/~fontanon/hamster-applet/hamster-plugins
Comment 19 Patryk Zawadzki 2008-08-10 17:16:14 UTC
A few comments:

* please make the interface and path org.gnome.Hamster and /org/gnome/Hamster

* please enable it by default as I don't see any reason to configure this by gconf

* I'll try to add some more calls and signals to the bus, including the "ActivityChanged" signal and a remote interface to change/stop the current activity
Comment 20 Patryk Zawadzki 2008-08-10 17:17:28 UTC
Also - I'm not sure we can add new features right now. It's possible we'll have to wait for GNOME 2.26.
Comment 21 J. Félix Ontañón 2008-08-11 10:13:53 UTC
(In reply to comment #19)
> A few comments:
> 
> * please make the interface and path org.gnome.Hamster and /org/gnome/Hamster

Well ... Juanje Ojeda did it at 339 bazaar revision on hamster-applet/d-bus branch.

> * please enable it by default as I don't see any reason to configure this by
> gconf

Juanje Ojeda also did it at 340 bazaar revision on hamster-applet/d-bus branch, by adding the dbus gconf key to the hamster-applet.schemas with true as default value.

So, if you think hamster dbus features has never to be disabled via gconf, i can remove the associated code and push again.

> * I'll try to add some more calls and signals to the bus, including the
> "ActivityChanged" signal 

Maybe the new 'update_fact' signal does the work you want for 'ActivityChanged'. I't only triggers on fact changes. The other 'update_activity' triggers on any changes in fact and activity time.

If you want easily see this signals in action please use the 'hamster-dbus-tracker.py' you can found here:

http://bazaar.launchpad.net/~fontanon/hamster-applet/hamster-plugins/files/4

> and a remote interface to change/stop the current activity

That's great! Cool idea!

Really thanks for your interest Patrick.
Comment 22 J. Félix Ontañón 2008-08-11 10:22:42 UTC
(In reply to comment #20)
> Also - I'm not sure we can add new features right now. It's possible we'll have
> to wait for GNOME 2.26.
> 

Oh! it's a pity, but i support your decisions if you think it's the right way.

Meanwhile, i'll keep playing with hamster and d-bus for my own achievements and will release any changes that the project can consider.

Anyway, thanks for your interest, Patrick.
Comment 23 Patryk Zawadzki 2008-08-11 10:33:15 UTC
As of August 4th we are in a feature freeze. This means we can't add any new abilities to GNOME modules :(

I'll be glad to merge these changes and add a simple command line client for 2.26. Great work guys :)
Comment 24 J. Félix Ontañón 2008-08-11 10:49:09 UTC
That's right! So, i think we need to enforce to a full bugfree dbus-featured hamster for 2.26.

And meanwhile as i've said, i'll keep playing with hamster, d-bus and the plugins for communication with other apps. See ya!
Comment 25 Anirudh Sanjeev 2008-08-11 14:43:18 UTC
Is there a patch for the head version of hamster to implement the D-bus?

There are a couple of small features I'm working on which could really use write access to D-Bus.
Comment 26 Juanje Ojeda 2008-08-11 22:29:54 UTC
(In reply to comment #25)
> Is there a patch for the head version of hamster to implement the D-bus?

You got a merged version of this feature branch with the trunk on this branch:
https://code.launchpad.net/~hamster.support/hamster-applet/d-bus
 
I syncronize it with the head version of Hamster very often, in order to develope it over the last stable versions.

> There are a couple of small features I'm working on which could really use
> write access to D-Bus.
 
You could create your own branch on:
https://code.launchpad.net/hamster-applet

So we all can see the features and pick up the ones everyone found more interesting and stable.

Of just send patches for this branch so we could include them when we make the merge on the head version for the next Gnome version.

Whatever method you want will be very welcomed :-)
Comment 27 Anirudh Sanjeev 2008-08-12 11:57:05 UTC
Hmm, the dbus code seems to be in place. However bzr is blocked from my university, so I'm stuck either reinventing the wheel or waiting for the dbus changes to be merged into the googlecode repo.

If someone can attach a tarball of the ~hamster.support/hamster-applet/d-bus snapshot, it'll be quite nice.

Thanks.
Comment 28 Juanje Ojeda 2008-08-12 12:28:17 UTC
Created attachment 116419 [details] [review]
Patch from HEAD version (at r369) with DBUS branch

I attach a patch from HEAD version (at r369) with DBUS branch, so you can test the dbus features with the last stable code.
Comment 29 J. Félix Ontañón 2008-08-13 17:04:09 UTC
Hi everyone!

I'm glad to present a new geek use of Hamster featuring the experimental d-bus interface: HamsterTwitter.

You can take it as a weird example of use of the two d-bus method and signals.

It post Twitter updates with your current fact or activity in periodical or change-driven way. It's well-configurable and can prevents itself of tweet-flooding.

Everything has been pushed in my hasmter-plugins branch:
https://code.launchpad.net/~fontanon/hamster-applet/hamster-plugins

Please, read the README file for installation issues if you want to test it.
Any comments/critics will be nice.
Comment 30 Juanje Ojeda 2008-09-28 21:04:36 UTC
Merged DBUS branch from Félix into the HEAD (r579 on trunk), so we have now basic DBUS interface :-)

Thanks Félix ;-)

I'll close the bug.

We'll need to see which others methods we need to export, but we'll do it in other bugs or, better, in the maillist.