Ticket #1188 (closed defect: fixed)

Opened 7 years ago

Last modified 7 years ago

Menubar sometimes inactive

Reported by: bdezonia Owned by: bdezonia
Priority: major Milestone: imagej2-b3-headless
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 7 years ago by bdezonia

Apparently this is happening on Windows too. Also I've had it happen on Linux when no images had ever been loaded.

comment:2 Changed 7 years ago by curtis

  • Version set to 2.0.0-beta2

comment:3 Changed 7 years ago by curtis

It happened on Windows for me with no images loaded, right off the bat.

comment:4 Changed 7 years ago 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 7 years ago 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 7 years ago 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 7 years ago 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:8 Changed 7 years ago by curtis

  • Component changed from other to ij-ui

comment:9 Changed 7 years ago 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 7 years ago 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.

Note: See TracTickets for help on using tickets.