Community
Participate
Working Groups
When creating a product from scratch, one does not know the necessary start level and it is always a pain to figure it out. Since in most situations these start levels are the same, I would like to add a button that populate "typical" start levels into the editor. There will be no smart implied, just a button with hardcoded values for now.
Pascal, I have a question about requirements here. I read this as doing one of two ideas: Idea one: A new button is added on the "Configuration Page" start level table that would generate default start levels for all the plugins defined by the product. You would just push "Defaults" or something like that and then the list of plugins and default start levels is populated. This would override any settings that were already specified (or else we prompt whether existing values should be overridden.) If the user later adds more plugins to the dependencies, they'd have to go back and generate these defaults again. Idea two: The user still uses the "Add" button to add a plugin(s). The user selects one or more plugins in the list and chooses a "Defaults" button which would set the values in the table for those plugins. In this case the user would still have to go back and generate defaults if they add more plugin dependencies, but it would be more expected since they are managing the start levels more explicitly. I like idea two for its explicitness/clarity, but it might not be enough of an improvement. Can you clarify? I also need some guidance on what the hardcoded/"typical" start levels need to be.
#1 is what I'm aiming for. Basically for the majority of ppl building RCP apps or IDEs on Eclipse they need to have the same set of start levels and they don't know what are those. Having a button that initializes this list is what we need. Of course we also still need to cater for the case where the user would have voluntarily changed some values and hit the default button again.
Curtis, I have submitted a patch at https://git.eclipse.org/r/25007 Note that this patch is independent of the patch in other bugs awaiting review. Pascal and I discussed the strategy at length, regarding how we decide which bundles should be added to the autostart list. We examined TargetPlatformHelper and BundleConfigurationHelper to see how different clients generate bundle start levels in the launch configuration dialog. TargetPlatformHelper was out of date. BundleConfigurationHelper relies on a launch configuration to generate the full list of bundles. Our goal with this feature is to provide the product editor user with the "typical list" that Eclipse applications have to generate. A bundle such as org.eclipse.equinox.ds does not appear in the bundle "requires" list yet the application won't run without it. For this reason, we felt it did not make sense to walk the requirements list of the product to generate this list. Instead, we try to generate the "typical" list of bundles/start levels that most people have to remember and then rely on the product editor user to recognize any that aren't needed. For most of the common cases, this solves the "I have no idea what to put for my start levels" problem.
Please note there are no p2-side changes for this. This is purely a UI-side helper.
1) "Typical..." This seems really unclear to me. Maybe "Add Defaults..." or "Add recommended...". At least by starting with "Add" it is clearer that no existing ones will be removed or altered. 2) The button should be second in the list, not at the end after remove. 3) There is no way to get the message box back after checking 'do not show again'. This is not a pattern I care for. In debug we have preferences to change from yes/no/prompt. Do we actually require a 'do not show again' option? What if that dialog was more useful, listing out all the 'typical' entries it will try to add? 4) Dialog should not have yes/no/cancel when no/cancel do the exact same thing. 5) It calculates whether any entries should be added before opening the dialog. If no entries are applicable, the dialog doesn't show (nothing happens), but the button will be enabled. The user doesn't know whether the feature is broken. This is another reason why the dialog should always show up with a list of recommended start levels. 5b) If the dialog is simply confirmation, the work to compare against existing start levels could be done after the user hits yes.
Thanks for the feedback, Curtis. We really got caught up in that wording for "Typical" vs. Defaults etc. It's good to get an opinion from someone not immersed in it. The other feedback makes sense to me. Will prepare a new patch.
(In reply to Curtis Windatt from comment #5) There is a new patch available in Gerrit ( https://git.eclipse.org/r/#/c/25007/ ) I agree with your suggestions here and took the approach of calculating all the proposed changes and presenting to the user ahead of time. The model is not touched until confirmation. If there is nothing to be added, the user is told this in a different message. I elected to always keep "Add recommended" enabled because I did not want to trust that all existing model change handling was complete and correct. I noticed that there are model change events fired that aren't checked in the change handler, yet they can cause the invocation of updateRemoveButtons. I could have enabled the button on any model change event, but I think that doing so when nothing of interest changed is worse than always keeping it enabled. I've responded to the rest of your suggestions below with annotations for what I did. > 1) "Typical..." This seems really unclear to me. Maybe "Add Defaults..." > or "Add recommended...". At least by starting with "Add" it is clearer that > no existing ones will be removed or altered. I went with "Add Recommended." This is the word we were looking for but couldn't come up with. "Defaults" to us implied a more formal set of defaults, and really these are just the typical, recommended defaults for many apps. It's a better word. > > 2) The button should be second in the list, not at the end after remove. Done. > > 3) There is no way to get the message box back after checking 'do not show > again'. This is not a pattern I care for. In debug we have preferences to > change from yes/no/prompt. Do we actually require a 'do not show again' > option? What if that dialog was more useful, listing out all the 'typical' > entries it will try to add? That's what I did. We now show all bundles and start level/autostart values that will be added. > > 4) Dialog should not have yes/no/cancel when no/cancel do the exact same > thing. This is now an OK/Cancel dialog since it's just for confirmation. Since there could presumably be different information every time, we always show the confirmation. > > 5) It calculates whether any entries should be added before opening the > dialog. If no entries are applicable, the dialog doesn't show (nothing > happens), but the button will be enabled. The user doesn't know whether the > feature is broken. This is another reason why the dialog should always show > up with a list of recommended start levels. Done. You see the list of proposed additions. If you've already added them all, then we tell you that you already have them all and that there's nothing to add. > 5b) If the dialog is simply confirmation, the work to compare against > existing start levels could be done after the user hits yes. We do some work before now. We *do* want to see if the plugin is already listed in the table, because we don't want to override it. But other than that, we just build a list of confirmation strings for the user. After confirmation, we build the actual model objects and add to the configuration.
Curtis, you made this note in a different bug so I'm moving it here. (In reply to Curtis Windatt from comment #4) > 6) Just a reminder for me to test that the editor is marked dirty correctly > when the start levels are changed. I did check this (dirtied when bundles are added, not dirtied when a bundle is not added, etc.). Note that if someone added the bundle already in the table, we don't add it as a "recommended" on the assumption that they know what they are doing. So we aren't really looking for changed start levels in this feature, but rather looking to see if the bundle is already in the list or not. If the user changes any of the start levels, the editor is dirtied, just as before.
http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=bae7fb46b92f6c2cea9707b91402b099aa9ff9d0 Merged with master Note: Can you have the commit message include the title of the bug report, rather than just a link. i.e. Bug 426529 - [Product][Editors] Allow for default start level to easily be loaded Change-id: ... Signed-off-by: ... I edited the messages for clarity. Also PDE uses the term 'plug-in' instead of 'bundle' http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=4b40337cc84017185f8900607466e531fd2bfd27
(In reply to Curtis Windatt from comment #9) > Note: Can you have the commit message include the title of the bug report, > rather than just a link. > i.e. > Bug 426529 - [Product][Editors] Allow for default start level to easily be > loaded Of course. I thought that's what I did. Sorry! Thanks for the quick turnaround and help on the wording.
