[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-ui-dev] UI-based bug reporting / feature requesting
|
Something to consider: using tooltip to describe the items in the
product/component combo box is not accessible for people without a mouse.
Simon :-)
"leon j breedt"
<ljb@xxxxxxxxxxxxxx> To: <platform-ui-dev@xxxxxxxxxxx>
Sent by: cc:
platform-ui-dev-admin@ Subject: RE: [platform-ui-dev] UI-based bug reporting / feature
eclipse.org requesting
03/27/2002 07:22 AM
Please respond to
platform-ui-dev
More comments....
> The product and component are the used often. I'm unsure if this should
> go on the first page or the second page (probably second page if you are
> going with the suggestion in the next paragraph). The rest I find the
> default values are usually correct. Once a summary and description is
> entered, it should be possible to just "finish" without having to go to
> the other pages (i.e defaults should be sufficient).
I'm not sure the product/component should be on the next page...when a
user experiences a problem, and decides to report a bug, we have no
idea where it happened. As I see it, it could be defaulted only if
something
else like another plugin determines this info and supplies pre-initialized
defect report to the wizard.
Also, I'm thinking what will work well, instead of seperate
product/component
widgets is a combo with the item names being "Product/Component". i.e.
"JDT/Core"
"CDT/Debug"
And so on. This seems to be the terminology everyone uses already. Maybe
the description of these components could then become a context-sensitive
help item (tooltip?).
> Maybe nice to provide a "template" for the description field. It
> could list
> things the user should remember to fill out. It could also automatically
> include the build number (most forgotten piece of information I find).
Hmm, I build this behind their back from the various parts
of information available, and provide a Preview button.
An example Description the plugin will generate:
Build: 20020321
Java VM: 1.3.1-b24, Sun Microsystems Inc.
Detail:
<user-supplied-description-here>
Stacktrace:
<stack trace, if applicable>
> You may also want to keep your public interface names generic (i.e.
> IProblemReport instead of IBugzillaBug). Where the problem gets stored
> could be plugable (i.e. by default to bugzilla, but maybe someone would
> want to provide an extension to save to another bug tracking system).
I think I've come up with a nice way of doing this, although I'm open to
suggestions for better ways:
I've defined a "provider" extension point for this plugin, and plugins
which
provide an implementation have an entrypoint class which implements the
IProvider
interface. This interface defines actions like retrieving the list of
repositories
configured, and creating new defect reports.
The Bugzilla support is now just another provider, albeit one which ships
with the
plugin.
Example (for the always-available Eclipse repository, will be slightly
different
for user-defined repositories):
IProvider provider =
ProviderRegistry.getRegistry().getEclipseProvider();
IDefectRepository repository =
provider.getRepository(ECLIPSE_REPOSITORY_NAME);
IDefectReport report = provider.createDefectReport(repository);
// set known info
report.setProduct(xxx);
report.setPlatform(xxx);
I changed the names to be mostly "defect", I don't like the word "bug" :)
> You should also consider providing a message at the end with the problem
> report number created.
Good idea...May be unreliable though, if people template their
Bugzilla installations, unless there is some other way to grab this.
Regards,
Leon.
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
