Thanks!
I guess the larger question is that I still don't understand the
difference between Activity and DevEvent. Is Activity going to get
phased out? Or Activity's sole purpose is 'statechange'.
Its always interesting to learn different parts of Hackystat!
Thanks, Aaron
At 11:42 PM 5/28/2006, you wrote:
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
> > >
>
