[[Rationalism]] is mentally attractive, but during real development we end up at most with [[empiricism]], if not with plain [[cluelessness]].

[[Rationalism]] is mentally attractive, but during real development we end up at most with [[empiricism]], if not with plain [[cluelessness]].

We had a lot of problems to convince our developers that [[Slowness Detector]] is useful. And [[Slowness Detector]] is really different story, as it delivers throughout reports about each individual failure (it [[empiricism|empiristicaly observes]]) and only the most annoying ones need to be fixed. I cannot imagine the welcome ceremony if I even tried to convince them to sign for a [[rationalistic]] approach and use the dispatch thread only for painting. No chance at all.

We had a lot of problems to convince our developers that [[Slowness Detector]] is useful. And [[Slowness Detector]] is really different story, as it delivers throughout reports about each individual failure (it [[empiricism|empiristicaly observes]]) and only the most annoying ones need to be fixed. I cannot imagine the welcome ceremony if I even tried to convince them to sign for a [[rationalistic]] approach and use the dispatch thread only for painting. No chance at all.

[[Rationalism]] is mentally attractive, but during real development we end up at most with [[empiricism]], if not with plain [[cluelessness]].

[[Rationalism]] is mentally attractive, but during real development we end up at most with [[empiricism]], if not with plain [[cluelessness]].

One of the distinguished members of [[NetBeans]] community however (quite convincingly) argued in favor of polishing the whole event handling model claiming that '''AWT Dispatch Thread shall be used only for painting'''. I really like this idea. It is so [[rationalistic]]! We know that there are problems in blocking the essential [[Swing]]'s resource (its dispatch thread) for too long and thus we shall design proper mechanism to eliminate this (something like [[SwingWorker]]). Then we shall rewrite all the [[NetBeans]] code to use this and then the world would be more [[beautiful]] place (indeed, as it would be [[rationalistic]]).

One of the distinguished members of [[NetBeans]] community however (quite convincingly) argued in favor of polishing the whole event handling model claiming that '''AWT Dispatch Thread shall be used only for painting'''. I really like this idea. It is so [[rationalistic]]! We know that there are problems in blocking the essential [[Swing]]'s resource (its dispatch thread) for too long and thus we shall design proper mechanism to eliminate this (something like [[SwingWorker]]). Then we shall rewrite all the [[NetBeans]] code to use this and then the world would be more [[beautiful]] place (indeed, as it would be [[rationalistic]]).

My own [[rationalistic]] half really wants the above approach to be implemented. However when the other half imagines how much existing code would have to be fixed, how much time that would take, how the [[NetBeans]] release schedule would be affected, how many complains we would hear from our fellow developers, then the whole of me just has to give up.

My own [[rationalistic]] half really wants the above approach to be implemented. However when the other half imagines how much existing code would have to be fixed, how much time that would take, how the [[NetBeans]] release schedule would be affected, how many complains we would hear from our fellow developers, then the whole of me just has to give up.

This solution is not going to make anything faster (obviously it is just [[UI Responsiveness]] work), it just properly indicates the status to the user and offers the additional benefit of being able to stop waiting for end of the operation.

This solution is not going to make anything faster (obviously it is just [[UI Responsiveness]] work), it just properly indicates the status to the user and offers the additional benefit of being able to stop waiting for end of the operation.

One of the distinguished members of [[NetBeans]] community however (quite convincingly) argued in favor of polishing the whole event handling model claiming that '''AWT Dispatch Thread shall be used only for painting'''. I really like this idea. It is so [[rationalistic]]! We know that there are problems in blocking the essential [[Swing]]'s resource (its dispatch thread) for too long and thus we shall design proper mechanism to eliminate this (something like [[SwingWorker]]). Then we shall rewrite all the [[NetBeans]] code to use this and then the world would be more beautiful place (indeed, as it would be [[rationalistic]]).

One of the distinguished members of [[NetBeans]] community however (quite convincingly) argued in favor of polishing the whole event handling model claiming that '''AWT Dispatch Thread shall be used only for painting'''. I really like this idea. It is so [[rationalistic]]! We know that there are problems in blocking the essential [[Swing]]'s resource (its dispatch thread) for too long and thus we shall design proper mechanism to eliminate this (something like [[SwingWorker]]). Then we shall rewrite all the [[NetBeans]] code to use this and then the world would be more [[beautiful]] place (indeed, as it would be [[rationalistic]]).

My own [[rationalistic]] half really wants the above approach to be implemented. However when the other half imagines how much existing code would have to be fixed, how much time that would take, how the [[NetBeans]] release schedule would be affected, how many complains we would hear from our fellow developers, then the whole of me just has to give up.

My own [[rationalistic]] half really wants the above approach to be implemented. However when the other half imagines how much existing code would have to be fixed, how much time that would take, how the [[NetBeans]] release schedule would be affected, how many complains we would hear from our fellow developers, then the whole of me just has to give up.

My own [[rationalistic]] half really wants the above approach to be implemented. However when the other half imagines how much existing code would have to be fixed, how much time that would take, how the [[NetBeans]] release schedule would be affected, how many complains we would hear from our fellow developers, then the whole of me just has to give up.

My own [[rationalistic]] half really wants the above approach to be implemented. However when the other half imagines how much existing code would have to be fixed, how much time that would take, how the [[NetBeans]] release schedule would be affected, how many complains we would hear from our fellow developers, then the whole of me just has to give up.

We had a lot of problems to convince our developers that [[Slowness Detector]] is useful. And [[Slowness Detector]] is really different story, as it delivers throughout reports about each individual failure (it just [[empiricism|empiristicaly observers]]) and only the most annoying ones need to be fixed. I cannot imagine the welcome ceremony if I even tried to convince them to sign for a [[rationalistic]] approach and use the dispatch thread only for painting. No chance at all.

We had a lot of problems to convince our developers that [[Slowness Detector]] is useful. And [[Slowness Detector]] is really different story, as it delivers throughout reports about each individual failure (it [[empiricism|empiristicaly observes]]) and only the most annoying ones need to be fixed. I cannot imagine the welcome ceremony if I even tried to convince them to sign for a [[rationalistic]] approach and use the dispatch thread only for painting. No chance at all.

[[Rationalism]] is mentally attractive, but during real development we end up at most with [[empiricism]], if not with plain [[cluelessness]].

[[Rationalism]] is mentally attractive, but during real development we end up at most with [[empiricism]], if not with plain [[cluelessness]].

My own [[rationalistic]] half really wants the above approach to be implemented. However when the other half imagines how much existing code would have to be fixed, how much time that would take, how the [[NetBeans]] release schedule would be affected, how many complains we would hear from our fellow developers, then the whole of me just has to give up.

My own [[rationalistic]] half really wants the above approach to be implemented. However when the other half imagines how much existing code would have to be fixed, how much time that would take, how the [[NetBeans]] release schedule would be affected, how many complains we would hear from our fellow developers, then the whole of me just has to give up.

We had a lot of problems to convince our developers that [[Slowness Detector]] is useful. And [[Slowness Detector]] is really different story, as it delivers throughout reports about each individual failure (it just [[empiricism|empiricistically observers]]) and only the most annoying ones need to be fixed. I cannot imagine the welcome ceremony if I even tried to convince them to sign for a [[rationalistic]] approach and use the dispatch thread only for painting. No chance at all.

We had a lot of problems to convince our developers that [[Slowness Detector]] is useful. And [[Slowness Detector]] is really different story, as it delivers throughout reports about each individual failure (it just [[empiricism|empiristicaly observers]]) and only the most annoying ones need to be fixed. I cannot imagine the welcome ceremony if I even tried to convince them to sign for a [[rationalistic]] approach and use the dispatch thread only for painting. No chance at all.

[[Rationalism]] is mentally attractive, but during real development we end up at most with [[empiricism]], if not with plain [[cluelessness]].

[[Rationalism]] is mentally attractive, but during real development we end up at most with [[empiricism]], if not with plain [[cluelessness]].

[[Rationalism]] is mentally attractive, but during real development we end up at most with [[empiricism]], if not with plain [[cluelessness]].

[[Rationalism]] is mentally attractive, but during real development we end up at most with [[empiricism]], if not with plain [[cluelessness]].

My own [[rationalistic]] half really wants the above approach to be implemented. However when the other half imagines how much existing code would have to be fixed, how much time that would take, how the [[NetBeans]] release schedule would be affected, how many complains we would hear from our fellow developers, then the whole of me just has to give up.

My own [[rationalistic]] half really wants the above approach to be implemented. However when the other half imagines how much existing code would have to be fixed, how much time that would take, how the [[NetBeans]] release schedule would be affected, how many complains we would hear from our fellow developers, then the whole of me just has to give up.

We had a lot of problems to convince our developers that [[Slowness Detector]] is useful. And [[Slowness Detector]] is really different story, as it delivers throughout reports about each individual failure (it just [[empiricism|empiricistically observers]]). I cannot imagine the welcome ceremony if I even tried to convince them to sign for a [[rationalistic]] approach and use the dispatch thread only for painting. No chance at all.

We had a lot of problems to convince our developers that [[Slowness Detector]] is useful. And [[Slowness Detector]] is really different story, as it delivers throughout reports about each individual failure (it just [[empiricism|empiricistically observers]]) and only the most annoying ones need to be fixed. I cannot imagine the welcome ceremony if I even tried to convince them to sign for a [[rationalistic]] approach and use the dispatch thread only for painting. No chance at all.

[[Rationalism]] is mentally attractive, but during real life we end up at most with [[empiricism]], if not with plain [[cluelessness]].

[[Rationalism]] is mentally attractive, but during real development we end up at most with [[empiricism]], if not with plain [[cluelessness]].

=== AWT Dispatch Thread shall be used only for painting ===

=== AWT Dispatch Thread shall be used only for painting ===

During the work on [[NetBeans]] 6.8 the [[performance]] team introduced new tool: [[Slowness Detector]]. It allows us to observe real [[UI Responsiveness]] problems that our users are facing. This is following the spirit of [[empiricism]] - observe, measure and only they try to explain and take some action. And we needed some action as (to some body's surprise, to someone's expectation) actions that were supposed to be instant some time took many seconds.

During the work on [[NetBeans]] 6.8 the [[performance]] team introduced new tool: [[Slowness Detector]]. It allows us to observe real [[UI Responsiveness]] problems that our users are facing. This is following the spirit of [[empiricism]] - observe, measure and only then explain or take some action. And we needed some action as (to some body's surprise, to someone's expectation) actions that were supposed to be instant some time took many seconds.

That started a discussion about proper way to fix it. One proposed solution suggested:

That started a discussion about proper way to fix it. One proposed solution suggested: