Community
Participate
Working Groups
Build Identifier: 3.4.2 Build id: M20090211-1700 On Windows XP go to Control Panel->Accessibility Options, choose the "display" tab, check "use high contract". click OK button. then the system come into large characters and high contrast model. 1. Help->Software Updates->Find and Install The install/update dialog shows. Drag the dialog to be smaller, the content can't totally show and there are no scroll bars either. 2. The same problem shows on the next "Install", "Update", "Install/Update", "Update Manager" dialogs, Reproducible: Always
In more recent versions of Eclipse, these dialogs have been merged into a single dialog in Help -> Install New Software... The dialog in question is quite large, and in high contrast mode, it does become large enough that it would require scrollbars on a less-than-high resolution monitor. (On my 1600 x 1200 display it looks fine in high resolution, unless I resize it to be smaller... which is not recommended...). So what this dialog needs (in order to be readable on small monitors) is an org.eclipse.swt.custom.ScrolledComposite parent for the client area. I am assuming that this is not something the JFace folks would like to add for all dialogs, in org.eclipse.jface.dialogs.Dialog.createDialogArea(Composite) and/or maybe org.eclipse.jface.wizard.WizardDialog.createDialogArea(Composite). Paul, is this correct? On that assumption, then, this particular dialog class is called: org.eclipse.equinox.internal.p2.ui.dialogs.ProvisioningWizardDialog And the git repository to clone to see its source code is: http://git.eclipse.org/gitroot/equinox/rt.equinox.p2.git (Just get the 'master' branch. When you import projects, select the org.eclipse.equinox.p2.ui bundle). Paul, can you suggest the best way to approach this? Should org.eclipse.equinox.internal.p2.ui.dialogs.ProvisioningWizardDialog override org.eclipse.jface.wizard.WizardDialog.createPageContainer(Composite) and create a ScrolledComposite for the pageContainer instead of a Composite? Or should they create a ScrolledComposite on every org.eclipse.equinox.internal.p2.ui.dialogs.ProvisioningWizardPage, for example in org.eclipse.equinox.internal.p2.ui.dialogs.AvailableIUsPage.createControl(Composite) and org.eclipse.equinox.internal.p2.ui.dialogs.SelectableIUsPage.createControl(Composite) and org.eclipse.equinox.internal.p2.ui.dialogs.ResolutionResultsWizardPage.createControl(Composite) and org.eclipse.equinox.p2.ui.AcceptLicensesWizardPage.createControl(Composite)? In case it's helpful, an example of creating a ScrolledComposite parent to contain dialog contents can be found in the Preferences dialog. Automatic scrolling will occur if the dialog gets too small, for example in high contrast mode. Here's the method where the PreferenceDialog creates a ScrolledComposite: org.eclipse.jface.preference.PreferenceDialog.createPageContainer(Composite) (the source for this class can be found in http://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git in the org.eclipse.jface project)
Susan, do you have any opinion on making the org.eclipse.jface.wizard.WizardDialog (org.eclipse.jface) follow the same pattern as the org.eclipse.jface.preference.PreferenceDialog and providing a protected createPageContainer(Composite parent) method? We would probably make the current method on WizardDialog protected and allow the subclasses (like ProvisioningWizardDialog) to override with something similar to the PreferencesDialog. PW
(In reply to comment #2) > Susan, do you have any opinion on making the > org.eclipse.jface.wizard.WizardDialog (org.eclipse.jface) follow the same > pattern as the org.eclipse.jface.preference.PreferenceDialog and providing a > protected createPageContainer(Composite parent) method? > > We would probably make the current method on WizardDialog protected and allow > the subclasses (like ProvisioningWizardDialog) to override with something > similar to the PreferencesDialog. That sounds right to me. ProvisioningWizardDialog is internal to p2, so from a p2 point of view, there is no risk at all in exposing that method. From a jface point of view, making createPageContainer dialog doesn't seem like a huge risk, but we should doc it as explicitly as possible...ie, any layouts we assume the container has (gridlayout), etc. etc.
> From a jface point of view, making createPageContainer dialog doesn't seem like > a huge risk, but we should doc it as explicitly as possible...ie, any layouts > we assume the container has (gridlayout), etc. etc. As this can't be guaranteed for existing code, I guess the new behavior would be off by default, right?
(In reply to comment #4) > > As this can't be guaranteed for existing code, I guess the new behavior would > be off by default, right? Right now it is simply an internal method on WizardDialog, used by createDialogArea(*). Clients that actually subclass WizardDialog would have overridden createDialogArea(*) and would not be effected. PW
(In reply to comment #5) > (In reply to comment #4) > > > > As this can't be guaranteed for existing code, I guess the new behavior would > > be off by default, right? > > Right now it is simply an internal method on WizardDialog, used by > createDialogArea(*). Clients that actually subclass WizardDialog would have > overridden createDialogArea(*) and would not be effected. Yes, but they could currently also call super.createDialogArea(...) and if we now start to expect a certain layout, they might be broken, no?
(In reply to comment #6) > Yes, but they could currently also call super.createDialogArea(...) and if we > now start to expect a certain layout, they might be broken, no? ah, I agree. This will have to be equivalent to a no-op for those that do override WizardDialog, unless they make the change (opt in). PW
yeah, I wasn't suggesting any new constraints. Just that we try to doc the assumptions that are implicit in overriding that method. Such as "if you override this method and do not override createDialogArea, your page container must....<insert assumptions here>"
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
