Gtk2::Dialog(3) User Contributed Perl Documentation Gtk2::Dialog(3)NAMEGtk2::DialogSYNOPSIS
# create a new dialog with some buttons - one stock, one not.
$dialog = Gtk2::Dialog->new ($title, $parent_window, $flags,
'gtk-cancel' => 'cancel',
'Do it' => 'ok');
# create window contents for yourself.
$dialog->get_content_area ()->add ($some_widget);
$dialog->set_default_response ('ok');
# show and interact modally -- blocks until the user
# activates a response.
$response = $dialog->run;
if ($response eq 'ok') {
do_the_stuff ();
}
# activating a response does not destroy the window,
# that's up to you.
$dialog->destroy;
DESCRIPTION
Dialog boxes are a convenient way to prompt the user for a small amount
of input, eg. to display a message, ask a question, or anything else
that does not require extensive effort on the user's part.
GTK+ treats a dialog as a window split vertically. The top section is a
Gtk2::VBox, and is where widgets such as a Gtk2::Label or a Gtk2::Entry
should be packed. The bottom area is known as the "action_area". This
is generally used for packing buttons into the dialog which may perform
functions such as cancel, ok, or apply. The two areas are separated by
a Gtk2::HSeparator.
GtkDialog boxes are created with a call to "Gtk2::Dialog->new". The
multi-argument form (and its alias, "new_with_buttons" is recommended;
it allows you to set the dialog title, some convenient flags, and add
simple buttons all in one go.
If $dialog is a newly created dialog, the two primary areas of the
window can be accessed as "$dialog->get_content_area ()" and
"$dialog->get_action_area ()", as can be seen from the example, below.
A 'modal' dialog (that is, one which freezes the rest of the
application from user input), can be created by calling the
Gtk2::Window method "set_modal" on the dialog. You can also pass the
'modal' flag to "new".
If you add buttons to GtkDialog using "new", "new_with_buttons",
"add_button", "add_buttons", or "add_action_widget", clicking the
button will emit a signal called "response" with a response ID that you
specified. GTK+ will never assign a meaning to positive response IDs;
these are entirely user-defined. But for convenience, you can use the
response IDs in the Gtk2::ResponseType enumeration. If a dialog
receives a delete event, the "response" signal will be emitted with a
response ID of 'delete-event'.
If you want to block waiting for a dialog to return before returning
control flow to your code, you can call "$dialog->run". This function
enters a recursive main loop and waits for the user to respond to the
dialog, returning the response ID corresponding to the button the user
clicked.
For the simple dialog in the following example, in reality you'd
probably use Gtk2::MessageDialog to save yourself some effort. But
you'd need to create the dialog contents manually if you had more than
a simple message in the dialog.
# Function to open a dialog box displaying the message provided.
sub quick_message {
my $message = shift;
my $dialog = Gtk2::Dialog->new ('Message', $main_app_window,
'destroy-with-parent',
'gtk-ok' => 'none');
my $label = Gtk2::Label->new (message);
$dialog->get_content_area ()->add ($label);
# Ensure that the dialog box is destroyed when the user responds.
$dialog->signal_connect (response => sub { $_[0]->destroy });
$dialog->show_all;
}
Delete, Close and Destroy
In the default keybindings the "Esc" key calls the "close" action
signal. The default in that signal is to synthesise a "delete-event"
like a window manager close would do.
A delete-event first runs the "response" signal with ID "delete-event",
but the handler there can't influence the default destroy behaviour of
the "delete-event" signal. See Gtk2::Window for notes on destroy vs
hide.
If you add your own "Close" button to the dialog, perhaps using the
builtin "close" response ID, you must make your "response" signal
handler do whatever's needed for closing. Often a good thing is just
to run the "close" action signal the same as the Esc key.
sub my_response_handler {
my ($dialog, $response) = @_;
if ($response eq 'close') {
$self->signal_emit ('close');
} elsif ...
}
HIERARCHY
Glib::Object
+----Glib::InitiallyUnowned
+----Gtk2::Object
+----Gtk2::Widget
+----Gtk2::Container
+----Gtk2::Bin
+----Gtk2::Window
+----Gtk2::Dialog
INTERFACES
Glib::Object::_Unregistered::AtkImplementorIface
Gtk2::Buildable
METHODS
$widget = Gtk2::Dialog->new;
$widget = Gtk2::Dialog->new ($title, $parent, $flags, ...)
· ... (list) of button-text => response-id pairs.
· $flags (Gtk2::DialogFlags) interesting properties
· $parent (Gtk2::Window or undef) make the new dialog transient for
this window
· $title (string) window title
The multi-argument form takes the same list of text => response-id
pairs as "$dialog->add_buttons". Do not pack widgets directly into the
window; add them to "$dialog->get_content_area ()".
Here's a simple example:
$dialog = Gtk2::Dialog->new ('A cool dialog',
$main_app_window,
[qw/modal destroy-with-parent/],
'gtk-ok' => 'accept',
'gtk-cancel' => 'reject');
$widget = Gtk2::Dialog->new_with_buttons ($title, $parent, $flags, ...)
· ... (list) of button-text => response-id pairs.
Alias for the multi-argument version of "Gtk2::Dialog->new".
widget = $dialog->get_action_area
$dialog->add_action_widget ($child, $response_id)
· $child (Gtk2::Widget)
· $response_id (Gtk2::ResponseType)
widget = $dialog->add_button ($button_text, $response_id)
· $button_text (string) may be arbitrary text with mnenonics, or
stock ids
· $response_id (Gtk2::ResponseType)
Returns the created button.
$dialog->add_buttons (...)
· ... (list) of button-text => response-id pairs
Like calling "$dialog->add_button" repeatedly, except you don't get the
created widgets back. The buttons go from left to right, so the first
button added will be the left-most one.
$dialog->set_alternative_button_order (...)
· ... (list)
Since: gtk+ 2.6
widget = $dialog->get_content_area
$dialog->set_default_response ($response_id)
· $response_id (Gtk2::ResponseType)
boolean = $dialog->get_has_separator
$dialog->set_has_separator ($setting)
· $setting (boolean)
$dialog->response ($response_id)
· $response_id (Gtk2::ResponseType)
Emit the response signal, as though the user had clicked on the button
with $response_id.
scalar = $dialog->get_response_for_widget ($widget)
· $widget (Gtk2::Widget)
Since: gtk+ 2.8
$dialog->set_response_sensitive ($response_id, $setting)
· $response_id (Gtk2::ResponseType)
· $setting (boolean)
Enable or disable an action button by its $response_id.
$responsetype = $dialog->run
Blocks in a recursive main loop until the dialog either emits the
response signal, or is destroyed. If the dialog is destroyed during
the call to "$dialog->run", the function returns 'GTK_RESPONSE_NONE'
('none'). Otherwise, it returns the response ID from the "response"
signal emission. Before entering the recursive main loop,
"$dialog->run" calls "$widget->show" on $dialog for you. Note that you
still need to show any children of the dialog yourself.
During "run", the default behavior of "delete_event" is disabled; if
the dialog receives "delete_event", it will not be destroyed as windows
usually are, and "run" will return 'delete-event'. Also, during "run"
the dialog will be modal. You can force "run" to return at any time by
calling "$dialog->response" to emit the "response" signal. Destroying
the dialog during "run" is a very bad idea, because your post-run code
won't know whether the dialog was destroyed or not.
After "run" returns, you are responsible for hiding or destroying the
dialog if you wish to do so.
Typical usage of this function might be:
if ('accept' eq $dialog->run) {
do_application_specific_something ();
} else {
do_nothing_since_dialog_was_cancelled ();
}
$dialog->destroy;
PROPERTIES
'has-separator' (boolean : readable / writable / private)
The dialog has a separator bar above its buttons
SIGNALS
response (Gtk2::Dialog, integer)
close (Gtk2::Dialog)
Note that currently in a Perl subclass of "Gtk2::Dialog" a class
closure, ie. class default signal handler, for the "response" signal
will be called with the response ID just as an integer, it's not turned
into an enum string like "ok" the way a handler setup with
"signal_connect" receives.
Hopefully this will change in the future, so don't count on it. In the
interim the easiest thing to do is install your default handler in
"INIT_INSTANCE" with a "signal_connect". (The subtleties of what order
handlers are called in will differ, but often that doesn't matter.)
ENUMS AND FLAGS
flags Gtk2::DialogFlags
· 'modal' / 'GTK_DIALOG_MODAL'
· 'destroy-with-parent' / 'GTK_DIALOG_DESTROY_WITH_PARENT'
· 'no-separator' / 'GTK_DIALOG_NO_SEPARATOR'
enum Gtk2::ResponseType
The response type is somewhat abnormal as far as gtk2-perl enums go.
In C, this enum lists named, predefined integer values for a field that
is other composed of whatever integer values you like. In Perl, we
allow this to be either one of the string constants listed here or any
positive integer value. For example, 'ok', 'cancel', 4, and 42 are all
valid response ids. You cannot use arbitrary string values, they must
be integers. Be careful, because unknown string values tend to be
mapped to 0.
· 'none' / 'GTK_RESPONSE_NONE'
· 'reject' / 'GTK_RESPONSE_REJECT'
· 'accept' / 'GTK_RESPONSE_ACCEPT'
· 'delete-event' / 'GTK_RESPONSE_DELETE_EVENT'
· 'ok' / 'GTK_RESPONSE_OK'
· 'cancel' / 'GTK_RESPONSE_CANCEL'
· 'close' / 'GTK_RESPONSE_CLOSE'
· 'yes' / 'GTK_RESPONSE_YES'
· 'no' / 'GTK_RESPONSE_NO'
· 'apply' / 'GTK_RESPONSE_APPLY'
· 'help' / 'GTK_RESPONSE_HELP'
SEE ALSO
Gtk2, Glib::Object, Glib::InitiallyUnowned, Gtk2::Object, Gtk2::Widget,
Gtk2::Container, Gtk2::Bin, Gtk2::Window
COPYRIGHT
Copyright (C) 2003-2011 by the gtk2-perl team.
This software is licensed under the LGPL. See Gtk2 for a full notice.
perl v5.14.1 2011-08-30 Gtk2::Dialog(3)