Bug 27403 - Create progress API
Create progress API
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: -- Other --
3.x
All All
: P3 (vote)
: 5.x
Assigned To: Milos Kleint
issues@platform
: API, THREAD
: 35737 (view as bug list)
Depends on:
Blocks: 27512 27744 29614 32020 34927 35753 35759 50356
  Show dependency treegraph
 
Reported: 2002-09-18 08:09 UTC by David Strupl
Modified: 2008-12-22 19:52 UTC (History)
9 users (show)

See Also:
Issue Type: TASK
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Strupl 2002-09-18 08:09:29 UTC
The progress API could be used by data system,
execution and elsewhere.
Comment 1 Jaroslav Tulach 2002-10-04 15:53:57 UTC
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.
Comment 2 _ pkuzel 2003-01-23 16:54:50 UTC
Please do not forget to cover:
 - indeterminite progress 
 - ability to cancel task (a cancel callback)
Comment 3 Jesse Glick 2003-08-25 23:03:35 UTC
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.
Comment 4 Jeri Lockhart 2003-08-25 23:50:45 UTC
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.
Comment 5 Jesse Glick 2003-08-26 00:22:20 UTC
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.
Comment 6 Jeri Lockhart 2003-08-26 00:54:26 UTC
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.



Comment 7 Jesse Glick 2003-08-26 21:49:02 UTC
Preliminary suggested API at URL above.
Comment 8 _ tboudreau 2003-08-28 12:10:32 UTC
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? 
 
Comment 9 David Strupl 2003-08-28 15:37:31 UTC
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.
Comment 10 Jesse Glick 2003-08-29 01:01:35 UTC
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.
Comment 11 David Simonek 2003-08-29 13:29:38 UTC
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.
Comment 12 Jeri Lockhart 2003-08-29 16:51:36 UTC
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.
Comment 13 Jesse Glick 2003-08-29 17:11:44 UTC
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.
Comment 14 Jeri Lockhart 2003-09-02 20:13:47 UTC
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
Comment 15 Jeri Lockhart 2003-09-13 00:09:59 UTC
A small addition to the S1S UI requirements above:  a checkbox for
"Automatically close this window when finished".  This would be
defaulted to true.
Comment 16 santhosh 2004-03-31 06:08:02 UTC
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)
Comment 17 Jesse Glick 2004-03-31 06:21:18 UTC
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.
Comment 18 Jesse Glick 2004-07-24 20:12:59 UTC
*** Issue 35737 has been marked as a duplicate of this issue. ***
Comment 19 Jesse Glick 2005-03-18 00:33:53 UTC
Milos are you the one doing this now?
Comment 20 Milos Kleint 2005-04-18 10:38:01 UTC
yup, planned for 4.2
Comment 21 Jesse Glick 2005-04-28 23:17:10 UTC
Killing

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

as I assume you're far enough along already that this is obsolete.
Comment 22 Milos Kleint 2005-05-10 08:28:06 UTC
integrated into trunk, new module org.netbeans.api.progress created.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo