Community
Participate
Working Groups
RSE wizards are using very untypical and in violation to the Eclipse UI guidelines a own message area at the bottom of the wizard. RSE needs to drop that and return to Eclipse UI guideline compliance by showing error message within the default wizard dialog message area at the top of the dialog.
AbstractSystemWizardPage forwards message to the standard Eclispe mechanism instead of using it's own control.
This needs to be reviewed by using products wishing to migrate to this version of RSE. It may be necessary to accommodate them based on prior message presentation standards.
Does it really make sense to keep violating all UI guidelines Eclipse have? Errors, warnings and messages are shown at the top of the wizard within the therefor available message area. That a simple rule of consistency. Is there is any known product which does require the error message on the bottom of a wizard page? It's very, very easy to let control that wizard page boolean attribute, so at the end I don't care as long it can be put at the location where it belongs in standard Eclipse. Please note that this applies only to the default wizard pages we have in open source. It does not affect any additional product specific as those pages can still decide to use explicit message lines. There is no API added or removed. I'm sure 99% of the clients does even notice that the error messages moved up to the top of the wizard. BTW: There had been no complains about the location of the error message since the very beginning of RSE 2.0 month ago. The new connection wizard does not have the message line at the bottom. Why should it be different with the "New Filter" wizard in example?
>I'm sure 99% of the clients does even notice that the error messages moved up >to the top of the wizard. I meant to write "doesn't".
(In reply to comment #2) > This needs to be reviewed by using products wishing to migrate to this version > of RSE. It may be necessary to accommodate them based on prior message > presentation standards. I agree with Uwe, the Standard in Eclipse wizards and dialogs is to have messages in the designated message area. Failing to do so in RSE 2.0 was a bug and I'm glad it has been fixed. No APIs or NLS strings are affected, only the widget location has been changed. This might be an issue for automated GUI testers but IMHO breaking this is OK in a 2.0.x release. The version numbering guidelines in http://wiki.eclipse.org/Version_Numbering are not 100% explicit for this case: they say that bug fixes go to the 3rd version segment but also say that "externally visible" changes go to the 2nd version segment. From our own product perspective, we need this bug fix because our users expect Eclipse compliance and consistency across the entire product, and all other wizards have messages in the message area. It is confusing for users to have it in a different location when creating a new filter. But since the version numbering guidelines are not explicit, I'm open to discussing this.
Actually, when reviewing the code changes, I noticed that breaking API changes were made for this fix: * AbstractSystemWizardPage.setErrorMessage(String) AbstractSystemWizardPage.setMessage(String) AbstractSystemWizardPage.setMessage(String,int) were made final --> it could happen that code which overrides any of these and works OK against TM 2.0 would not link against TM 2.0.1, this is not acceptable. We cannot make such change in a 2.0.x release -- we can only update Javadoc of the methods and inform users that they should not override. * RSEDialogPageMessageLine.isDisposed() This is a new public API method in a public API class. Because of it, users could write programs against RSE 2.0.1 that would not run against RSE 2.0. This is also not acceptable in a 2.0.x release. Please try and revert the API breaking changes. For the isDisposed() issue this should be easy since the private "page" is initialized in the constructor to be actually "this" i.e. the AbstractSystemWizardPage so it can equally well ask itself whether it has been disposed. For the methods you declared "final" please just remove the final modifier. You can file a new enhancement request for TM 3.0 to actually make the API changes if you want. Reopening till this is fixed.
Done.
