Bug 21347 - [Perspectives] Extensions must be able to customize default perspective
Summary: [Perspectives] Extensions must be able to customize default perspective
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P1 blocker (vote)
Target Milestone: 2.0.2   Edit
Assignee: Eduardo Pereira CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 24454
Blocks:
  Show dependency tree
 
Reported: 2002-07-08 12:01 EDT by Greg Adams CLA
Modified: 2002-11-05 15:29 EST (History)
2 users (show)

See Also:


Attachments
Feature example. (22.85 KB, application/octet-stream)
2002-11-04 18:05 EST, Eduardo Pereira CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Adams CLA 2002-07-08 12:01:26 EDT
Installation of an extension must be able to give the user the option of 
customizing the current/default perspective. The behavior should be such that 
the specified perspective becomes the active perspective once the extension is 
installed & eclipse is up again.  The behavior is similar to the first time 
behavior with the default perspective. For example if product 1 was installed 
and product 2 installs as a feature we need the product 2 perspective to become 
the default (if the user so chooses during our install). For upgrades within a 
company, we would likely not even both to give the user the option
Comment 1 Pat McCarthy CLA 2002-07-08 15:40:46 EDT
There seem to be a few post-installation/extensions tasks that are required by 
product teams.  

Could run once plug-ins, which use the org.eclipse.ui.startup extension-point to 
get started and include logic to skip on subsequent runs be part of a 
work-around?   

Might support a process that allows the startup plugin to prompt the user to 
perform some tasks, maybe as part of a wizard, which results in preference 
changes (default perspective), file/editor associations (might even have to walk 
the resource tree), and exit by opening the new perspective/welcome.xml.

Just a thought...
Comment 2 Greg Adams CLA 2002-07-08 17:53:58 EDT
1) Your approach is one of the ones we had proposed as a potential work around 
to yourself & the eclipse team however even as a work around this is a problem 
because it would require every product team doing it (ibm and others) to play 
by the exact same rules and ensure it never ran multiple time. Otherwise we 
could have our settings undone on the next start up. Informal rules like this 
for product customization tpically don't succeed.

2) Moreover it now means there is more potential for more folks knowing about 
and using the startup early hook which is definitely not a good thing to have 
happen.

3) Are you also positive that the things that need to be configured (along the 
lines of those you outlined) can in fact be configured with API?

4) I don't recall if the startup plugin runs before the workbench is displayed. 
The timing of it could pose potential usability problems.


Comment 3 Nick Edgar CLA 2002-07-09 11:12:11 EDT
Plugins using the startup extension point are started after the workbench 
starts, in a background thread.
But for the reasons you've outlined, we would prefer to stay away from this.
Comment 4 Greg Adams CLA 2002-07-09 13:37:19 EDT
* Given it happens after the workbench is up, this means the user would see the 
wrong perspective, or the wrong welcome for a bit until the background thread 
actually ran.

* Theoretically there is no gaurantee when that code would run since its in a 
background thread. Of course realistically it may happen reasonably quick.

* If multiple extensions were installed then there is no clean resolution for 
how to handle this case (this is in fact an issue pat raised in another pr). 
That means one startup plugin could set the perspective, followed immediately 
by another changing it again.  The net is this kind of stuff really needs to be 
controlled by the platform or it can quicjly be a mess.
Comment 5 Eduardo Pereira CLA 2002-10-02 15:33:00 EDT
Fix released to 2.0.2 stream. Changed classes: IEditorRegistry, EditorRegistry, 
WorkbenchWindow, WorkbenchPage, Workbench.

If a new feature has a welcome editor and a welcome perspective its feature 
plugin will be activated on startup and code may be added to the startup method 
to change the default editor. The feature plugin should be a very small plugin 
and the startup method must guaranty that it changes the default editor only 
once.





  
Comment 6 Eduardo Pereira CLA 2002-10-02 15:43:41 EDT
Released changes to the 2.1 stream.
Comment 7 Eduardo Pereira CLA 2002-10-07 11:04:31 EDT
The fix worked on the self hosting eclipse but did not work a new installed 
eclipse. Opened bug 24454 against Update Manager.
Comment 8 Eduardo Pereira CLA 2002-10-07 14:15:27 EDT
Released code using another API from update manager. See bug 24454.
Comment 9 Eduardo Pereira CLA 2002-10-16 11:43:06 EDT
Fix is released in both streams.
Comment 10 Eduardo Pereira CLA 2002-11-04 18:05:06 EST
Created attachment 2312 [details]
Feature example.

There are 3 different set of files in this zip: a) the feature b) the plugin
associated with that feature (same id) and c) a plugin for the new editor.

To test this example. a) Download eclipse 202; b) Run it once or more; c) unzip
this file in the eclipse install dir; d) run eclipse again; e) check all new
feature in the update list; f) click yes to restart eclipse.

The perspective specified by this new feature should be opened with its welcome
editor; the startup method in the plugin associated with this feature should
run which in this example will change for *.java.

If you start eclipse another time this method should not run anymore.