java - JavaFX Scene Graph modification for Responsiveness Indicator -

it bad practice big jobs on ui thread if do, big jobs cause program hang (not accept user input or render new data) until job finished.

i looking add widget our code base indicate developers when have committed taboo. idea, , 1 i've seen on number of other applications, have component moving @ constant speed, such bar twirling on screen. such tool, if developer working , accidentally more computationally difficult expected on ui thread, spinning bar become choppy, indicating him, when functional testing, needs implement mechanisms cause job executed elsewhere.

one odd requirement on code should non-existent in production builds, , present in dev builds, since widget not users, developers.

i jumped canvas objects , wrote quick component spins teal bar. idea if big job dumped on ui thread, bar stop spinning (since fx job queue wont continue dispatching) , bar jump forward, rather rotate smoothly (as when program @ rest).

below screen-shot of first implementation:

(notice teal bars, which, if saw our application running, rotating steadily --hopefully anyways)

the issue here (as might notice) our layout's been screwed up. because i'm modifying scene graph this:

scene     rootcomponent         content 

to

scene     obnoxiouspane         canvas             spinner(s)         rootcomponent             content 

modifying scene graph in such way has things preferred height, mouse events , (presumably) number of other events getting dispatched spinners rather content components.

of course, when go production, have original scene graph in version give our users.

so question this: how should go correcting these problems?

i go after each of them individually come up, writing lot of custom code things like

obnoxiouspane.prefheightproperty().bind(content.prefheightproperty) obnoxiouspane.prefwidthproperty()//... spinner.setmousetransparent(true) spinner.setothereventsiprobablycantenumeratewithoutseriousresearchtransparent(true) 

or try go after problem reflection, attempting bind every property in content pane corresponding obnoxiouspane property, seems bug breeding ground.

or... what? i'm hoping there's lightweight component or imnotreallyhereproperty can leverage add development aid.

thanks help!

your approach seems fundamentally flawed. shouldn't stalling javafx application thread.

instead should have concurrent process , update ui appropriate process starts, progresses , completes.

see java2s sample using javafx concurrency , progress indicator facilities example of such alternate approach.

---

if want disable portion of ui time, nodes have disabled property can set. can use css style disabled node user has indication thing hasn't hung , deliberately disabled.