Commit cd4b4bfd authored by Murray Cumming's avatar Murray Cumming

Initial revision

See the ChangeLog for up-to-date information.
Murray Cumming <>
Daniel Elstner <>
Former contributors:
Karl Nelson <>
Tero Pulkkinen <>
Elliot Lee <>
Phil Dawes <>
Erik Andersen <>
Bibek Sahu <>
Mirko Streckenbach
Havoc Pennington <>
Guillaume Laurent <>
Todd Dukes <>
Peter Lerner <>
Herbert Valerio Riedel <>
*** #Include "gtkmm/something.h" instead of "gtk--/something.h"
As well as using the new gtkmm name, this means that we don't need to move
the old gtk-- 1.2 headers into a version-specific directory. However, the
new gtkmm 2.0 headers are in a version-specific directory, so this won't
happen again for gtkmm 2.2.
*** Glib::ustring:
glib::ustring has much the same interface as std::string,
but contains UTF8 strings.
Note that a normal ANSI string is also a UTF8 string, so,
if you want to, you can use this class without every thinking about UTF8.
Also, this class has conversions to and from std::string,
so you can use a std::string instead of a glib::ustring -
However, this will not work with multi-byte translations,
just as normal C char* code wouldn't.
In a perfect world the C++ Standard Library would contain a
a UTF8 string, but it doesn't.
*** The main window concept
In gtkmm 1.2 you had to worry about the Window's delete_event signal to make your application quit properly. If you didn't or if you got it wrong then your Window would self-destruct and cause a segfault. This was tedious and difficult, and nobody really understood it.
We've made life simpler by preventing Window from self-destructing, and adding the Gtk::Main::run(window) override. It shows the window, starts the event loop, and stops the event loop when the window is closed. You can think of it as a way to say 'This is the main application window.' or 'The window and the application have the same lifetime. The examples now demonstrate this simpler technique.
*** Glib::RefPtr<>:
Most of the GDK objects are now based on GObject,
so we now have auto-generated classes for them. However, GObject is a bit
stricter than GtkObject about how we can manage it's memory. We can only
unref() a GObject, we can never destroy it. Therefore our C++ wrapper (which
is used by the C GObject) must remain alive as long as the C instance. But of
course it should be deleted when glib tells us that the C instance has died.
Of course you don't want to worry about all that, so we've created RefPtr<>
which does all that for you. Objects such as Gdk::Bitmap can now only be
instantiated with a create() function. For instance,
Glib::RefPtr<Gdk::Bitmap> bitmap
= Gdk::Bitmap::create(window, data, width, height);
You have no way of getting a bare Gdk::Bitmap.
bitmap is then a smart pointer, so you can do this, much like a normal
int depth = bitmap->get_depth().
When bitmap goes out of scope an unref() will happen in the background and you
don't need to worry about it anymore.
This should mean that you *never* need to ref()/unref() a Gdk
object again. GTK+ is a little inconsistent about it's refcounting, though there
are a loose set of rules. All gtkmm methods do any extra referencing for you, so
you don't need to worry about that.
*** Re-written GDK wrappers
The GDK wrappers are now auto-generated and are in the Gdk namespace. With the use of Glib::RefPtr<> you no longer need to worry about ref-counting issues.
*** Clearly-named default signal handlers
Default signal handlers were previously suffixed with _impl - for instance, Button::clicked_impl(). Now that they are prefixed with on_ - for instance, Button::on_clicked() is is much easier to see that they are signal handlers that are worthwhile to override in derived classes.
*** signals prefixed by signal_
For instance, Button::clicked is now Button::signal_clicked. This makes the API and your code clearer, while also avoiding clashes with methods of the same name - for instance, Button::clicked().
*** signals connected via signal accessors.
For instance,
gtkmm 1.2: button.clicked.connect(SigC::slot(this, &Something::somemethod));
gtkmm 1.3: button.signal_clicked().connect(SigC::slot(*this, &Something::somemethod));
*** C++ types used in signal handlers
Signal handlers now use C++ types, just like other C++ methods.
*** Signals do not have slots.
In gtkmm1.2, you could connect a Signal to the 'Slot' of another signal, for instance Gtk::Main::quit.slot(). The actual action that then happened when the signal was emitted was quite arbitrary. These slots did not have any consistent connection with the signal. Therefore we have removed this idea.
*** Namespaced enums:
gtkmm interfaces now use C++ enums rather than the original GTK+ enums.
*** properties:
GTK+ properties can be used like so:
int value = someobject.property_something().get_value();
or alternatively:
someobject.property_something() = 2;
int value = someobject.property_something();
*** GTK+ changes:
Methods and classes that are now deprecated in GTK+ 2.0 are not wrapped in gtkmm 2.0.
Implementation Changes:
*** Much clearer, better documented, more maintainable code-generating code.
*** Use of gtk+'s .defs C interface-definition format, parsed by perl.
*** Seperate .hg/.ccg files parsed by perl.
*** Wrappers for GObject, GtkObject, and Boxed Types.
This diff is collapsed.
This diff is collapsed.
See the MAINTAINERS file.
mailing list:
For information about submitting patches, see
GNOME sherrifs may make changes if they can't get a quick maintainer response from the mailing list or bugzilla.
**** Building from CVS - see README too:
When building from CVS you will probably need to install this Perl module:
\ No newline at end of file
Murray Cumming <>
Daniel Elstner <>
SUBDIRS = tools glib pango atk gdk gtk docs
DIST_SUBDIRS = $(SUBDIRS) scripts demos examples tests
build_shared/Makefile_build.am_fragment \
build_shared/Makefile_build_gensrc.am_fragment \
build_shared/Makefile_gensrc.am_fragment \
build_shared/Makefile_gensrc_platform.am_fragment \
build_shared/Makefile_build_extra.am_fragment \
@echo "*** Everything completed ***"
@echo; echo; \
echo "**********************************************************"; \
echo "* IMPORTANT NOTICE: *"; \
echo "* *"; \
echo "* Be sure you have done a complete build before running *"; \
echo "* 'make dist' or 'make distcheck', because otherwise *"; \
echo "* the tarball will _not_ contain the dependency rules *"; \
echo "* generated by the compiler. *"; \
echo "**********************************************************"; \
echo; echo
include $(top_srcdir)/docs/Makefile_web.am_fragment
doc_tarball_files = \
docs/index.html docs/FAQ/html docs/images/*.gif \
docs/internal/*.txt docs/internal/*.dia docs/reference/html \
docs/tutorial/figures/*.png docs/tutorial/html
# This doesn't work very well in a $(srcdir) != $(builddir) setup,
# but this target is for maintainer use only anyway.
find examples -name '*.cc' -o -name '*.h' -o -name '*.xpm' -o -name '*.xml' | \
tar cf - --files-from - $(doc_tarball_files) | gzip -c --best >$@
# Upload documentation and examples:
list='docs examples'; for subdir in $$list; do \
test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) post-html); \
post-html-local: gtkmm-docs.tar.gz
rsync $(rsync_args) gtkmm-docs.tar.gz $$$(web_path_gtkmm2)
post-html: post-html-recursive post-html-local
(cd docs && $(MAKE) $(AM_MAKEFLAGS) doc-clean)
doc-clean: doc-clean-recursive
(cd docs && $(MAKE) $(AM_MAKEFLAGS) doc-rebuild)
.PHONY: post-html post-html-local post-html-recursive doc-clean doc-clean-recursive doc-rebuild
This diff is collapsed.
This should help people with some of the first problems that they are likely
to find when porting apps from gtkmm 1.2 to gtkmm 2:
Some of these are explained in more details in the CHANGES file.
* Use pkg-config checks instead of the various old .m4 macros:
See the gtkmm_hello package:
* Replace gtk-- 1.2 includes with gtkmm2 includes:
e.g. #include <gtkmm/button.h> instead of <gtk--/button.h>
* Use new signal connection syntax:
e.g. change
* Use new SigC::slot() syntax:
e.g. change
* Change virtual methods overrides used for signal handling from
signalname_impl() to on_signalname().
* Do not connect to a Gtk::Window's "destroy" signal.
* You do not need to connect to Gtk::Window's "delete_event" signal just to
prevent self-destruction of the window, or to quit the application
appropriately. In most cases you should just use the new
Gtk::Main::run(window) override that shows the window and quits when it
is hidden.
* Change Gtk::Widget::set_usize() to Gtk::Widget::set_size_request() or Gtk::Window::set_default_size().
* Change Gtk::Window::set_policy() to set_resizable().
* Change Gtk::wrap() to Glib::wrap(), and gtkobj() to gobj().
* Change Gtk::Pixmap to Gtk::Image
* Change enums from GTK_FOO to Gtk::FOO and GDK_FOO to Gdk::FOO.
* Gtk::Notebook: Change set_page() to set_current_page()
* Container STL-style interfaces: items are now references rather than pointers.
For instance, change
menuList[i]->somemethod() to
* Replace Gtk::Text with Gtk::TextView.
* Replace Gtk::CList and Gtk::CTree with Gtk::TreeView.
* See the GTK+ 2 C porting guide:
amd the GNOME2 C porting guide:
* Replace use of Gnome::Dialog with Gtk::MessageDialog.
* Replace use of Gnome::PropertyBox with a similar, but custom Window
This is the unstable version of gtkmm, aimed at Gtk+ 2.0.x.
See CHANGES for a comparison with gtkmm 1.2.
* Your unstable development environment
* Required libraries:
Your unstable development environment
Until the GTK+ 2.0 / GNOME 2.0 platform is stable, you should try to separate these unstable libraries from your stable GTK+ 1.2 / GNOME 1.2/1.4 libraries. You can do this by installing the unstable libraries into a different prefix.
e.g. ./configure --prefix=/usr/devgnome2
When using the development libraries, you will need to modify some environment variables. This will be easier if you create a file (e.g. devgnome2) in your home directory that contains these commands:
export PATH="/usr/devgnome2/bin:$PATH"; export LD_LIBRARY_PATH="/usr/devgnome2/lib" ; export PKG_CONFIG_PATH="/usr/devgnome2/lib/pkgconfig:$PKG_CONFIG_PATH" ;
You can then type
# source devgnome2
to prepare your environment before building or working with the development libraries.
You may also need to edit /etc/ to add /usr/devgnome2/lib, and then type /sbin/ldconfig to re-process the
The vicious-build-scripts module in might help you with this, if you can get it to work.
Required Libraries
* Of course, you will need gtk+ 2 and its dependencies.<