Ok Dafe, you seem to be the one that works on busy cursor and progress
api is exactly for you. So here you are.

Please do not forget to update 
http://openide.netbeans.org/tutorial/api-design.html#interfacesandclasses
if you find some new nice design pattern.

Please do not forget to cover:
 - indeterminite progress 
 - ability to cancel task (a cancel callback)

I would like to take this on (since I need it done to support other
threading code, anyway). I already have some ideas what the API should
look like. On the other hand, I don't plan to work on UI improvements
taking advantage of it (like a reworked progress bar) - Dafe may wish
to do that still; the API should be strong enough to support a variety
of UIs easily.

I'd like to eventually use your API and UI to replace what we have in
S1S for J2EE deployment progress, which will be using the JSR88
ProgressObject.  This is its api:

 getDeploymentStatus returns the DeploymentStatus object that
contains the
current status details.

 getResultTargetModuleIDs returns a list of TargetModuleIDs that
completed
the associated DeploymentManager operation successfully.

 getClientConfiguration returns a ClientConfiguration object that
installs,
configures, and executes an application client.

 isCancelSupported indicates whether this product provider has
implemented
a cancel operation for the associated DeploymentManager operation.

 cancel stops all further processing of the operation and returns the
environment
to its original state before the operation was executed. This is an
optional
method for vendor implementation.

 isStopSupported indicates whether this product provider has
implemented a
stop operation for the associated DeploymentManager operation.

 stop allows the operation on the current TargetModuleID to run to
completion
but does not process any of the remaining unprocessed TargetModuleID
objects.
This is an optional method for vendor implementation.

For the UI, it would be nice to have the option of using something
like a scrollable  vertical marquee for rapidly updated progress messages.

Also nice to have would be the handling of completely unknown and
unpredictable completion times.

Jeri - I am not sure what you are asking for exactly, but the kind of
progress API I had in mind would be very generic, used for various
purposes in the IDE such as running actions etc. You could very likely
write a bridge from a JSR-88 ProgressObject to the new progress
interface for purposes of displaying it in the IDE's GUI, though I am
not sure the standard GUI would be enough for you - it should support
probably a name, icon, percentage complete (or indeterminate), perhaps
messages, perhaps cancellation, but no more. If you need some
particular UI elements to represent something so specific (and
potentially complex) as a J2EE deployment, you may be better off
writing it yourself.

The jsr88 ProgressObject doesn't have a GUI.  What you describe is
similar to what we're using now.  The primary benefit would be
consistency across the product.        

However, if Dafe or someone else is going to implement a standard
progress GUI, I'd like it to be able to show a history of all the
progress messages, and support the cancel and stop features of the
jsr88 prog obj.

Preliminary suggested API at URL above.

There is also a proposal to merge the editor status bar and the default status bar 
and put both at the bottom of the screen. 
 
Not knowing that there is a proposed API, I started some prototyping of how this 
can work - it's a little different than the proposal, but should help solve both problems. 
An overview: 
 
StatusManager:  Provides named status areas, including a default one. 
Status areas may be of type: 
 - Text 
 - Progress 
 - Custom (allows the module to provide its own component to include in the status bar) 
 
Most modules will only need the default one;  the editor may register additional text 
ones for search results and line numbers, etc. 
 
Named sections are made visible by calling StatusManager.activate("name"). 
The manager will reference count calls to activate/deactivate, so, for example, 
each editor of a type may activate a status area it wants to use.  When a symmetric 
number of calls to deactivate have happened, the manager will hide the section. 
 
Processes have a fairly simple descriptor API which can be listened to for change 
events, provide an icon, description, actions (such as cancel).  The process area will 
function similarly to the windows "tray".  Progress is either an integer from 0-100 or it 
is one of a few predefined constants such as Running (unknown degree of completion), 
completed, aborted. 
 
Anyway, I'm probably a couple days away from a working prototype.  Should I abandon 
it or go forward with it? 
 

Tim, we actaully use our own version of status displayer because we
use our own custom component. If you ever implement it please provide
the possibility to plug our own. Plus we also need the progress bar so
all your items are needed by at least someone.
We hack it in 3.5 but in case we decide to upgrade it would be very
nice to remove our nasty hacks for the status line.
And finally we use it docked to the bottom of the window (again hacked
somehow). I might send you a screen shot if you are interested.

Tim, go ahead with what you're doing, though we may need to synch up
APIs later. I have no intention of including everything needed for a
status bar in the progress API; it should primarily be a way of
keeping track of everything going on inside NB (for example to check
when exiting and maybe show in the exit dialog), secondarily as a GUI
device. The API may include the ability to describe richer semantics
than we need to actually display, but that is not a problem I think.

Probably it would be best if the status bar API were able to include
progress API tasks as one of the things it was able to show. That
should be fairly easy to set up later, assuming that you are not
trying to put the status bar API into the trunk as a stable API very soon.

Jesse - ok, I agree, go ahead and work on API. But please keep me
informed, I already spent some time thinking about it, so my thoughts
may be of soem value for you.

Tim - there exists unfinished UI spec on status line, which contains a
lot of *really good* ideas, please contact Dusan Pavlica and make sure
you are in line with general stream of UI spec so that your work isn't
wasted.

In your proposed API, I'd like the support of both Cancel and Stop, 
as described above from the JSR 88 spec. 

In response to your suggestion that we write it ourselves, I believe
that it's preferable from the point of view of consistency to use a
common NetBeans API and UI for progress instead of a custom one for
S1S only.

Jeri -

Re. Cancel vs. Stop - I do plan to somehow support this distinction.
Actually acc. to the JLF, there could be three kinds of interruptions:
cancellation (all work reverted to original state); stopping (a clean
cessation of activity at some safe stopping point); halt (abrupt
termination, possibly leaving data in an inconsistent state and
requiring user confirmation to a warning message).

Re. custom vs. standardized progress API and/or GUI - definitely any
standardized API and GUI should be used throughout NB & S1S, I was not
suggesting otherwise! I was only saying that if you needed to display
detailed GUI elements pertaining to particular aspects of a J2EE
deployment, particularly with specialized GUI controls, then you may
want a tailored GUI (and perhaps API) for that, e.g. for display
within a wizard panel. The task can still be registered into the
system with the generic API.

It would be helpful if you could come up with a brief sketch of what
you would like to show to the user during a J2EE deployment, so we can
evaluate whether a generic API/GUI would suffice. E.g. if you just
have a task with some hierarchy of subtasks, each of which displays
some progress message with a progress indicator, and want to supply a
Cancel and/or Stop button to terminate the whole process, no problem -
the generic API should suffice. (There may need to be some utility
method for creating a standardized GUI component displaying progress
of one task group that you could embed e.g. in a wizard panel, since
otherwise you would only have the global status bar available.) If you
need the ability to terminate subtasks individually, or show
additional GUI components in certain places, etc., then you should
describe these requirements.

Jesse, Dafe, and all:
The S1S api and ui requirements are here:
http://roadcampy.sfbay/sequoia/plans/progress_ui/S1S_Progress_API_and__UI_Requirements.html
--Jeri

A small addition to the S1S UI requirements above:  a checkbox for
"Automatically close this window when finished".  This would be
defaulted to true.

I want to show the progress of a time consuming task, by showing a 
progress bar in status bar.

If you see other professional ide's, they have progress bar,memory
monitor,clock in statusbar.
can I add a component to status bar?

after this bug fix, I should be able to achieve this.
(as Jesse Glick suggested)

Santhosh - this issue is just about an API. You would also need a
standard GUI displaying it. No such GUI has yet been specified or
designed.

Note that in the short term, you can add a component to the main menu
bar and it should be displayed (though not on Mac OS X with screen
menu bar mode enabled). I think there is also some way to replace the
main window's status bar completely but I am not sure how; please ask
on dev@openide.netbeans.org.

*** Issue 35737 has been marked as a duplicate of this issue. ***

Milos are you the one doing this now?

yup, planned for 4.2

Killing

http://core.netbeans.org/proposals/threading/progress.html

as I assume you're far enough along already that this is obsolete.

integrated into trunk, new module org.netbeans.api.progress created.