Hi Turker,
I agree with Mike that it's great that you're working on extending hackyEclipse to CDT. I am hoping that your efforts will help us improve the quality of that module as well as extend its functionality.
Some initial general thoughts:
* As Mike notes, there's no a priori reason why the Activity sensor for hackyEclipse needs to know whether it's working in JDT or CDT or FortranDT or whatever. The server-side analysis functions such as Telemetry support a FileFilterPattern method that allows you to do analyses on all *.java files, or *.c files, or *.cc files, etc. So, if what you are interested in is Active Time for C or C++ development, then I think the best strategy is to simply make the current approach work generally for any *DT, then use server-side functions to get C-specific analyses.
* However, there do appear to be some Java-specific stuff that's crept into the code. It seems like the code should be refactored to enable certain capabilities depending upon the *DT that is active. That way, we can have some functionality that's Java-specific, and other functionality that's C-specific. I would be interested in how you would propose to provide such toolkit-specific functionality.
Here's some more specific answers to your questions:
I noticed that the sensor was programmed to record "Open File" activity for any file type but "Close File" activity for only .java files. Is there a specific reason for that?
No, that's an oversight. However, it should be noted that the only type of Activity event we actually manipulate on the server side is "State Change", so this asymmettry doesn't have any operational impact.
For this purpose, I added ECLIPSE_PROJECT_NATURE property to my sensor.properties file. This would be either javanature, ccnature, or cnature. So, if the nature is ccnature, the sensor only collects activity data on C++ files.
I again agree with Mike that it would work better if we could avoid this property altogether, and send general events (such as statechange) whenever possible and decide whether it's C or Java on the server side. For things that really are language specific, then maybe use the active toolkit type to decide whether to enable the functionality or not.
Is there anyone else who has an interest on CDT compatible hackyEclipse?
That would be Mike. :-)
Also, I am wondering if it would be a good idea to contribute a PreferencePage to configure the plug-in instead of a sensor.properties file. It could make it easier to configure the sensor. Again, is there a specific reason why we need a sensor.properties file?
Yes. One of the basic design goals of Hackystat is to collect metrics from a wide variety of different tools in the developer's environment using tool-specific sensors. Every sensor, regardless of the language it is implemented in and the tool it is supporting, needs upon startup to get the answers to at least the following questions: What is the URL of the hackystat server I should send this data to? What is the 12 character key of the user to be associated with this data? Does this user want me to be enabled at the current time? The sensor.properties file provides a single "point of contact" for the answers to these questions for every sensor. Doing it this way allows a user, for example, to one line in the sensor.properties file and then have all of their sensors start sending data to a different server.
Now, the downside to this is that sensor.properties represents a "lowest common denominator" from the user interface point of view. This is unfortunate. In the longer term, we would like to build a client-side 'installer' type application for users that they would download and run, which would bring up a nice Swing/SWT GUI where they could type in their preferences and also indicate which sensors they would like to have downloaded and installed from the server. This would be a major win over the current very manual and very error-prone process, but would still maintain the single point of contact behavior.
That's a long answer to a short question, but I wanted to advertise that 'installer' project to anyone who might have extra time on their hands. :-)
Cheers, Philip
