Class MenuSelectionManager

java.lang.Object
vaadinx.swing.MenuSelectionManager
public class MenuSelectionManager extends Object
Emulator for MenuSelectionManager — present so migrated code that names the type still compiles after the import swap, WARN-stubbed throughout because SB-Emulators models no menu-selection machinery to manage.

Why a stub rather than JDK reuse. Its whole API traffics in MenuElement, which SB-Emulators ports, so the JDK class could not accept a ported element as an argument. Same forcing as MenuElement's own port. The behaviour it would manage — a selected menu path driven by mouse and key traversal — is Vaadin's own: SJMenuBar plus MenuTreeBuilder rebuild the whole Vaadin menu tree from the emulator hierarchy and the browser owns highlight and traversal from there (D_menu_tree).

What that leaves is more than a stub. The selected path itself is pure bookkeeping, so setSelectedPath(MenuElement[]) really keeps it, really calls each element's menuSelectionChanged, and really fires — the declined effect is the *highlight*, one layer down in each element (R_decline_effect_only). Nothing inside SB-Emulators ever calls it, so a migrator driving menus by hand is the only writer; the mouse and key processing that would drive it on the desktop stays WARN-stubbed, since those events never reach the server.

  • Field Details

  • Constructor Details

    • MenuSelectionManager

      public MenuSelectionManager()

  • Method Details

    • defaultManager

      public static MenuSelectionManager defaultManager()
      Mirrors MenuSelectionManager.defaultManager() — one shared instance.

    • setSelectedPath

      public void setSelectedPath(MenuElement[] path)
      Replaces the selected path, walking the JDK's body: keep the shared prefix, tell each dropped element it left the selection, tell each added one it joined, then fire.

      Pure bookkeeping and notification, so both land (R_decline_effect_only) even though nothing in SB-Emulators ever calls this: the browser owns menu highlight and traversal (SJMenuBar + MenuTreeBuilder rebuild the Vaadin tree, D_menu_tree). What is declined is the *rendering* of a selection — which is each element's own menuSelectionChanged, called here and WARNing there.

      Parameters:
      path - null is treated as an empty path, as in the JDK

    • getSelectedPath

      public MenuElement[] getSelectedPath()

    • clearSelectedPath

      public void clearSelectedPath()

    • addChangeListener

      public void addChangeListener(ChangeListener l)

    • removeChangeListener

      public void removeChangeListener(ChangeListener l)

    • getChangeListeners

      public ChangeListener[] getChangeListeners()

    • isComponentPartOfCurrentMenu

      public boolean isComponentPartOfCurrentMenu(Component c)
      The JDK's own walk, and it reaches less far here than there: a JMenu owns no JPopupMenu (D_menu_tree rebuilds the Vaadin tree instead), so getSubElements() is empty and the walk stops at the root. It widens on its own if that structural gap ever closes.
      Returns:
      true if c is the component of any element under the selected path's root

    • processMouseEvent

      public void processMouseEvent(MouseEvent event)

    • processKeyEvent

      public void processKeyEvent(KeyEvent e)

    • componentForPoint

      public Component componentForPoint(Component source, Point sourcePoint)
      Returns:
      null — no component-to-path mapping exists without a selected path.

    • fireStateChanged

      protected void fireStateChanged()
      JDK-faithful fan-out over listenerList. Nothing in SB-Emulators calls it (the selection never changes server-side), but a subclass that does gets the JDK's delivery.