Loading preferences dialogs with Glade
- From: Michael Ekstrand <lists elehack net>
- To: gtkmm-list gnome org
- Subject: Loading preferences dialogs with Glade
- Date: Sat, 25 Feb 2006 10:26:13 -0600
Hello all:
I'm working on a GTKmm app in which I am building the main window
myself with C++ code, but trying to use Glade to build auxillary
dialogs (preferences, etc.). I'm having a bit of difficulty figuring
out when and how to load my Glade file. Ideally, I don't want to have
to re-read the file every time the preferences dialog is displayed.
Also, the prefs dialog should be modal.
Currently, my app's startup procedures load the Glade file into a
Gnome::Glade::Xml object, and store this in my global singleton
application object. I then have an object for my preferences dialog,
ConfigDialog, which inherits from Gtk::Dialog and implements the
appropriate constructor to be used with get_widget_derived.
ConfigDialog then exposes a static method get(), which grabs the Xml
object from the App, calls get_widget_derived, and returns a
Glib::RefPtr pointing to a new ConfigDialog instance.
Now, I found that, if I set Modal to True in Glade for my prefs dialog,
my application can't receive any events. So I'm trying to set it modal
when I show it, and turn off the modal flag when it's closed.
In the event handler in my main window that is supposed to display the
preferences dialog, I've tried a variety of things (dlg is a RefPtr to
a ConfigDialog object as returned by my static get() method in the
following). Either of
dlg->show();
dlg->set_modal();
or
dlg->set_modal();
dlg->show();
result in loss of all event response (except move/resize) in my main
window, and do not show the prefs dialog. Moving the set_modal() call
into ConfigDialog's on_show() handler results in a segfault.
So, am I headed down entirely the wrong path? Does ConfigDialog::get()
need to load the Glade data every time it's called? Should I (horrors)
be using code generation for this task? Or is there something minor
that I'm missing?
Is there a better way to think about this whole problem?
Thanks,
Michael
--
mouse, n: a device for pointing at the xterm in which you want to type.
-- Fortune
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]