Re: [gnomemm] libglademm / widget templates

[Ole Laursen <olau hardworking dk>]

"C.J. Collier" <cjcollier colliertech org> writes:

[...]

> Thank you, Ole.  I think that's what I want, as long as I get ANOTHER
> minor_window each time I call that function.  I'll try it out.

It will.

> Another question along these lines is this: Is there a way to have
> glade use inheritence?  Many of Murray's examples create a
> 
> class MyWindow : public Gtk::Window
> 
> or the like, in which he creates member objects and member signal
> handlers.  This is nice, as it doesn't clutter up the default
> namespace, but I don't see this being possible if glade/libglademm
> doesn't allow you to use arbitrary classes for widgets.

You don't have to abandon that way of structuring the code. Actually,
I think that is the single most important thing in gtkmm. If you
always create one class per window type, it is very easy to structure
the application.

My general pattern is like this:

  class PreferencesWindow: public SigC::Object, noncopyable
  {
  public:
    PreferencesWindow();
    ~PreferencesWindow();

    void raise();
    void show();

    // ... other public methods, usually not many are needed

  private:
    Glib::RefPtr<Gnome::Glade::Xml> ui;

    Gtk::Window *window;
    // ... other widget pointers extracted from the XML 

    // ... other call backs

    bool on_closed(GdkEventAny *);
  };

Noncopyable is just a helper class for making copy constructor and
assignment private that I ripped from Boost. raise() and show() are
used by the MainWindow that constructs this window.

And for the implementation

  PreferencesWindow::PreferencesWindow()
  {
    ui = get_glade_xml("preferences_window"); // wraps Gnome::Glade::create

    ui->get_widget("preferences_window", window);

    window->set_transient_for(MainWindow::instance().get_window());
    window->set_type_hint(Gdk::WINDOW_TYPE_HINT_DIALOG);

    // ... extract other widgets

    // ... connect callbacks for these

    // for instance:

    // Gtk::Button *button;
    // ui->get_widget("close_button", button);
    // button->signal_clicked()
    //  .connect(SigC::slot(*this, &PreferencesWindow::on_close_clicked));

    window->signal_delete_event()
      .connect(SigC::slot(*this, &PreferencesWindow::on_closed));
  }

  PreferencesWindow::~PreferencesWindow()
  {
  }

  void PreferencesWindow::show()
  {
    window->show();
  }

  void PreferencesWindow::raise()
  {
    window->deiconify();

    window->raise();
  }

Then in the MainWindow class, I keep a
std::auto_ptr<PreferencesWindow> which I fill in when first needed. If
you need access to the actual window, you can add a
'Gtk::Window &get_window()' call. I do that for MainWindow.

So you can "fake" the inheritance by using aggregation. If you don't
provide a get_window(), it will also enhance the encapsulation.


I've been wanting to write about this for some time. We need a good
"programming with libglademm" tutorial. I'm prepared to write one.
Murray, what do you think? Should it be included on www.gtkmm.org? If
so, it is perhaps best to write in Docbook XML (?), else I'll just
write in XHTML and put it on my home page.

I am thinking of including:

  - why [lib]glade[mm] is the best thing since sliced bread

  - how to use it (from a libglademm perspective, I don't want another
    Glade tutorial)

  - how to structure an application sensibly with libglademm supplied
    widgets

So it won't be terribly long. I just need some time, but it sounds
like an exciting project.

> Is it possible to have glade parse a class and display it in the
> palette?

Theoretically, yes, I think. I doubt anyone here knows how. :-)

> Does anyone use libglademm?

I think we're lots of people who do. Using Glade/libglade/libglademm
is much, much better than hand coding the interface. The hand-crafted
code will be nearly unreadable and difficult to maintain (I've been
down that road), whereas the XML is nicely structured, even with a
graphical tool to manipulate it.

-- 
Ole Laursen
http://www.cs.auc.dk/~olau/