Community
Participate
Working Groups
OS: Windows Build date: 05112007 Component Name: CDT Blocking: No Tester Name: Noha Steps to recreate the problem: Create a new workspace. Switch to the C/C++ Perspective: from the main menu go to Window -> Open Perspective -> Other and select C/C++ Problem description: The tool tips text such as 'New C/C++ Project' does not have RTL reading order, however when I click anywhere else such as clicking on any of the main menus and then go back to the tool tips they become RTL enabled. As discussed, this is probably a Platform/Base problem. Thanks! Vivian Hi, Updating with screen shots. This is a general problem for all tooltips (including workbench toolbar buttons and view's local toolbar buttons). The switching reading order behavior happens to all strings with Engish mixed in Bidi words. Platform UI please take a look. This article was reassigned from Category:''TVT Testcases''.
Created attachment 67263 [details] 13.001120-Wrong_Hover_order.jpg
Created attachment 67264 [details] 13.001120-Correct_Hover_order.jpg
<cde:tctdetail> Testcase: Project: WSW33 Component: CDE - Platform/UI Priority: 2 Subject: ar: 13.001120 Tool tips text does not have RTL reading order Article ID: 159 Originator: husseinn@eg.ibm.com </cde:tctdetail>
Not sure where to dump this one Tod...
CDT needs to TextProcess thier Tooltips
Vivian, according to Platform, it's a CDT bug.
Created attachment 67314 [details] CDT icons Ravi, can you please take a look? The problematic tooltips are found on these C/C++ icons in the C/C++ Perspective. Please see the attached screenshot.
Warning: Unable to attach CDT_icons due to lack of extension on the filename.
The tooltips are loaded from the plugin.properties file and that's not handled by CDT. We're seeing similar problems with the tooltips for plain Eclipse as well. I'm not sure which component this belongs to so I'm going to assign it to Platform for now. Please feel free to change it.
Is this also an issue on Windows?
Yes, the problem was reported on Windows.
Warning: Unable to attach CDT_icons due to lack of extension on the filename. Warning: Unable to attach CDT_icons due to lack of extension on the filename.
This problem was found again in TPTP component, testcase 09.001440. But in this case, the tooltip text permanently had incorrect reading order. Clicking anywhere else and returning back to this tooltip still displays incorrect reading order.
Created attachment 70018 [details] 09.001440.jpg
This is a high priority must-fix problem for Arabic. I need screen shots to be sent to verify this problem.
We have set the orientation on the parent of the ToolBar (the Composite) as you can see in the screenshot. This is a general SWT issue in the processing of Tooltips. Having said that this was this tested on a machine with an Arabic install? If not then you will get OS behaviour I would expect.
Why is this problem assigned against Linux-GTK ? According to comments #0 and #14 and all screenshots this is a Windows problem.
Tod: 1) Can you confirm that the ToolBar is RTL (or by inherence or directly set) 2) Can you give the string that is being set in the tooltip (so I can make sure it doesn't have bidi control characters). Reporder, please reply Tod last question: "Having said that this was this tested on a machine with an Arabic install?" Note: if the machine doesn't have Arabic installed you can't expect RTL reading order to work on it. This works for me in a simple snippet. public class PR196791 { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display, SWT.SHELL_TRIM | SWT.RIGHT_TO_LEFT); ToolBar bar = new ToolBar(shell, SWT.NONE); ToolItem item = new ToolItem(bar, SWT.NONE); item.setText("ToolItem."); item.setToolTipText("ToolItem tip."); bar.setBounds(10, 10, 100, 26); shell.setSize(300, 300); shell.open (); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Tod, please modify the snippet to show the problem. Send it back to SWT when you are done. Thanks
This one fell through the cracks. I will remove the 3.3.1 target and we will talk about putting a fix in before the build next week.
Embed an Arabic character to give mixed text in each to see the difference package org.eclipse.jface.snippets.dialogs; import org.eclipse.swt.SWT; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell; import org.eclipse.swt.widgets.ToolBar; import org.eclipse.swt.widgets.ToolItem; public class PR196791 { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display, SWT.SHELL_TRIM | SWT.RIGHT_TO_LEFT); ToolBar bar = new ToolBar(shell, SWT.NONE); ToolItem item = new ToolItem(bar, SWT.NONE); item.setText("Tool\u0751Item."); item.setToolTipText("Tool\u0751Item tip."); bar.setBounds(10, 10, 100, 26); shell.setSize(300, 300); shell.open (); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Interesting test case Tod. In my machine I don't need the arabic char to reproduce the problem. The reading order in the tooltip changes every time the mouse enters the toolbar from the top edge. Go figure. Fixed in HEAD > 20080410
