Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
Gtk2::Dialog(3)	      User Contributed Perl Documentation      Gtk2::Dialog(3)

       Gtk2::Dialog - wrapper for GtkDialog

	 # 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 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

       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,
					   '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 });


   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

       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 ...



   $widget = Gtk2::Dialog->new;
   $widget = Gtk2::Dialog->new ($title,	$parent, $flags, ...)
       o   ... (list) of button-text =>	response-id pairs.

       o   $flags (Gtk2::DialogFlags) interesting properties

       o   $parent (Gtk2::Window or undef) make	the new	dialog transient for
	   this	window

       o   $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',
				     [qw/modal destroy-with-parent/],
				     'gtk-ok'	  => 'accept',
				     'gtk-cancel' => 'reject');

   $widget = Gtk2::Dialog->new_with_buttons ($title, $parent, $flags, ...)
       o   ... (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)
       o   $child (Gtk2::Widget)

       o   $response_id	(Gtk2::ResponseType)

   widget = $dialog->add_button	($button_text, $response_id)
       o   $button_text	(string) may be	arbitrary text with mnenonics, or
	   stock ids

       o   $response_id	(Gtk2::ResponseType)

       Returns the created button.

   $dialog->add_buttons	(...)
       o   ... (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 (...)
       o   ... (list)

       Since: gtk+ 2.6

   widget = $dialog->get_content_area
   $dialog->set_default_response ($response_id)
       o   $response_id	(Gtk2::ResponseType)

   boolean = $dialog->get_has_separator
   $dialog->set_has_separator ($setting)
       o   $setting (boolean)

   $dialog->response ($response_id)
       o   $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)
       o   $widget (Gtk2::Widget)

       Since: gtk+ 2.8

   $dialog->set_response_sensitive ($response_id, $setting)
       o   $response_id	(Gtk2::ResponseType)

       o   $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 ();

   widget = $dialog->get_widget_for_response ($response_id)
       o   $response_id	(Gtk2::ResponseType)

       Since: gtk+ 2.20

       'has-separator' (boolean	: default false	: readable / writable /
       private / static-nick / static-blurb / deprecated)
	   The dialog has a separator bar above	its buttons

       'action-area-border' (integer : default 5 : readable / private /
       static-nick / static-blurb)
	   Width of border around the button area at the bottom	of the dialog

       'button-spacing'	(integer : default 6 : readable	/ private / static-
       nick / static-blurb)
	   Spacing between buttons

       'content-area-border' (integer :	default	2 : readable / private /
       static-nick / static-blurb)
	   Width of border around the main dialog area

       'content-area-spacing' (integer : default 0 : readable /	private	/
       static-nick / static-blurb)
	   Spacing between elements of the main	dialog area

       close (Gtk2::Dialog)
       response	(Gtk2::Dialog, integer)

       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.)

   flags Gtk2::DialogFlags
       o   'modal' / 'GTK_DIALOG_MODAL'

       o   'destroy-with-parent' / 'GTK_DIALOG_DESTROY_WITH_PARENT'

       o   '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.

       o   'none' / 'GTK_RESPONSE_NONE'

       o   'reject' / 'GTK_RESPONSE_REJECT'

       o   'accept' / 'GTK_RESPONSE_ACCEPT'

       o   'delete-event' / 'GTK_RESPONSE_DELETE_EVENT'

       o   'ok'	/ 'GTK_RESPONSE_OK'

       o   'cancel' / 'GTK_RESPONSE_CANCEL'

       o   'close' / 'GTK_RESPONSE_CLOSE'

       o   'yes' / 'GTK_RESPONSE_YES'

       o   'no'	/ 'GTK_RESPONSE_NO'

       o   'apply' / 'GTK_RESPONSE_APPLY'

       o   'help' / 'GTK_RESPONSE_HELP'

       Gtk2, Glib::Object, Glib::InitiallyUnowned, Gtk2::Object, Gtk2::Widget,
       Gtk2::Container,	Gtk2::Bin, Gtk2::Window

       Copyright (C) 2003-2011 by the gtk2-perl	team.

       This software is	licensed under the LGPL.  See Gtk2 for a full notice.

perl v5.32.1			  2021-09-21		       Gtk2::Dialog(3)


Want to link to this manual page? Use this URL:

home | help