Community
Participate
Working Groups
All RSE wizards, dialogs, preference pages and other UI related elements must use standard Eclipse mechanisms to present error, warning and information message to the user. Therefor the proprietary and not Eclipse standards conform implementation and use of the ISystemMessageLine widget needs to be dropped and replaced by the use of the built-in DialogPage/PreferencePage/Launch Configuration Tab message presentation methods. The IMessageProvider similar methods dealing with SystemMessage objects may or may not extracted into a ISystemMessageProvider interface. I think it would be better to do without such interface, but it might be helpful for dealing with SystemMessage objects.
I'm not sure whether this request is valid. In my understanding, the use of ISystemMessageLine is that RSE widgets (such as a SystemHostCombo or connection browse button) have a means for displaying error and warning messages, regardless of what Control they are embedded in. Note that this makes only sense for Widgets that have some concept of validation in themselves (in most cases, the containing Control will have that concept of validation; so, where is ISystemMessageLine currently used?) I agree that Eclipse standard message lines should be used wherever possible, e.g. make wizard pages print messages to the wizard message line make dialogs use MessageDialog or IconAndMessageDialog The point is, that these Controls have different means of accessing the message line; ISystemMessageLine unifies access to all of these, such that a widget can be embedded without having to know where it can print its messages to. In Eclipse Platform, the UI Forms Framework has also unified access to the message line. It works through the IMessageManager interface, and messages are presented in a Forms header - so, unfortunately this seems to work in managed Forms only: EclipseCon2007 - UI Forms Presentation: http://www.eclipsecon.org/2007/index.php?page=sub/&id=3664 Associated Sample Code: http://eclipsezilla.eclipsecon.org/php/attachment.php?bugid=3664 Important Classes: ManagedForm#getMessageManager() ManagedForm#getToolkit()#adapt() Thinking again, I guess we should perhaps change ISystemMessageLine into something that works more like IMessageManager: * Allow multiple Controls to each set/reset a message with their own key * Display one or more of them simultaneously; with decorators per widget At any rate, I agree that AbstractWizardPage should certainly not implement ISystemMessageLine but rather provide a Getter for the message line interface (composition is better than derivation). This is requested by bug 199031.
Whatever the outcome of the defect will be, as long as we _do_ think about a better, more generic and Eclipse conform way of handling messages, the defect had been valid. For the rest, thats what discussions are for, finding the best solution for all needs. I will not argue to get the comment#0 fulfiled exactly as it has been written down.
