Community
Participate
Working Groups
the ejbdoclet and webdoclet follow eclipse fonts, however the main XDoclet preference page for selecting the xdoclet libraries does not.
The following preference screens don't display in the correct Eclipse font: Data Label Decoration Output Internet Cache Web and XML CSS DTD HTML JavaScript JSP Task WSDL XML Files XML Schema WebServices Scenario Defaults Server and Runtime XDoclet
Lawrence, as our newly annoited UI consistency focal point, I'm turning this over to you.
Dave, as you offered to investigate the solution to this problem yourself I'm assigning the bug to you. Thanks!
Preliminary list of affected components: org.eclipse.jst.j2ee.ejb.annotations.internal.xdoclet.ui.XDocletPreferencePage.java org.eclipse.jst.jsp.ui.internal.preferences.ui.JSPSourcePreferencePage.java org.eclipse.jst.ws.internal.consumption.ui.widgets.PublishWSWidget.java org.eclipse.jst.ws.internal.creation.ui.widgets.ServerWizardWidget.java org.eclipse.wst.css.ui.internal.preferences.ui.CSSSourcePreferencePage.java org.eclipse.wst.internet.cache.internal.preferences.CachePreferencePage.java org.eclipse.wst.javascript.ui.internal.common.preferences.ui.JavaScriptFilesPreferencePage.java org.eclipse.wst.javascript.ui.internal.common.preferences.ui.JavaScriptSourcePreferencePage.java org.eclipse.wst.rdb.core.internal.ui.preferences.LabelDecoratorPreference.java org.eclipse.wst.rdb.core.internal.ui.preferences.OutputPreference.java org.eclipse.wst.sse.ui.internal.preferences.ui.AbstractColorPage.java org.eclipse.wst.sse.ui.internal.preferences.ui.EmptyFilePreferencePage.java org.eclipse.wst.sse.ui.internal.preferences.ui.FilePreferencePage.java org.eclipse.wst.sse.ui.internal.preferences.ui.TaskTagPreferencePage.java org.eclipse.wst.wsdl.ui.internal.util.WSDLPreferencePage.java org.eclipse.wst.xml.ui.internal.catalog.XMLCatalogPreferencePage.java org.eclipse.wst.xml.ui.internal.preferences.WorkbenchDefaultEncodingSettings.java org.eclipse.wst.xml.ui.internal.preferences.XMLFilesPreferencePage.java org.eclipse.wst.xsd.ui.internal.preferences.XSDPreferencePage.java
Created attachment 36244 [details] xdoclet preference page fonts First patch installment. Did I do it right?
Hi Janet. David has identified many WTP preference pages that do not use the standard Eclipse font. Can you tell us which font these pages should use?
BTW: My plan was to have vitually everything DIALOG_FONT. The only exception would be preference pages that had something like an editor window ... like Web and XML>CSS Files>CSS Styles (the sample text window). That should probably use JFaceResources.TEXT_FONT. Let me know if I'm in-line with your thinking. I wasn't planning on changing preference pages that display correctly, but set the font a little differently than the way I've done it in my sample patch.
Created attachment 36265 [details] Image of changes to Font's when default OS Property settings are changed Can you attach a screencapture of the problem you are seeing? Ideally the fonts should be using the System Font settings, so that when the user makes changes its reflected in the resulting dialog.
I'm not talking about the System font. Eclipse has it's own font preferences to set fonts of various things including dialog fonts. If you change Eclipse's dialog fonts, then all dialogs presented by Eclipse (including the preference pages) are displayed in this new font. Some of WTP preferences already follow this standard, but the previously listed preference pages do not. All WTP dialogs should follow the standard laid down by Eclipse. I'll also include a screen capture to demonstrate the problem.
Created attachment 36268 [details] xdoclet not displaying Ecplise dialog font
Created attachment 36270 [details] xdoclet not displaying in the correct font
Comment on attachment 36270 [details] xdoclet not displaying in the correct font Eclipse Dialog fonts are accessed via Eclipse >menu /tree selection: Window>Preferences, General/Appearance/Colors and Fonts, Basic/Dialog Font
Created attachment 36908 [details] complete patch Complete set of patches for this bugzilla entry.
Created attachment 36910 [details] complete patch sorry about the previous one. I had to tweak the path file because of some problems, but didn't save it. Here it is again.
David, thanks for the patch. When reviewing your patch I noticed that you made a lot of changes to the parent font. I think it's better practice to have the method that creates the composite update the font rather than having downstream clients (subclasses) change the font of composites they did not create. Can you fix the references such as this.applyDialogFont(parent); by placing the applyDialogFont call in the method where the composite is created? This may also reduce the number of locations this call is needed. When making the update you should also notice that some of the plug-ins have changed since you created your complete patch.
Thanks for your comments Lawrence. I agree that the backward parent reference was pretty hokey, but I wasn't sure how else to do it. I'll revise based on your suggestion.
As a tip, in the method that you make the call to change the parent component's fault, select the method name, right click and select to find the references to this method. You can then find the method(s) that call(s) this one and pass in the parent component.
Lawrence, I'm back at it again. I see some new code with text inside a graphic. That is a bad idea for 2 reasons. You can't changed the font inside the graphic, and you can't translate it. Would you like me to address this issue, or leave it as someone else's problem. It could be debated if this is within the scope of my change. org.eclipse.jst.ws.internal.creation.ui.preferences.ScenarioDefaultsPreferencePage Thanks, Dave
BTW: My "fix" would be to edit the graphic to remove the text, and create a separate field somewhere to contain the text.
Is this part of the WTP Preference dialog.. ? Could you show a screencap of what you are seeing?
Created attachment 39921 [details] WTP preference page with text embedded in the graphics The two sliders in this dialog alter the graphic to the right of the slider. Each graphic that is displayed has embedded text. Should I enter another bugzilla for this? Thanks, Dave
The images are translatable.. and have been sent to the Translation centre's already. I would suggest a new bugzilla, since those images are part of the WebServices wizard work.
(In reply to comment #22) > The images are translatable.. and have been sent to the Translation centre's > already. I would suggest a new bugzilla, since those images are part of the > WebServices wizard work. Thanks Janet. Based on your comment, I don't know if there's really an issue. The translation work for this item is to edit the graphic. It's a little more tedious for the translator, but still workable. As far as the font size goes, tool tip text is pretty small anyway and the text could be considered similar to tool tip text. In your opinion, is there really an issue to report? THanks
I don't think this is an issue. But the development team (Chris Brealey and Joan Haggarty) may still be interested in potential solutions that David has suggested.
Done. See 139540.
Created attachment 39988 [details] new patch Lawrence, Here we go again. You may still have comments ... in particular the class AbstractPreferencePage. I'm not sure what to do about classes that inherit this abstract class and add widgets. The additional widgets won't have the correct font. The choice was to put the font setting in the base class so nobody has to worry about it, or force everyone who adds widgets to set their own fonts. I thought the second choice was error prone so I put the font setting in the base class. It's hidden in SetSize which doesn't seem quite right, however the fonts should be set before setting the size so that's why it's there. BTW: good comment of pushing the set font into the base classes. It's a bit embarassing that I didn't think of doing that the first time around!
Created attachment 41680 [details] Patch for various preference pages Dave, your patch looks good. There are a couple problems (one which seems to be because I took too long to review and the plug-in has been updated the second which looks like a problem with the patch file). I've created an updated patch based on S-1.5RC3-200605162029. I included an update for the validation preference page (although this page still needs some work as buttons and text do not move to make room for the larger font size). David - I've cced you for review and approval. See comment #1 for information on the preference pages that do not respect the dialog font size. To reproduce the problem go to the Colors and Fonts preference page (General->Appearance->Colors and Fonts), select Basic->Dialog Font and change it to a larger size.
If it helps, the plug-ins affected by the changes in the patch are org.eclipse.jst.j2ee.ejb.annotations.xdoclet org.eclipse.jst.jsp.ui org.eclipse.jst.ws.consumption.ui org.eclipse.jst.ws.creation.ui org.eclipse.wst.internet.cache org.eclipse.wst.javascript.ui org.eclipse.wst.rdb.core.ui org.eclipse.wst.sse.ui org.eclipse.wst.validation.ui org.eclipse.wst.wsdl.ui org.eclipse.wst.xml.ui org.eclipse.wst.xsd.ui I'm targetting to RC3 and moving to the assigned state as Dave has already investigated and has attached a proposed fix.
Forgot to actually CC David when I made comment #27
The concepts look right to me ... Amy, will you please review details and/or commit the changes relevent to us? Thanks.
If it helps, I can do the commit/release for all the pages once approved.
Created attachment 41826 [details] updatedPreferencePages Lawrence, it's probably best for to release all these changes at once, so I'll let you do the honors. Here were some of my thoughts though: Is there a reason why in some places: this.applyDialogFont(composite) is called instead of: applyDialogFont(composite) Here are some modifications I made in the SSE code: -sse.ui TaskTagPreferencePage: moved call to "applyDialogFont(composite)" from TaskTagPreferencePage to PropertyPreferencePage Regarding sse.ui's AbstractPreferencePage: Adding "applyDialogFont(composite)" to setSize is fine since setSize is supposed to be called after all controls are added in createContents but it should be consistently done this way then. So I made changes to the following files to add "applyDialogFont(composite)" to "setSize(composite)" and make sure "setSize(composite)" is called in createContents: EmptyFilePreferencePage AbstractPreferencePage AbstractColorPage JavaScriptFilesPreferencePage JSPFilesPreferencePage JSPSourcePreferencePage While verifying, I noticed we should do something similar to our property pages as well. Is there separate bug open for that issue?
Amy - I'm not aware of a second bug. Please go ahead and open one. Dave, care to tackle another one? David - Do you approve of this fix with Amy's changes?
(In reply to comment #33) > Amy - I'm not aware of a second bug. Please go ahead and open one. Dave, care > to tackle another one? > David - Do you approve of this fix with Amy's changes? I don't recall the logic of me using "this" some places and not others. It seems redundant. Do you want me to create another patch with this corrected? I like Amy's "bigger picture" consistency changes. I'm going to apply the current patches and retest everything today (Thurs). I'll try to complete this today so we don't have another migration to do. I'm game for another one.
I opened bug 142500 to track the issue with properties pages. As for the this.applyDialogFont issue, it looks like there's only 2 places that are calling it that way, so I'd prefer if they were cleaned up. Thanks.
I need help. I got all the new stuff out of CVS, applied the latest patch, fixed the things listed below and verified everything else. However, for some reason I can't generate patches anymore. I didn't check everything, but In particular ValidatePreferencePage doesn't generate a patch. I see the ">" icon in the project saying it's changed, I can use the diff too to see the differences, but when I try to generate the patch Eclipse says there aren't any differences. I'm tempted to edit the last patch file, but that probably isn't cool. What should I do? I wonder if this is an eclipse or CVS bug? - removed “this.” references - fixed my comment in all the setSize methods. Sentence needed an “is”. - ValidationPreferencePage had the applyDialogFont on the wrong side of setSize
more info. I can create patches for other files in the Validation component, but not ValidatePreferancePage.java. This is some more info on the error. This seems to be isolated to this one file. Problems reported while synchronizing CVS Workspace. 0 of 1 resources were synchronized. An error occurred synchronizing /org.eclipse.wst.validation.ui/validateui/org/eclipse/wst/validation/internal/ui/ValidationPreferencePage.java: Connection reset by peer: socket write error Connection reset by peer: socket write error
Well, looks like you're not generating a patch because it can't compare the file with what's in HEAD. You might want to try checking out the plug-in and making your change again (assuming it's simple).
(In reply to comment #38) > Well, looks like you're not generating a patch because it can't compare the > file with what's in HEAD. You might want to try checking out the plug-in and > making your change again (assuming it's simple). I already tried that a couple times. I started with a fresh workspace, checked out just the validation project from CVS and inserted my one line change. Same error. I can do the same thing with another file in the same project, and it works. Sounds like a something is wrong with the archive in CVS. I'll try it
In the interest of saving time, how about providing the patch for the rest of the changes and detailing the change for which the patch creation isn't working in a comment. We're respinning RC3 today at 5 and I'd like to have David review this so we have a chance to include it in RC3.
I resorted to editing the patch for ValidatePreferencePage.java. You can try to apply the patch(In reply to comment #40) > In the interest of saving time, how about providing the patch for the rest of > the changes and detailing the change for which the patch creation isn't working > in a comment. > We're respinning RC3 today at 5 and I'd like to have David review this so we > have a chance to include it in RC3. 5:00 in which time zone?
EST - right now.
Created attachment 41942 [details] good to go (almost) ValidatePreferencePage patch won't merge. You'll have to fix it. ApplyDialog font must come before setSize.
Amy - Comments? David - Approval? Are we too late for RC3?
(In reply to comment #44) > Amy - Comments? > David - Approval? Are we too late for RC3? I don't understand what I need to approve? I approve of Amy's changes and the last patch I just supplied. What else do I need to do. Sorry for the delays. Remember this is my first time.
My apologies. There are two David's watching this bug. I've been referring to you as Dave and David Williams (SSE component lead) as David. I'm requesting approval from David Williams.
I've only visually inspected the patch. But it looks good to me.
I'm still having problems generate patches. I opened a bugzilla for the problem 142726
I approve. Amy, please apply, if you approve as the responsible committer. Thanks.
Fix committed and released for WTP 1.5 RC4.
This is part of a mass update to close out all stale WTP resolved bugs from the 1.0.x and 1.5.0 timeframe. If you feel this bug was closed inappropriately, please reopen. Thanks, John Lanuti
