This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The IDE have to generate menus by compositing several piecesof functionality. The current implementation is somehow problematic because of its asynchronity. The menu generation should be more streamlined with help of the new Actions API
Reassigned to Dafe group
Huh, wait Petr, please be more specific. Assume we know nothing about menu creation and actions (that's nearly true, you know). Please write specific ideas what should be done, this will help us. Also, UI team we need some tests and techniques how to measure that popup menu is fast enough. Please provide something.
Af first, I've originally assigned this to myself, willing to take care of the research and proper implementation. At second, new Actions APIs does solve the complexity part. This was intended as a tracking task to not forget to exploit the "Context" (see actions APIs) when it will be available. See the dependency tree.
Dafe told me to assign it to Petr.
It seems it would be possible to significantly reduce flickering of the menu by using some nice package private communication inside org.openide.awt even without new Actions API. It would involve two-phase menu posting because of inline menus waiting to addNotify and then updating themselves *later* (can't modify parent during addNotify). I'll try to investigate it more.
*** Issue 21256 has been marked as a duplicate of this issue. ***
*** Issue 21006 has been marked as a duplicate of this issue. ***
I think the hard requirement for this issue is: no flickering. Under no condition should the menu rebuild itself while already being displayed. Besides the fact that this is annoying, AWT implementations do not deal well with this situation (gray rectangle left behind on the screen for example)
I've just realized that the keyboard initialized popup in explorer is way faster than when initiated by right click (more work done even when clicking on the same node).
*** Issue 21813 has been marked as a duplicate of this issue. ***
The popup menus based on JMenuPlus/JPopupMenuPlus should not flicker any more. I've added private communication channel between them and JInlineMenu, which was the major source of flickering. Also subclasses of JInlineMenu have their chance to behave better, and I've also fixed ToolsAction to exploit it and to cause flickering neither from popup nor from top level menu. I've also changed the MenuView to wait for the most up-to-date content of the underlaying Node, so it will display OK directly, not refreshing itself later. The explorer menu is mostly below 100ms on my machine (after first-time initialization), the editor menu is a bit slower (depending on actual completion resolution time), but we can tune them both more now, when we have everything one-shoot and in one thread.
Verifying this wanted task, will commit some tests soon.