Community
Participate
Working Groups
Sometimes super users want functionality to be put in early startup, that won't be useful for the rest. It would be useful then to set org.eclipse.ui.startup extension point to be disabled by default and allow such user to enable it in "Preferences -> General -> Startup and Shutdown" if he knows what he do. Our particular use case is bug 173040 where we want to start error log view on any first log event. See Daniel Megert comment: https://bugs.eclipse.org/bugs/show_bug.cgi?id=173040#c11
I will fix this if Platform UI agrees on it.
(In reply to comment #1) > I will fix this if Platform UI agrees on it. that would be great. I've started prototyping and run into one problem: Platform UI stores preference only about disabled plugins and then there's no way to enable that plugins using preference. There's another preference needed, or some tweaking to already existing one.
>There's another preference needed, or some tweaking to already existing one. Yep. Fortunately this is an internal preference.
Just to be clear, you're suggesting a new attribute to the startup extension point for "enabled" with the default being true (for backwards compatibility)? If so, absolutely - great idea!
Yes, that's my suggestion. I'll try to do this for M6, so that we can also close bug 173040.
This is a bit more complicated than I hoped because - the UI prefs aren't 100% stored: there's just a black list ==> we also need a white list for those that are disabled by default - the individual attributes are currently only read in the EarlyStartupRunnable ==> we could get and check the 'enabled' attribute there but that seems conceptually wrong to me: we should make that check before we create the runnable. My preferred solution to this is to introduce a StartupDescriptor or StartupRecord that holds all that information together for each contribution. I have the extension point addition in place but the above changes need more work. I hope to get this done during next weeks fix pass.
> I hope to get this done during next weeks fix pass. That did not work out.
Mike, according to Philippe we also need PMC approval for extension point changes. I would like to add the following attribute: <attribute name="enabled" type="boolean" use="default" value="true"> <annotation> <documentation> the startup takes place if this attribute is &quot;true&quot; or if this optional attribute is not present. The user can override this setting in his preferences. </documentation> </annotation> </attribute> Or in more readable form: enabled (true | false), default: true - the startup takes place if this attribute is "true" or if this optional attribute is not present. The user can override this setting in his preferences.
(In reply to comment #8) > Mike, according to Philippe we also need PMC approval for extension point > changes. > > I would like to add the following attribute: > > <attribute name="enabled" type="boolean" use="default" value="true"> > <annotation> > <documentation> > the startup takes place if this attribute is > &quot;true&quot; or if this optional attribute is not present. The user > can override this setting in his preferences. > </documentation> > </annotation> > </attribute> > > > Or in more readable form: > > enabled (true | false), default: true > - the startup takes place if this attribute is "true" or if this optional > attribute is not present. The user can override this setting in his > preferences. > Traditionally we've had issues with boolean attributes like this. We define two states and then we discover a third that'd we'd like to expose and suddenly we have two boolean values with some crazy interaction. I'd suggest using an enumeration attribute instead with a name like "mode." Perhaps there'd be different behavior based on whether or not the plug-in was already loaded (via osgi.bundles in an RCP app) or whether or not the extension lived in the product plugin or what have you.
>Traditionally we've had issues with boolean attributes like this. Examples? >We define >two states and then we discover a third that'd we'd like to expose and suddenly >we have two boolean values with some crazy interaction. Sorry but this indeed looks like "crazy" to me. At least in JDT and Text land we make API that is requested and needed and do not prepare to 'crazy' stuff. Of course if Platform UI according to their experience propose a better way I am all open. Mike?
Adding Jeff for more history about the pain that using boolean values has caused us. I'm pretty sure we've discussed it several times in the arch calls. There's *always* a third option (we just don't what it is yet).
Yes, there is alway more that people want ;-) My personal attitude is: you can always give more later. That's normally less pain than exposing too much upfront. But that's just me.
(In reply to comment #10) > >Traditionally we've had issues with boolean attributes like this. > Examples? There are two examples of this in the actionSet extension point alone - the @pulldown attribute and the combination of @retarget/@allowLabelUpdate are both examples of where we've neglected to look forward when defining our extension points. We have similar issues in our java APIs as well. The only one off the top of my head is the part state/zoomed state distinction in IWorkbenchPage. > >We define > >two states and then we discover a third that'd we'd like to expose and suddenly > >we have two boolean values with some crazy interaction. > Sorry but this indeed looks like "crazy" to me. At least in JDT and Text land > we make API that is requested and needed and do not prepare to 'crazy' stuff. > Of course if Platform UI according to their experience propose a better way I > am all open. Mike? > Here's an example that I could easily see us doing - having an unmodifiable "on" state for RCP applications. This state would override any preference or setting specified by your suggested attribute. It'd be another one of those boolean pairs like @retarget/@allowLabelUpdate where the value of one makes the value of the other irrelevant. Having an enumeration for values here would allow us to head these situations off before they happen with absolutely no pain in the short term.
Would the following attribute better fit your needs: Attribute 'enablement' or 'startupMode' with currently allowed values 'onByDefault' and 'offByDefault'? This would allow to e.g. add 'alwaysOn' or 'ignoreUserPref'. Or we could use numbers instead of strings (not sure what's the preferred thing for Platform UI - I'd prefer strings though). Personally I'd still prefer to add just what we need now, unless there's already some requests in bugzilla to do more in the future. But I am also absolutely fine with the other approach.
(In reply to comment #14) > Would the following attribute better fit your needs: > > Attribute 'enablement' or 'startupMode' with currently allowed values > 'onByDefault' and 'offByDefault'? This would allow to e.g. add 'alwaysOn' or > 'ignoreUserPref'. Or we could use numbers instead of strings (not sure what's > the preferred thing for Platform UI - I'd prefer strings though). Sounds good to me (an attribute with string values). It looks like we already have an idea what kind of additional values we might want in the future.
Moving to 3.5. Too late now.
On a second thought we should not offer this and should not make it easier to use the startup extension point. A better solution for bug 173040 would be a new extension point where plug-ins can register for log events via extension point.
