Bugzilla – Full Text Bug Listing
| Summary: | [Bidi] when mirroring the popup menu item, the icon should be to the right of the text | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | yuling chen <yulingc> | ||||||
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Felipe Heidrich <eclipse.felipe> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | landau, semion, snorthov | ||||||
| Version: | 2.1.2 | Keywords: | triaged | ||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 2000 | ||||||||
| Whiteboard: | stalebug | ||||||||
| Attachments: |
|
||||||||
|
Description
yuling chen
According with bug#42892 the images are in the correct place. Semion, please advice. It is not understood from description, what is the menu's orientation and what is the orientation of its parent shell. If this bug is about the case, when orientation of menu is differ from orientation of shell, it is known problem, which was defined in the bug #42892 as Windows limitation. But, Felipe, what about creating the popup menu as child of another, temporary shell? For example, let us change ToolBarTab.java from ControlExample demo application as following: ..... Shell shell = tabFolderPage.getShell(); int menuOrient = (shell.getStyle() & SWT.RIGHT_TO_LEFT)!= 0? SWT.LEFT_TO_RIGHT : SWT.RIGHT_TO_LEFT; Shell shell1 = new Shell(shell,menuOrient); shell1.setBounds(0,0,0,0); menu = new Menu(shell1,menuOrient); ..... menuItem.setText(text); menuItem.setImage(instance.images[ControlExample.ciOpenFolder]); ..... We will receive rtl popup menu with correct placement of its items' icons. What do you think about this? Can this logic be placed inside of Menu? Yuling, I also don't quite understand the problem. You mean the image itself should not be mirrored or the Item (alignment between image and text should not be reversed) ? In LTR, a menuItem has the image alignment in the LEFT and the text right next to it (on the RIGHT portion of the item). In RTL, it is reversed, the image on the RIGHT and the text on the LEFT. Maybe a screen snapshot would help. Semion, you are suggesting a fix for bug#42892 ? If so you should put the code in the right bug. I didn't test the code and, even if it works, is very unlike we would release it. Usually faking the parent of a widget causes much more problems than it helps. We would just agree to release this kind of workaround in order to fix a critical problem. Bug42892 is a pretty particular case where mirroring fails due a limitations on Windows - not consider critical. Felipe, as far as I understand, this bug is about only one of the 5 problems, which were described in the bug #42892. Bug #42892 is already closed, and current bug isn't defined as duplicated - that is why I wrote my comments here. Problem, which is written about in this bug, probably, isn't critical, but very unpleasant. Example, where it can appear, is using popup menus with ToolBar or CoolBar, which can have orientation, differ from orientation of their top shell. Please, explain, what the problem we can receive with this solution? Do you mean, that popup menu should be always created as child of top shell only? Note, that all what I suggest is to create popup menu as child of its own zero- sized shell with the same orientation, and this shell, in it's turn, should be the child of the original parent. Semion: "Do you mean, that popup menu should be always created as child of top shell only" Look the code, the parent of a menu is always a Decoration (top level shell), the contructors Menu(Menu), Menu(MenuItem), Menu(Control) were a bad design API. They actually are helpers and make people think their argument (Menu|MenuItem|Control) are the actuall parent of the new istance of Menu. Look the code, these helpers reach inside the argument and use their parent Shell. Yuling: please, explain the problem better for us. Thanks. Created attachment 11009 [details]
Test application for popup menus
I don't write about Control, Menu or MenuItem. "Top shell" means top level
container for application's GUI. If you use shell to create some custom
component, like CCombo, it isn't top shell.
Behavior of popup menu (in the framework of our case) depends on
TrackPopupMenu(). Real parent of popup menu is the shell, handle of which is
send as parameter of this call (and here isn't important, who is the menu's
parent from SWT point of view). Please, look the code from attachment. In this
example popup menus are created with orintations, which are opposite to
orientation of corresponding buttons. With first two buttons menus are created
as children of "secondary" shell, with other buttons - as children of top
shell.
There is a bug: If the menu orientation differs from the shell orientation and the menu has images the images are shown in the wrong place. We have talked about this in bug#42892 and we decided not to fix it. I ran your example and it proves that using and hidden shell the application can workaround this problem, Is that what you were trying to prove ? Anyhow, I don't think the problem Yuling Chen reported involve mixing orientation of widgets. As far as I understand, "mixing orientation of widgets" - this is exactly what
Yuling wrote. Anyway, we both see, that some problem exists. Once we decided
not to fix it, because suitable solution was not found. Why we can't try to
solve it once more - by another way?
My suggestion is to create popup menu as a child of its own "hidden" shell:
Menu (Decorations parent, int style, int handle) {
super (parent, checkStyle (style));
if ((style & (SWT.BAR | SWT.DROP_DOWN)) == 0)
this.parent = new Shell(parent.getShell(), (style &
(SWT.LEFT_TO_RIGHT | SWT.RIGHT_TO_LEFT)));
else
this.parent = parent;
this.handle = handle;
.......
I don't try to prove something, I only try to ask you: is this solution safe
from your point of view? Do you see real problems, which can appear after these
changes?
Yuling, please help us to understand your problem here. Semion, I don't think it is safe. Menu.getParent() is going the return some invalid internal widget. MenuItem.setMenu(Menu) will throw ERROR_INVALID_PARENT when it should not, etc. We would need to add hacks all over places to make it work and it is very likely we'll missed a couple places, therefore adding bugs to the code. Created attachment 11330 [details]
Problem description
From YuLing:
"The problem only happens when the workbench orientation is different from that
of the menu. The menu looks like follows:"
[image]
"The icons should be at the position where the arrow points to.
As you can see, the popup menu problem disappears in global mirroring(by
flipping the workbench itself), we're more concerned about the bugs regarding
the DirectoryDialog and ColorEditors. These are not flipped in global
mirroring.
Since I'm not working on the mirroring issues anymore right now, please contact
Jerrold Landau for following ups of these bugs."
At this any code needs to be approved by Steve prior release into RC2. Steve: Old problem (duplicate of bug#42892): MenuItem when its parent doesn't have the same orientation of the Shell draws its image in the wrong place. The fix is dangerous, the idea is to create a hidden parent shell for Menu with the same orientation. This problem is not a regression. Not for 3.0. Too dangerous at this time. Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info. This is a one-off bulk update. (The last one in the triage migration). Moving bugs from swt-triaged@eclipse to platform-swt-inbox@eclipse.org and adding "triaged" keyword as per new triage process: https://wiki.eclipse.org/SWT/Devel/Triage See Bug 518478 for details. Tag for notification/mail filters: @TriageBulkUpdate 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. -- The automated Eclipse Genie. |