Re: [platform-ui-dev] Startup performance / Lazy creation of editors.

[Nick_Edgar@xxxxxxx]

Bob,

The selectAndReveal notifications are not issued whenever the selection 
changes.  This is used when creating a new resource. 
Views like the Navigator and Packages view implement ISetSelectionTarget 
in order to show the newly created item.
Currently I know of no editors implementing this, only views, but we do 
check nonetheless.
(In this case, it would be acceptable to only check the instantiated 
editors)

FYI, the editor/view linking behaviour in the Navigator and Packages views 
is done by the views themselves.
They track their own selection, activating the corresponding editor if 
it's open.
And they track editor part activation using the part service 
(IPartService), to update the view's selection when switching between 
editors.

Nick






"Bob Foster" <bob@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
04/29/02 08:54 PM
Please respond to platform-ui-dev

 
        To:     <platform-ui-dev@xxxxxxxxxxx>
        cc: 
        Subject:        Re: [platform-ui-dev] Startup performance / Lazy creation of editors.


getDirtyEditors() could replace my use of getEditors(), if it does what I 
think (return the already instantiated editors for which isDirty() returns 
true). However, getDirtyEditors() seems over-specialized. I suggest you 
instead provide an API like getInstantiatedEditors(); callers could test 
isDirty() or any other condition themselves.
 
Question on a separate point: I'm sure you don't mean this, but the 
rationale for selectAndReview() suggests that a resource showing in an 
editor view tab would be revealed or not when the user selects the 
resource in another view, depending on whether the editor happens to be 
instantiated. This would be quite confusing to the user.
 
Bob
----- Original Message ----- 
From: Eduardo_Pereira@xxxxxxx 
To: platform-ui-dev@xxxxxxxxxxx 
Sent: Monday, April 29, 2002 4:21 PM
Subject: [platform-ui-dev] Startup performance / Lazy creation of editors.


As part of the startup time improvement work, we are thinking about not 
creating editor that are not visible on startup. I.e. only one editor will 
be created at startup if the user has only one window with one editor 
workbook opened. Only the tabs will be created for the other editors. 

To be able to change this, we need to remove/add API related to editors. 
One of the biggest problem is the API IWorkbenchPage.getEditors() which 
returns an array with all IEditorPart(s) created in that page. 

This optimization would work only if all senders of getEditors were 
changed to use new provided API. 

The API getEditors would be deprecated and changed to restore all editors 
not restored by the time it was sent. API such as: 
findEditor(IEditorInput), getDirtyEditors(), would be added to 
IWorkbenchPage.  Another API that could/would be necessary is 
selectAndReview(ISelection) which would collect the parts  that implements 
ISetSelectionTarget and send selectReveal(ISelection) only to the parts 
already created. findEditor(IEditorInput) would instanciate the editor and 
return it. 

I took a look in all senders of getEditors (Platform and JDT) to check 
what they are using it for and if they  are running on startup. Most of 
the senders running on startup are part of platform UI which makes it 
easier for us to implement this proposal. However, all senders should be 
changed because the first one to send getEditors would create all the 
editors taking a long time. 

If the time permits we would like to do the same kind of change for views 
that are hidden in a tab folder. 

Comments are appreciated. Please let me know if findEditor(IEditorInput), 
getDirtyEditors(), selectAndReview(ISelection)  would not be 
enough to do the work that your senders of getEditors() are doing. 

Thanks. 
Eduardo.