JEdit is just a text edtitor. I don't think it can run Junit tests.
Unless there is a plugin or something. So, for now I think I'll just
start with Active Time via Activity and DevEvent.
Thanks, Aaron
ps. Hongbing are you back in Hawaii? We should plan a lunch or something.
At 05:05 PM 6/10/2006, Hongbing Kou wrote:
Hi, Aaron,
How about unit test, compilation, object metrics (methods,
statements) etc? Are
you just interested in Active Time in JEdit IDE? JEdit is a good IDE
for beginners.
It might be cool if we can make Zorro work to TDD development in JEdit.
Thanks,
Hongbing
Aaron Kagawa wrote:
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
>
