Community
Participate
Working Groups
Should the shorten text; method in OperationHistoryActionHandler be more GC.textExtent() based instead of using a hard coded max? See other implementors of shortenText() /* * Shorten the specified command label if it is too long */ private String shortenText(String message) { int length = message.length(); if (length > MAX_LABEL_LENGTH) { StringBuffer result = new StringBuffer(); int mid = MAX_LABEL_LENGTH / 2; result.append(message.substring(0, mid)); result.append("..."); //$NON-NLS-1$ result.append(message.substring(length - mid)); return result.toString(); } return message; }
The original intent was performance-oriented (avoiding repeated text extents on the substring), but I see that this is not a consideration in other implementations. I think the best course of action would be to move one of the JFace implementations (Dialog?) to a utility class, along with the char width->pixel conversions, etc. that are currently in Dialog. This way we aren't copying different implementations around. Perhaps these should be made static methods in JFaceResources or Util and uses converted to using the common implementation. Opinions??
The usual way we do it is to create a static method and have the old method call the static one. See the convert* methods in Dialog.
I'm sorry for beating this to death, but there are separate issues at play. I was looking for suggestions as to what JFace class to define these new static methods in. Dialog is too specific, Util seems a bit general, creating a new class is a bit heavy-handed. The methods would be public static String shortenText(String text, int pixelWidth, GC gc) public static String shortenText(String text, int charWidth) Why two flavors? (1) - shorten text to a pixel width - used for precisely fitting some text into a control or other fixed-width UI element. (2) - shorten text to a character width - the intention is to shorten the text to something "reasonable" as defined by some number of char widths. The intention is not to fit into an exact pixel width. Used in menus and places where the size will be adjusted to fit the longest item. The performance issue I mentioned is that when you aren't trying for an exact pixel-width fit, it is overkill to convert char widths to pixels, then measure all substrings in order to split the string at the pixel-halfway point vs. doing simple char width calculations. That's why I suggest two flavors, leaving us the option to implement the second one in terms of the first one. I was also suggesting we provide implementations for these methods: public static int convertWidthInCharsToPixels(FontMetrics fontMetrics, int chars) public static int convertHeightInCharsToPixels(FontMetrics fontMetrics, int chars) These are used outside of Dialog and belong in a more general location. Note that somewhere we still need to define the "hard coded" preferred max char width of a menu item, analgous to IDialogConstants.ENTRYFIELDWIDTH, but again, IDialogConstants is too specific.
Sounds like a new Graphics Utility class to me.
Changing name of bug to reflect the real issue and removing milestone, as this is not necessarily important for 3.3. I still believe there should be two flavors of text-shortening. Using approximated char widths is the right thing to do in menu text when you aren't trying to fit an exact width.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
*** Bug 172295 has been marked as a duplicate of this bug. ***
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.
