Yast UI
ButtonBox Class Reference

Layout for push buttons that takes button order into account. More...

Detailed Description

Layout for push buttons that takes button order into account.

Following widget variants exist: ButtonBox Id of widget: ButtonBox


# encoding: utf-8
# Example for ButtonBox
module Yast
class ButtonBox1Client < Client
def main
Yast.import "UI"
HVCenter(Label("Hello, world!")),
PushButton(Id(:doit1), "Do &Something Very Cool"),
PushButton(Id(:doit2), Opt(:key_F10, :customButton), "Do &More"),
PushButton(Id(:help), "&Help"),
PushButton(Id(:ok), "&OK"),
PushButton(Id(:cancel), "&Cancel"),
PushButton(Id(:apply), "&Apply")

This widget arranges its push button child widgets according to the current button order.

The button order depends on what UI is used and (optionally) what desktop environment the UI currently runs in.

The Qt and NCurses UIs use the KDE / Windows button order:

[OK] [Apply] [Cancel] [Custom1] [Custom2] ... [Help]

[Continue] [Cancel]

[Yes] [No]

The Gtk UI uses the GNOME / MacOS button order:

[Help] [Custom1] [Custom2] ... [Apply] [Cancel] [OK]

[Cancel] [Continue]

[No] [Yes]

Certain buttons have a predefined role:

In a [Continue] [Cancel] dialog, [Continue] has the okButton role. In a [Yes] [No] dialog, [Yes] has the okButton role, [No] has the cancelButton role.

The UI automatically recognizes standard button labels and assigns the proper role. This is done very much like assigning function keys (see UI::SetFunctionKeys()). The UI also has some built-in heuristics to recognize standard button IDs like Id(:ok), Id("ok"), Id(:yes), etc.

Sometimes it makes sense to use something like [Print] or [Delete] for the okButton role if printing or deleting is what the respective dialog is all about. In that case, the application has to explicitly specify that button role: Use Opt(:okButton).

Similarly, there are Opt(:cancelButton), Opt(:applyButton), Opt(:helpButton).

By default, a ButtonBox with more than one button is required to have one okButton and one cancelButton. Opt(:relaxSanityCheck) relaxes those requirements: It does not check for one okButton and one cancelButton. This should be used very sparingly – use your common sense. One Example where this is legitimate is a pop-up dialog with [OK] [Details] for error messages that can be explained in more detail. Most dialogs with more than just an [OK] or a [Close] button should have a [Cancel] button.

ButtonBox widgets can have no other child widgets than PushButton widgets. ButtonBox widgets are horizontally stretchable and vertically non-stretchable. If there is more space, their layout policy (depending on KDE or GNOME button order) specifies whether to center or right-align the buttons.

The documentation for this class was generated from the following file: