Community
Participate
Working Groups
When you have many files open in the main pab, some tabs are hidden and accessible by clicking Chevron shaped thing (on mouseover, you'll see it as 'show list'). If you have a file in the list with very long name (usually the file is in deep directory), then the file name cannot be displaid properly. Right hand side is visible but left hand side of the 'show list' window is out of screen.
possibly a Java editor issue.
>possibly a Java editor issue Mazen, I wonder what made you think so? ;-)
Daniel... work with me here ! I just got to the office and Im having a coffee.... JDT bugs just sounded better :-) sorry for confusion...
*pats Mazen on the head* It's OK... everything is fine.
Thank you for your comments, everyone. So, is this a Java editor issue? Any plan to fix?
>So, is this a Java editor issue? No.
There are no plans to fix at the moment.
Moving Dougs bugs
what is the status of this?
Does anybody have a screenshot of this for me? Is this maybe due to non-standard fonts?
0. switch to high contrast mode 1. start Eclipse 2. create a file with a long name 3. open that file 4. open so many editors that the chevron appears 5. click the chevron ==> once the hover has the size of the screen your doomed
I think I was able to recreate this on the 3.2 GM without going into high contrast mode. I will attach a screen shot. Note that the user, at least in my case, completely doomed. The Ctrl+Shift+F6 key combination still works to get to the previous editor (it shows the same cut off list while you hold the combination but when you release, you are on the previous editor). Note that the Ctrl+F6 key combination to get to the next editor was broken for me. Could someone else check this. Maybe I messed up some key preferences.
Created attachment 55905 [details] The promised screen shot.
I can think of two ways to fix this. 1) Wrap the really long file names to multiple lines. I am not sure how easy, safe or portable this would be. 2) After some number of characters (would need to depend on the x dimension of the display and the font size), truncate the very long file names. "Averylongfilenamewouldlooklikethisinthelistinsteadofall...". Or perhaps you always show the extension, so it would be this, "Averylongfilenamewouldlooklikethisinthelistinsteadof....txt". I think this fix is likely to be easier, safer and more portable but I don't own the code. Is this critical enough for inclusion in 3.2.2? I am not sure. I would think this would be more common in high contrast mode so if the fix is easy and safe, it would probably be worth doing. Note that if someone confirms the Ctrl+F6 problem, I think that would be important to fix. I can open a separate bug if someone else sees it.
Under normal conditions I see this being a minor but for disabled people using high contrast mode this might be important to get fixed at least for 3.3 and in case the fix is trivial it could be backported to R3_2_maintenance. >Note that >the Ctrl+F6 key combination to get to the next editor was broken for me. Could >someone else check this. The key binding works for me using 3.3 M4 and M20061214-1600 but to be honest I never use that because I always have a different understanding of 'next' and 'previous' (see bug 43625).
We need to intelligently truncate the filename to something reasonable so that the overall width of the popup never gets bigger than, say, 1/3 of the screen in size. Note: the original reporter describes the problem in terms of files in deep directories, but when I click on the chevron I only see the "short names" for the files for both Java and text files (i.e. no directory info.
Boris this is marked 3.2.2 - has it been fixed yet?
Created attachment 56682 [details] possible patch (In reply to comment #17) > Boris this is marked 3.2.2 - has it been fixed yet? Sorry, no, this is not fixed. The proper fix would be to constrain the size of the pop-up shell to be smaller than its parent shell, and adding scroll bars to the table if it contains entries that don't fit into that size. Doing this looks too risky to me though, we would need to change DefaultPartList (knows about the parent shell and its size) and AbstractTableInformationControl (controls the layout) in a non-trivial way. The only localized fix I can think of is attached, it just truncates editor names if they exceed a certain length by cutting out characters in the middle. In the middle because I am not sure if the start or the end of the string is more important, this may be one or the other depending on the editor. It seems strange to me though that there are editor names of that length, is someone working on files with names that are very long, or could it be that some editors set their part name to a really long string, maybe the full path? Tod, what do you think about the patch? Would you give it a +1 for 3.2.2?
>It seems strange to me though that there are editor names of that length, is >someone working on files with names that are very long, I think the very long names are less frequent than people using High Contrast (or just large fonts) and hence making the problem appear with shorter names as well.
Boris this patch doesn't apply to 3.2.2 - is it a 3.3 patch? P.S. Dani has hit the nail on the head - people using lower resolutions hit this sort of thing constantly.
While I like the idea of the patch I would feel better if the nubmer we chose was based on the display size and some font metrics. I would take the Dialog.shortenText method and modify it to do something similar for this control. I'll attach my suggestion.
Created attachment 56695 [details] Showing a possible 3.3 solution Here is a patch that uses the shortenText implementation from Dialog. The use of it in this patch would create too many GCs - we will have to cache much better or make some better guesses. Either way I am +1 for fixing this - I think Boris's suggestion is safer but not the stratagy we should use going forward.
Created attachment 56784 [details] Patch for 3.2.2 Boris's solution can fail for High Contrast with certain large characters. The two of us have an alternate solution using Display size and FontMetrics here.
Patch released to HEAD for maintenance build 20070112.
I am guessing that in comment 24 that "HEAD for" should be "HEAD and for". HEAD isn't the maintenance stream. Just wanted to clarify.
Correct - the maintenance stream. We have not currently committed this to HEAD as we are investigating a better general solution.
Reopening. This is embarrassing - two senior software developers, while pair programming, add some code for safety (after testing, I guess) and confuse Math.min and Math.max. Tod, you seem to have auto-format on save enabled - the patch has all sorts of formatting changes in it.
Created attachment 56938 [details] patch (to be applied after rolling back "Patch for 3.2.2") (In reply to comment #27) > Reopening. This is embarrassing - two senior software developers, while pair > programming, add some code for safety (after testing, I guess) and confuse > Math.min and Math.max. I believe it was me who made that suggestion :-/ We should roll back "Patch for 3.2.2" and then apply this one. Tod, McQ, could you please double-check the patch and then approve it for 3.2.2?
+1 for me. Verified in regular and high contrast modes.
*sigh*. +1.
I rolled back the previous patch (id=56784) and applied the updated one (id=56938). Released to R3_2_maintenance >20070116.
