I also believe your statements to be true. :-) Cheers, Philip
----- Original Message ----- From: Aaron Kagawa <[EMAIL PROTECTED]> Date: Monday, May 29, 2006 3:29 am Subject: Re: [HACKYSTAT-DEV-L] Sensor for JEdit To: [email protected] > Okay, I'm going to list statements that I believe to be true. > > 1) Both Activity and DevEvent 'statechange' events are both > implemented with a timer-based fashion. > 2) Open, close, and save events are implemented in a event-based > fashion in both Activity and DevEvent. > 3) Since I just want to send statechange, open, close, and save > events there is no real significant difference in terms of > implementation between the DevEvent and Activity data that I will > be sending. > > Thanks, Aaron > > > At 07:56 AM 5/28/2006, you wrote: > >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 > > > >
