Menu Bar for Partitioner

[shundhammer]

Trello

https://trello.com/c/cx6LEKsA/1914-5-partitioner-menu-bar

Bugzilla

https://bugzilla.suse.com/show_bug.cgi?id=1175489

Problems

• We have too many buttons in the partitioner; they clutter the dialogs. Some of the actions on those buttons are really exotic and rarely needed.

• Some of the pages in the partitioner are really out of place; they should not be mixed among all the others that are all related to devices like Hard Disks, Volume Management, Bcache:

  • Settings
  • Installation summary
  • Device graphs

Solutions

• Add a menu bar and move at least the exotic actions out of the main dialog; remove those buttons from there.

• Convert the pages that are out of place into pop-up dialogs and move them out of the tree on the left side. They should be initiated by a menu entry.

Screenshots

Partitioner with menu bar.

Notice that some of the views are now gone from the tree on the left:

• Installation summary
• Device graphs
• Settings

They are now accessible from the menus.

NCurses 80x24

Pop-up Dialogs that were Main Dialog Views

Installation summary invoked from the "View" menu

If there was any change, the user will still get a full-screen version of this as a final wizard step to confirm the actions that will be performed:

Menus

The "System" Menu

All items here are fully functional.

"Settings" opens the "Settings" dialog which is now no longer a page of the main view, but a separate pop-up dialog.

"Abort" and "Finish" are alternatives to the wizard buttons with the same name.

The "Edit" Menu

Not supported yet, thus all disabled:

The general idea is that these menu items should perform the same action as the buttons with the same name on the currently selected page: If a partition is selected, the menu will add or edit or delete etc. a partition. If a disk is selected, only "Edit" will be enabled, and the user can modify the disk, e.g. create a filesystem directly on disk. If an NFS is selected, the menu will add or edit or delete an NFS mount etc.

We will have to decide if that still works well with volume management where a user can add or edit or delete a volume group or a logical volume.

But wherever possible, this menu should provide a uniform user interface for common operations.

We decided against adding a separate menu for each of the different kinds of objects (disk, partition, RAID, LVM volume group, LVM logical volume, bcache, NFS mount, Btrfs); not only would we run out of screen space (especially in NCurses), the sheer number of entries would also defeat the purpose of having a menu. Only one of them would ever be enabled at the same time anyway, depending on what page in the main view is selected.

This is work in progress.

The "View" Menu

All entries are fully functional

Each one opens a view that was formerly a page of the main view, but is now a separate pop-up dialog.

The "Configure" Menu

All entries are fully functional.

Formerly, they were on a menu button in the first page of the main view. That button is now gone.

Most of those items (except "Provide Crypt Passwords") start another YaST module to configure one of the more exotic storage subsystems.

On the IBM s/390 architecture, this also includes storage technologies specific to s/390:

• Configure DASD
• Configure zFCP
• Configure XPRAM

The "Options" Menu

"Options" menu in the installed system

Those entries are not functional yet (thus disabled).

"Options" menu during installation

Notice the extra menu item for "Import Mount Points" which is only available during installation (functional).

Implementation Details

Event Handling via Ruby Introspection

This adds a custom CWM widget to the partitioner that receives all events. It filters out events of type MenuEvent and checks the ID of that event. If the MainMenu class has a matching handler, that handler is called:

For a menu entry Item(Id(:transmogrify), _("Transmogrify")_), the MainMenu class checks if it has a method handle_transmogrify(), and if it does, that method is called. If not, the event is passed up the chain of event handlers.

In particular, that means that a menu entry with an unknown ID that belongs to a separate MenuButton is handled correctly by that MenuButton. However, if menu item IDs clash, the MainMenu comes first and will handle the event.

[ancorgs]

LGTM. Let's merge and continue from here

[ancorgs]

LGTM as a very valid starting point (this is being merged to a separate shared branch). We will refine things afterwards.