Bug 59061 - [Javadoc] [RCP] RCP doc review
Summary: [Javadoc] [RCP] RCP doc review
Status: RESOLVED WORKSFORME
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Boris Bokowski CLA
QA Contact:
URL:
Whiteboard:
Keywords: api
Depends on:
Blocks:
 
Reported: 2004-04-19 09:44 EDT by Kim Horne CLA
Modified: 2007-06-19 16:54 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kim Horne CLA 2004-04-19 09:44:20 EDT
 
Comment 1 Kim Horne CLA 2004-04-19 09:49:20 EDT
IActionBarConfigurer - the association between an IActionBarConfigurer and the
window it configures is implied only in the call
WorkbenchAdvisor.fillActionBars(IWorkbenchWindow, IActionBarConfigurer) yet the
doc for IActionBarConfigurer methods often mentions "a window".  It's not
immediately obvious what window the doc is referring to.  Perhaps the method
fillActionBars() could drop the IWorkbenchWindow parameter and
getWorkbenchWindow() could be added to IActionBarConfigurer.  Otherwise, perhaps
the doc for each method could have the @see tag that shows what "window" is
being referred to.
Comment 2 Kim Horne CLA 2004-04-19 09:56:48 EDT
IWorkbenchConfigurer - is emergencyClosing() the best name for this method? 
Couldn't it be generalized to "allowUserInput()" ?

It is not clear what get/setData() is used for.  Arbitrary data?  Known constants?
Comment 3 Kim Horne CLA 2004-04-19 10:07:34 EDT
IWorkbenchPreferences - The name is a bit vague, as the issue tag suggests. 
Perhaps IApplicationPreferences?

Also, it's not clear when an application developer would set these preferences
from the doc of this class alone, although the doc of WorkbenchAdvisor
helps.Will changing them after a window has been created change the behaviour of
that window? This could be assumed - much of the workbench reacts to preference
changes on the fly.
Comment 4 Kim Horne CLA 2004-04-19 10:23:19 EDT
IWorkbenchWindowConfigurer - the first @see tag refers to a non existing method.

The @link elements in getShowCoolBar(), getShowStatusLine(),
getShowPerspectiveBar() and getShowFastViewBars() are not actual links because
you use a '.' instead of a '#' to seperate class from constant name.  Also, the
second link attribute should be qualified by IWorkbenchPreferences.  Also, the
doc doesn't specify if these methods can be used before and/or after the window
has been created.

getInitialSize() has been changed recently to be 1024x768 - the doc still reads
800x600.

Should configureEditorAreaDropListener() be setEditorAreaDropListener()?  Can
this method be used more than once in the advisor?

createMenuBar()/createCoolBarControl()/createStatusLineControl()/createPageComposite()
refer to a method createWindowContents... where is this method located?  It's
not referenced via a @link tag, simply wrapped in a code block...
Comment 5 Kim Horne CLA 2004-04-19 10:39:03 EDT
WorkbenchAdvisor - the doc for some of the pre/post methods seem redundant.  The
first sentence of the second paragraph is often a rehash of the first.

Should eventLoopIdle() have a disclaimer about doing long-running operations in
this method?  Also, the reference to IWorkbench.close() should be a @link rather
than just a code block.  This is the case for postWindowRestore and
postWindowCreate as well.

The doc for fillActionBars use code blocks for constant references instead of @links

getInitialWindowPerspectiveId doesn't say whether or not it may return null.

Reference to IWorkbenchWindowConfigurer.createPageComposite in
createWindowConstants should be a @link.

Several code blocks in the doc for this method should be @links
Comment 6 Kim Horne CLA 2004-04-19 10:52:58 EDT
Overall the doc for individual methods is quite good but I don't get a good
sense from it how all of the pieces tie together.  The package level
documentation could do with a good description of the workbench lifecycle and
where various methods are invoked.  Maybe a flow chart?  It might also be useful
to duplicate the code example from WorkbenchAdvisor here.
Comment 7 Nick Edgar CLA 2004-04-22 17:16:04 EDT
Thanks Kim, I'll have a look at these issues.

Note that we generally do not explicitly state when a parameter or return type
is never null -- this is assumed unless it explicitly states that it can
accept/return null.  E.g. see the Javadoc for IResource.
Comment 8 Nick Edgar CLA 2004-05-09 02:24:27 EDT
Re comment #1: I considered adding IActionBarConfigurer.getWindow(), however 
I've decided to leave it as-is.  WorkbenchAdvisor.fillActionBars is somewhat 
unusual in that the action bars may refer to either the action bars of the 
window itself, or some other component that simply wants to get a picture of 
the built-in actions, e.g. the perspective customization dialog.  For this 
reason, I think it's clearer -not- to encapsulate the window, or window 
configurer, in the action bar configurer.

I'll clarify this in the Javadoc, and address the other issues above next week, 
but I don't see any issues here that require changes to the structure of the 
API.
Comment 9 Nick Edgar CLA 2005-04-19 17:04:32 EDT
IActionBarAdvisor gained a getWindowConfigurer() in 3.1.
There are still some minor issues here, but nothing further planned for 3.1.
Comment 10 Nick Edgar CLA 2006-03-15 11:24:15 EST
Reassigning bugs in component areas that are changing ownership.
Comment 11 Boris Bokowski CLA 2007-06-19 16:54:19 EDT
Closing stale bugs.