Community
Participate
Working Groups
The Update dialog message is too long on Linux. The TitleAreaDialog is designed to have 2 lines of text and this dialog has 3 so the top and bottom get cut off. There is also a missing period and the end of the last sentence. STEPS 1) Install the examples to your eclipse install 2) Restart Eclipse - look at the message in the dialog.
Same issue with the Pending Changes dialog
Also need a mnemonic for Software Updates in the Help menu
It is a metter of the point of view :-) - the message is not too long, the dialog is too short :-). Seriously though, JFace wizards should be able to accomodate any length of the description text. At the moment, they are randomly restricting the area to two lines of text. Even if we (the users) would manage to keep the description down to two lines, that would only work on Win32 using the default font. Changes in font sizes, OS/WS combinations and locales will expose this as a shoddy workaround. JFace wizards should simply compute the height of the description text in such a way as to accomodate the entire description text. There are APIs to compute the text height given the width. Moving to Platform UI - mark this as a duplicate.
Should investigate if the new layout can size for this. Could also try and decide on default number of lines based on sample text.
*** Bug 16695 has been marked as a duplicate of this bug. ***
changing name to better reflect the issue
*** Bug 91004 has been marked as a duplicate of this bug. ***
*** Bug 217341 has been marked as a duplicate of this bug. ***
From the most recent duplicate bug: >It would be much better if a nice looking scroll bar (maybe >even just two floating arrows to the right) would appear, giving the user a >visual indication that more test is available and giving an obvious mechanism >to access that text.
*** Bug 232497 has been marked as a duplicate of this bug. ***
Could this not be solved relatively simply using a CLabel? This would at least make the user aware that some text is missing. The tooltip text for the label could then be set to the full string so when the user hovers over it they can see the full message.
(In reply to comment #11) > Could this not be solved relatively simply using a CLabel? This would at least > make the user aware that some text is missing. > > The tooltip text for the label could then be set to the full string so when the > user hovers over it they can see the full message. > I'd be willing to examine a patch for consideration in 3.5.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
*** Bug 290988 has been marked as a duplicate of this bug. ***
Picking up the bug
Created attachment 164664 [details] Patch v01 Patch v01 Just an idea of how it would look like when its done.
Created attachment 164665 [details] Dialog to test
Created attachment 165695 [details] Patch v02 Patch v02. Adds the "scroll bars" in the title area. They will be visible only when required. Scrolling can be done via mouse/keyboard (when focus is on the message)
Created attachment 165979 [details] Patch v02b The up arrow is kind of weird in patch v02 (or maybe it looks fine on a Mac?). The down arrow is very good though. This v02b takes Prakash's arrow drawing code and inverts the down arrow instead of trying to draw both arrows "separately" to give it a better mirroring effect.
Created attachment 165980 [details] Screenshot depicting the problem in question. Here's what they look like on my Windows 7 system.
Comment on attachment 164665 [details] Dialog to test Forgot to mention that I haven't really looked over the rest of the patch otherwise.
Created attachment 166041 [details] Patch v02 & Patch v02b in Mac (In reply to comment #19) > Created an attachment (id=165979) [details] > Patch v02b > > The up arrow is kind of weird in patch v02 (or maybe it looks fine on a Mac?). Yes. In Mac my version looks OK. The screenshot has both my version and your version and no much differences.
Created attachment 167724 [details] patch for growing the title area I've experimented with adding a scrollbar when the text doesn't fit, but that did not work on the Mac where Text widgets with just two lines of text don't have enough vertical space to even render the scrollbar controls. This patch is another attempt, it grows the title area dynamically so that the text fits even if it has more than two lines. The remaining issue with this is that (for example) in the Import wizard, as you select different wizards on the first page, the tree jumps vertically if the new description takes up more than two lines. Not sure if we can live with this or if someone has an idea how we can avoid this problem. Susan, can you take a look?
(In reply to comment #23) > This patch is another attempt, it grows the title area dynamically so that the > text fits even if it has more than two lines. The remaining issue with this is > that (for example) in the Import wizard, as you select different wizards on the > first page, the tree jumps vertically if the new description takes up more than > two lines. Not sure if we can live with this or if someone has an idea how we > can avoid this problem. Susan, can you take a look? Another issue I'm seeing is, that when the message is large enough, there will be no space for the other controls. Run the dialog from Comment# 17 to see the effect.
(In reply to comment #23) > Created an attachment (id=167724) [details] > patch for growing the title area > > I've experimented with adding a scrollbar when the text doesn't fit, but that > did not work on the Mac where Text widgets with just two lines of text don't > have enough vertical space to even render the scrollbar controls. > > This patch is another attempt, it grows the title area dynamically so that the > text fits even if it has more than two lines. The remaining issue with this is > that (for example) in the Import wizard, as you select different wizards on the > first page, the tree jumps vertically if the new description takes up more than > two lines. Not sure if we can live with this or if someone has an idea how we > can avoid this problem. Susan, can you take a look? I don't find this looks that bad. But in the import wizard case, the tree has some "give" so we don't lose any content. The risk is that for a dialog area with no "give" in a control (for example, just a form-style UI with labels and texts, or buttons and radios), the button bar will start to clip as the message grows. The only way I could see to avoid this would be to resize the shell to accomodate the larger message. I experimented with this, but I found it more disconcerting than helpful, because the contents would appear to shift twice. In the end I think that as long as the shift is predictable (everything is moving down), the user can deal with resizing the dialog if needed. I would imagine that in many cases, the user will correct whatever the problem is that is causing the long message, and then everything would shift back up anyway. (In reply to comment #24) > Another issue I'm seeing is, that when the message is large enough, there > will be no space for the other controls. Run the dialog from Comment# 17 to see > the effect. What really looks disconcerting in Prakash's example is that the separator disappears until you resize the shell. That does look quite poor. The separator is needed to help the user keep the context when things start shifting downward. I couldn't figure out how to mess with the attachments to make this work, and I think it's bogus anyway that the dialog area is creating the separator vs. the title area. So I changed the code to create the separator in the title area and attach it to the rest. This solves the problem (at least on windows). I'll attach an updated patch. Incidentally, I think FormAttachments are so outdated (and I have such a mental block against them) that I wasted way too much time in the last hour or so rewriting the layout with a GridLayout. I was pretty close to the right behavior, but I couldn't get the message image to top-align against the wrapped text cell, and after fighting with it for too long, I realized this is too much change for an RC1 anyway. So I recommend the patch I'm attaching here, with the caveat that we need to test on all platforms.
Created attachment 168074 [details] patch that grows the title area but ensures separator never disappears
Created attachment 168154 [details] experiment with tooltip This is to experiment with a roll-over tooltip that displays the message.
Tried this on win7. - the hover is well placed - even with a message icon, the hover is well placed so that you can see the icon adjacent to the message Things to think about: - should there be some kind of ellipsis/indicator that there is more to be seen in the hover? We don't do this in other places where we show a hover (table and tree column hovers, editor tab hovers, etc.) so I don't see a reason to do it here - the hover can't take focus, does that impact any accessibility issues? No, because the message takes focus already so screen-readers can read the entire message. The problem is really addressing the sighted user The approach where we grow the message area is more appealing in some respects, but I think it's much riskier. It introduces the risk of clipping, and fixing that problem requires an additional resize/layout. I don't like the idea of introducing new layout flows for all title area dialogs (and wizards) in eclipse. We would want to have more time to flesh out unintended side effects (for example, clients that have custom resize hooking or odd layout behavior.) I seem to recall some tooltip/focus differences on Linux, but I can't see how an unintentional loss of focus (if one exists) could hurt a wizard. All in all, I think this is the most reasonable UI given the timeframe and may well prove to be good enough in the long term.
A standard question from yours truly, should the tooltip be using the JFace dialog font?
If I shrink JDT's 'New Class' wizard to the extreme, horizontally speaking, and hover over the label, it does not work (I am using default dialog font on XP).
Created attachment 168272 [details] Tooltip patch v2 This new patch includes changes to honour the dialog font and to get the tooltip to appear in "pixel perfect" conditions where the label just barely misses the mark.
(In reply to comment #30) > If I shrink JDT's 'New Class' wizard to the extreme, horizontally speaking, and > hover over the label, it does not work (I am using default dialog font on XP). I haven't been able to reproduce this. I think I might've even actually be launching the wizard from my outer Eclipse instead of my inner. :o (In reply to comment #31) > Created an attachment (id=168272) [details] > Tooltip patch v2 I've looked at this patch together with Boris and have released this to HEAD.
*** Bug 72191 has been marked as a duplicate of this bug. ***
*** Bug 328088 has been marked as a duplicate of this bug. ***
