OK, it's important to differentiate between two kinds of data collection: - event-based - timer-based
The 'statechange' event is intended to be implemented in a timer-based fashion. The sensor should have a timer-based subprocess that wakes up every state-change-interval number of seconds and records a statechange if something has changed with respect to the buffer. The state change event does not care about menu items or commands that were invoked: it only cares about whether the contents of the buffer has changed since the last time it woke up. That's not to say that this is the only interesting thing you might want to collect about a developer's behavior. Perhaps you're using a new Editor with some whizbang refactoring feature and you want to see how often the developers actually use it. For this, you might want an "event-based" approach, in which you generate a "DevEvent" when the developer uses the feature. Finally, there's the question of tracking "usage" of the IDE in a more general sense than either "statechange" (which is intended to track state changes to file contents). For example, you might want to know if the user was "reading" code (such as in Jupiter). In this case, you might want to use both statechange event data plus the event-based behavior to get this more general perspective on how much time the developer was doing "something" in the IDE. Does that answer your question? Cheers, Philip ----- Original Message ----- From: Aaron Kagawa <[EMAIL PROTECTED]> Date: Sunday, May 28, 2006 1:16 pm Subject: [HACKYSTAT-DEV-L] Sensor for JEdit To: [email protected] > Hey Guys, > > I'm writing a sensor for JEdit (a Java text editor, > http://www.jedit.org/) and I have a couple of questions. > > First off it seems that JEdit has a pretty good API - I'm able to > get > all the SAVE, OPEN, CLOSE, and BUFFER events in real time. But, > I'm > a little confused what to do with that information. More > specifically, I know that we have a HACKYSTAT_STATE_CHANGE_INTERVAL > property, but it seems that I don't need to trigger the collection > of > this information every 30 seconds. So, should I "filter out" the > state changes so that I have only one (probably the last one) for a > 30 second time period? And should that apply to the other events > as well? > > thanks, Aaron >
