[gtkmm] namespace issue with simple widget implementation
- From: Carl Nygard <cjnygard fast net>
- To: gtkmm-list gnome org
- Cc: Murray Cumming <murrayc murrayc com>
- Subject: [gtkmm] namespace issue with simple widget implementation
- Date: Fri, 06 Aug 2004 13:48:07 -0400
Murray, et al,
I have a set of libraries that serve to make some aspects of
implementing data-backed widgets easier. Before diving into the
details, my question is about namespace usage. Right now the code
follows a naming convention GTKLink::<name>Widget. I'd like to use
instead Gtk::Simple::<name> but I'm guessing the polite thing to do is
ask first;)
The code is mostly template code, and the basic implementation is pretty
simple. Hopefully my explanation is equally simple.
The code is built upon two base classes, Proxy::Proxy<typename T> and
SimpleWidget::BaseWidget. The Proxy::* classes provide a way to get/set
data values without knowing where they live. So there's classes for
class function access, struct data-member access, independent var, and
one built-in the Proxy.
The BaseWidget simply provides virtual functions for UpdateWidget() and
UpdateData(). The first updates the state of the widget to reflect the
data value, the other updates the data value from widget contents.
SimpleWidget::* classes provide a base class for general widget types
independent of the gui classes, so one can use these without requiring
(that individual) code to know about Gtk/Qt/whatever widgets.
The GTKLink::* classes take a Proxy and a Gtk::* widget and bind them
together, implementing the UpdateWidget()/UpdateData() functions.
There's also a NotifierProxy that takes a normal Proxy and a widget and
updates the widget when the data value is changed (changed via the
proxy, of course).
This code was inspired by the Perl/Tk classes that allowed the user to
bind a variable to a widget and forget about the widget. No offense
Murray, but I'd like to forget about the widgets as much as possible;)
I'm planning on releasing the code soon, working out some bureaucratic
issues first. The code is relatively small, so I could send a copy to
anyone who wants it, but I'm not going to spam the list with it.
Regards,
Carl
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]