Community
Participate
Working Groups
This is related to removing the need for a separate program launcher to launch eclipse. https://bugs.eclipse.org/bugs/show_bug.cgi?id=76855 deals with the passing in of the arguments. Our products use a launcher to a) pass in command line arguments and b) perform some specical processing before eclipse actually comes up. One current use of the special processing is the ability to warn the user that the current level of GTK is not valid for use in DBCS locales if it isn't at the right level. Another example is the ability to prevent the launch of eclipse with a dialog indicating why the launch was prevented. When we ship trial or evaluation copies these are timelimited. We pop a dialog up stating how many days are left in the trial then proceed to launch eclipse. Once the evaluation period is over the dialog comes up indicating that fact and then exits and does not launch eclipse. In order to remove the need for a separate launcher application we have to be able to process the command line arguments before eclipse proper loads up. Our applications are based on the eclipse IDE not an RCP application so we don't currently have any ability to perform processing while the IDE is starting up.
Rather than defining a new extension point (at either the generic workbench or IDE level), I'm inclined to augment the existing org.eclipse.ui.startup extension point (at the generic workbench level) to allow an entry to be run before the workbench is opened (current entries only run after the workbench is opened). Such entries would be given the ability to veto the open (or perhaps just call IWorkbench.close()).
Consider for M5.
Note that this API won't be useful for checking things like VM version. It's typically too late to check this once the application extension runs.
Peter, have you tried to use the StartLevel service? Some degree of what you want seems to be doable. For example your plugin can be run early do the necessary checks and something is wrong it can stop the platform. Of course I guess that is probably too easy :-)
This sort of hook should be independent of the application and the UI. The common usecases are license checking and login prompts. The net effect of both could be quite profound (e.g., may change the set of plugins available or what application to run). We should investigate a hook just before running the application. There will be a trick around SWT and the Display but Steve assures me that if you create and dispose the Display before creating a new one we should be happy.
*** Bug 50164 has been marked as a duplicate of this bug. ***
Moving confirmed bugs/enhancements out of the "inbox"
Slipping milestone for bugs not fixed in time for 3.1 M5.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
