GNOME Bugzilla – Bug 535863
D-Bus interface for tracking events
Last modified: 2008-09-28 21:04: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.
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.
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.
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.
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.
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. ;-)
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.
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 :)
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
(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!
#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.
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
Thanks Juanje i'll work on this branch and left my hamster ppa for playing pruporses.
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!
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 :-)
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.
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.
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.
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
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
Also - I'm not sure we can add new features right now. It's possible we'll have to wait for GNOME 2.26.
(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.
(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.
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 :)
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!
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.
(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 :-)
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.
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.
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.
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.