Community
Participate
Working Groups
I20031119 - open any custom drop down menu (a good example is the new editor dropdown that you get when launching Eclipse with "-newDropdown" command line argument) Observe: the parent shell (the Eclipse workbench window) loses focus and deactivates. As a result there is lots of flashing and the dropdown menu appears rather slowly. This makes dropdown menus a pain to use. Dropdown menus should behave similarly to the drop down menus found in tool items. This is a problem at least on Mac and Windows. However, on Mac deactivating is more of a problem because the menubar is cleared too.
The drop down shell should be created with the ON_TOP style the same way tooltips are, but I am not sure this will fix the problem because focus is set to the textfield on the top.
This has a non-trivial impact on the usability of several standard Eclipse features, not just custom dropdown menus. For example, the "ctrl-O outline dialog" takes more than a second longer to open on the Mac than it does on windows. Note: the problem with the menu bar being cleared is covered by https://bugs.eclipse.org/bugs/show_bug.cgi?id=87884
One reason why this is so slow is that the main window underneath the drop down menu is fully redrawn 2-3 times when the menu appears as well when it disappears. This can be seen by using "Quartz Debug" and turning on the "Flash Screen update" option.
Do you suspect that this is an SWT issue, or a UI issue. If the latter, please make sure that someone on the UI team knows how to run in this mode. Kim Horne is a mac user, so she might be a good candidate.
I suspect this to be an SWT or OS problem. It should be fairly easy for the OS provider to tell us how to create a *lighweight* window that can take focus but doesn't invalidate its parent shell.
Any chance we can get some screenshots that demonstrate the problem? Maybe steps to reproduce the problem? What are the SWT controls used to generate the custom dropdown menus? What Carbon APIs are in play?
I am about to attach screen shots that show the active eclipse window, followed by the appearance when the command-O outline is popped up. Notice that in the second shot, the menu bar has been cleared, and all selections in the main window have been grayed.
Created attachment 20069 [details] normal appearance of active eclipse window
Created attachment 20070 [details] appearance after pressing Command-O
See attached screenshot, however, since a screenshot isn't a good way to demonstrate this performance problem, I suggest to try it yourself: start Eclipse, open one or more files in the editor, and press Cmd- E. You get a small dropdown menu, that should give you "fast" access to switching between editors. As this menu-like window appears, the main Eclipse window is deactivated and the menubar is cleared. This makes the menu rather sluggish. Compare this with the dropdown menus in the Eclipse toolbar. They don't have any of these problems.
Created attachment 20075 [details] Switching Editor dropdown
Thanks, guys. We now understand the issue and can recreate it ourselves. To Andre's point in the thread, Apple should be able to recommend how to create a *lighweight* window that can take focus but doesn't invalidate its parent shell. How is it implemented in SWT today? What Carbon APIs are called? If you're doing the right thing, we may have a bug. If not, we can suggest an alternative.
I was able to get rid of the deactivation issue by: - creating a WindowGroup with the kWindowGroupAttrSharedActivation flag set - putting the Combo dropdown into it - assigning the WindowGroup temporarily to the underlying Shell (as long as the dropdown is open). Under this setup the underlying Shell stays active even if the dropdown window has the focus. However, the menu bar is still cleared (but this is under SWT control, so it could be avoided).
Thanks, Andre. If your latest update (5/30) is not enough to answer the outstanding questions from our Carbon graphics team, would you be available for a conference call?
Andre - Our guys understand the use case in question, but are still unclear on how the custom drop down menus are implemented in SWT. Can you elaborate? What Carbon APIs are called?
The widgets in question are top level windows (created with CreateNewWindow()) that don't have trim and should not take focus when opened. This makes them similar to menus in behavior only, not implementation. Their behavior is actually the same as the other platforms in the cases that Andre describes (try it on Windows or GTK). The [performance] part of the problem happens because the Mac redraws the whole window when it becomes inactive. Other platforms redraw only the title bar.
Let me add a bit more. The statement "should not take focus when opened" is true, however, when a control within this kind of shell such as a text widget is given focus, the window manager normally actives the associated top level window. This is what is happening on Windows, GTK and the Mac, causing the main Eclipse window to lose focus and redraw.
These shells should really be "Utility Windows" (without a title bar or border): http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_17_section_5.html#//apple_ref/doc/uid/20000961-TPXREF17 I think they are called "Palette Windows" on Windows. Support for this shell style would also be useful in a number of other places, e.g. CCombo, content assist, custom tooltips, persisted tooltip windows (F2), the Find/Replace dialog, etc.
Does hacking Shell creation to use kUtilityWindowClass fix the performance problem (which is what this bug is about)?
> Does hacking Shell creation to use kUtilityWindowClass fix the performance > problem (which is what this bug is about)? Performance is not that bad anymore (at least on my Intel MacMini), but the flashing of menu bar, title bars, and scrollbars is still a problem. I hacked Shell to create a kUtilityWindowClass. This solved all flashing problems, but had other unwanted consequences: - Popup windows didn't get keyboard focus. When I clicked into the popups, they got keyboard focus, but the caret in the workbench window's text editor was still blinking at the same time (two carets visible). - Popup windows have a title bar. http://lists.apple.com/archives/carbon-dev/2006/Oct/msg00913.html suggests to create a "custom WindowDefSpec"instead. So maybe the approach outlined in comment 13 is more promising in the end.
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.
