Jan Haderka's Blog

Get Busy now

JXBusyLabel have been in SwingX for quite while. Introduced by Josh while ago component and associated painter have provided developers with ability to enrich their applications with nice infinite progress bar component. The initial version have been bit limited - it was not possible to scale the indicator, speed have been fixed, shape and trajectory have been fixed as well.

As soon as this component have been introduced I've started to look at the ways to extend its functionality. Being interrupted multiple times and having lost some changes to the code it took about 6 months before the final version have been committed back to the SwingX code base. New BusyPainter now supports nearly any kind of shape as a progress point as well as nearly any kind of closed path as trajectory.

Since it is not always easy to imagine kind of progress indicator that can be created by combination of different shapes as points and trajectories, below is simple demo that shows various combinations and can also produce the code necessary to recreate whatever kind of progress bar is currently shown. For those who can't run the demo or are too lazy to do so, here's at least a screenshot.

BusyLabel Demo:

Here's another demo showing use of the JXBusyLabel to as progress bar indicator common in the browsers - as part of the menu.

Menu Bar Demo:

Comments

• sorry, but I have to say this. WHY do you extend the functionality of a busylabel?

  I want a busylabel to be EXACTLY the same whichever platform/application.
  Are you sure that users of this component need this functionality?

  If users do not ask for this kind of functionality (I know I do not) than this extension is bloating the API. It was a simple component but it isn't anymore. There is now even a tool to try out the API. To me this is evidence that bloat introduces more bloat.

  Sorry to put it this hard but I hate to see a simple component become complicated for no reason what so ever. Especially because swingx is the frontportal for javax.swing

  Kees.

  Posted by: keeskuip on January 01, 2008 at 07:42 AM

• This new version looks great. Thanks for continuing the work!

  Posted by: joshy on December 31, 2007 at 11:04 AM

• I've added color pickers to the demo so it should be complete by now.I get what you say about the animation, but as long as painting stays the way it is now it will always be jerky at slow speeds no matter how many fps is used What need to change is the way black shape gets painted. It needs to appear gradually to smooth it out. Thanks for all the comments, it helped to make it better.

  Posted by: rah003 on December 31, 2007 at 06:35 AM

• Excellent. Yes, it looks better. :)

  You should have one timer (that would be the current one, that you call speed) that is resetting the time stamp on the next bar to "current" time. Then another timer that is repainting the widget, say, 30 times a second. Then the color on each bar is just proportional to the delta from current time. It should be a breeze to do, given of course that you can the setup coded as I thing you have.. :)

  Anyway, good work!
  

  Posted by: mikaelgrev on December 30, 2007 at 02:34 PM

• I see what you mean now. This is the part of the label I haven't touched, but you are right and I might try to change this. But I guess it will be more complicated then just maintaining constant FPS. As it is the trajectory and points painted on it are constant and black shape with trail either is painted or is not. With what you suggest I will have to rotate the whole thing point by point (or skip few at high speeds) which will take more of the CPU or gradually fade in the black shape or something like this. BTW I've changed the demo a bit so hopefully you will find it more appealing now.

  Posted by: rah003 on December 30, 2007 at 01:54 PM

• If you think of the "black" shape running around as a light that is lit and then fades away with time it will look much better at "low speeds". If you try to lower the speed now it looks very jerky and synthetic, not imitating any real world process. If you instead repaint at the same FPS (basis for good animation is a decent and consistent FPS) and calculate the color of each shape using the time since it turned "black" you will get a more fluid and better looking result. Now you have connected the speed of movement and frames per second (FPS) together. If you ask Chet maybe he can explain this better.

  Regarding the design of the demo I just think that is important to make the GUI look good from the start. One never have a second chance to make a fist impression. :)

  Cheers,
  Mikael Grev

  Posted by: mikaelgrev on December 30, 2007 at 10:05 AM

• I'm not sure I get your comment regarding the speed. Speed is controlled by setDelay(int) method (delay between moving from one point to the another) and by total amount of points on the trajectory.
  The start and end colors are configurable already - setHighlightColor(Color) and setBaseColor(Color) methods take care of that. Just because the demo doesn't show it, it doesn't mean you can't set the colors ;).
  The slope of the gradient is controlled by the setTrailLength(int) and difference between base and highlight colors.
  As for demos, sure, they could look much better. They were more then anything just a test cases for changes I was forcing on the JXBusyLabel itself. If you want to make them look better, all the code is in the jdnc-incubator... :)

  Posted by: rah003 on December 30, 2007 at 09:39 AM

• The speed is connected to the FPS which is wrong. The FPS should be constant, or settable as well, and the rotational speed should be independent of that, with an exception ooof the first black one which should move in discrete steps according to rotational speed (or this should be settable as well). Also, the start and end color should be settable, as well as maybe the gamma (slope) of the gradient from start to end color. Other than that it has potential. It would be good it you added some presets that looks good in different situation as must do not. For instance the Menu Bar Demo doesn't have a very attractive setting. All IMO. The GUi of the demo app could also benefit from a touch by someone that can do GUI design, like a designer.

  Posted by: mikaelgrev on December 29, 2007 at 04:15 PM

This work is licensed under a Creative Commons License.