Ticket #1188 (closed defect: fixed)
Opened 2012-05-17T14:23:14-05:00
Last modified 2012-07-02T13:46:48-05:00
Menubar sometimes inactive
| Reported by: | bdezonia | Owned by: | bdezonia |
|---|---|---|---|
| Priority: | major | Milestone: |
|
| Component: | UI Framework | Version: | 2.0.0-beta2 |
| Severity: | serious | Keywords: | |
| Cc: | curtis | Blocked By: | |
| Blocking: |
Description
Using the final candidate for beta 2 on Linux and OpenJDK I have a problem where sometimes the menu bar becomes inactive. Open a sample image. Try to select any menu entry (like File) and nothing happens. Select the loaded image. Then select back to the menu bar. Usually it is working again but not always. Eventually it works again.
(Curtis, if you know of recent changes to the menus [the fix-menus branch has not been committed] please comment)
Change History
comment:1 Changed 2012-05-18T15:32:22-05:00 by bdezonia
comment:3 Changed 2012-05-18T15:40:34-05:00 by curtis
It happened on Windows for me with no images loaded, right off the bat.
comment:4 Changed 2012-05-23T12:56:01-05:00 by bdezonia
Note that I can replicate with beta2 on Linux right off the bat. The menubar begins in an unresponsive state. If you move the cursor over a tool the menu becomes responsive afterwards.
comment:5 Changed 2012-05-24T13:11:38-05:00 by bdezonia
Developing on Linux. Apparently it is related to the display of the README file. The first time ever launched the README displays and then menubar is inactive (as long as you avoid tool icons). Exit IJ2 and relaunch and the menubar is active. Run File :: clear preferences, exit, and run again. README displays and then once again the menubar is inactive. README code must be messing up menubar focus initialization.
comment:6 Changed 2012-05-24T16:11:36-05:00 by bdezonia
- Owner changed from bdezonia to curtis
- Status changed from new to assigned
Got it. The running of displayReadme() launches a plugin. This plugin shows the readme text in a DefaultTextDisplay. That generates a DisplayActivatedEvent. The SplitChannelsContextMonitor class captures that event and sets it context accordingly. This updates info in the setContextAppropriate() call. The updating of info generates a MenusUpdatedEvent. Eventually the UI responds by creating another menu and this is what causes one of them to have focus but not be active.
The update info call in setContextApproriate() is already tagged with a TODO as to whether we need it or not. Removing it fixes the bug. There is more surrounding documentation of problems. It looks like Curtis knows this code intimately and thus I'm passing it to him from here.
comment:7 Changed 2012-05-24T16:16:28-05:00 by bdezonia
Note that updating the code to surgically alter menus rather than wholesale replacement would address this also.
But the current situation may point out issues with SplitChannelsContextMonitor.
comment:9 Changed 2012-07-02T13:00:21-05:00 by curtis
- Owner changed from curtis to bdezonia
Can you please test whether this bug still occurs after our menu refactoring? If so, please assign back to me; otherwise, please close.
comment:10 Changed 2012-07-02T13:46:48-05:00 by bdezonia
- Status changed from assigned to closed
- Resolution set to fixed
Tested on Ubuntu Linux 12.04 with a version some time after we made changes to menu code to accomodate a single menu bar on Mac. Bug is no longer apparent.
Apparently this is happening on Windows too. Also I've had it happen on Linux when no images had ever been loaded.