Community
Participate
Working Groups
We currently have a mechanism for creating repository task and reporting bugs. However, this could be better integrated for new users. For example, a "Report but or feature request" could be added to the Help menu. This would iterate thorough installed plug-ins and their issue trackers, and then allow one to be selected (regardless of what repository connector it uses). It would then open a rich editor and encourage the user to add additional information (e.g. paste in screenshot, add stack trace, describe steps to reproduce).
Balazs: I started on this for you by adding a Help -> Report Bug menu action. See the attached context.
Created attachment 65871 [details] mylar/context/zip
*** Bug 190514 has been marked as a duplicate of this bug. ***
Balzas: please prioritize this since it would be great to have in 2.0, and would need to be done by the end of next week to make the cut.
Created attachment 75550 [details] plan I made a plan. If it's good for you, I will make a prototype.
Hmm. You do have a poind about too many plugins, but features are kind of problematic, as far as I know new provisioning story won't have features at all. Add repository button on wizard page 2 is confusing. That page meant to select feature from the list... Instead of page 3 we should open regular task editor. I think it is generally a good idea to stay in a wizard for as short time as possible.
Excellent plan document Balazs! I agree that we should open the new task editor instead of having Page 3, for reasons that Eugene describes. Regarding Page 2, I think that that under the covers we're stuck doing this via plug-ins, because only plug-ins can specify the necessary extension point. But in the UI we definitely need something higher-level than plug-ins because there are often hundreds. I'm leaning towards features, because they are the main user-visible component that's independently installable and are currently first class in the UI. If the new provisioning work adds another first-class component beyond features we could work with that as well. Let's chat more about this during today's call.
Mik, aren't features going to be retired by the new provisioning story? See 3.4M1 release...
What do you think about to use plug-ins in a tree structure? Like this: org eclipse mylyn equinox apache jasper
The problem is that to the user, plug-ins are an implementation detail. The only place that details about plug-ins need to show up is in the Error Log, where other implementation details surface as well (and notably the Error Log is not part of the plain Java package of Eclipse). Balazs: what needs to show up is whatever the user knows they have installed. Currently that's features but in the future it could be something else, and we could update your cord accordingly when that happens. Eugene: could you point me at a document on the new provisioning story that we should be considering? We could do that on a separate bug report since this one should be focused on the current implementation.
Didn't you read the New and Noteworthy for 3.4M1? http://wiki.eclipse.org/Equinox_Provisioning_M1
Current idea for the user interface: - display all installed branding features in a pretty list (similar to Help > About) - open a (simplified) bug editor that pre-selects attributes using the extension point specified in bug 212209 based on the feature id
Created attachment 89624 [details] first pass
Created attachment 89952 [details] second pass This patch has been committed to CVS.
Created attachment 89953 [details] screenshot of report bug dialog
Updated screenshots are on bug 212209. The next step is to determine the user interaction when a support provider or product has been selected in the wizard. Should that always open the task editor or do we have additional requirements, e.g. redirecting the user to a web page?
*** Bug 195698 has been marked as a duplicate of this bug. ***
As proposed in the description of this bug the wizard opens a task editor by default. Extensions may change that behavior by registering an errorReporter with o.e.m.commons.core that handles FeatureStatus objects.
