Am 04.02.2017 um 16:00 schrieb Philippe Mouawad:
On Sat, Feb 4, 2017 at 3:52 PM, Vladimir Sitnikov <
[email protected]> wrote:
Felix> The timer lives in the awt thread, so we need no invokeLater. Or do
I miss
Felix> something?
I thought it was java.util.Timer.
I did not notice that was javax.swing.Timer. swing timer is fine.
Philippe>I agree. The only reason I would see for calling invokeLater would
maybe to
Philippe>avoid freezing UI if the call takes more than some limit
invokeLater is not required provided the timer is swing timer.
I agree it's not required but this might be interesting to consider.
http://stackoverflow.com/questions/15556646/why-are-there-two-timer-classes-in-javaone-under-javax-swing-one-under-java-ut
I wonder if we can rework log panel into "append" calls instead of "set
text from scratch".
I remember I had tried something around that without success but if you
have an idea .
I looked at that, too. There are two options, one is the String (as
implemented) the other is a RDocument, which didn't look like it would
support it easily. But you might find a find, so look at it.
Philippe>For me there is only 1 Timer thread no ?
I'm not sure if we can reuse that swing timer to aggregate events form
listeners (e.g. statistics listeners, etc).
Felix>The component is set to an empty text
Oh, I did not notice that. On the other hand, it looks awkward.
I find "buffer.clear(); modified=true;" easier to reason about since that
results in a single place where the textarea gets updated.
PS. Are you sure "events.clear()" is thread-safe?
I think indeed there might be a problem here
Done.
PPS. Can we move format.format(logEvent) out of syncrhonized(events) block?
Formats are not threadsafe, so I put it inside the lock.
Felix
Vladimir
