DarkRadiant + gtkmm

[greebo]

I did a bit of research with regards to using gtkmm for DarkRadiant and a possible migration scenario. In a separate branch I could get the DR+gtkmm combination to work for both the Win32 and Win64 targets, by compiling the gtkmm binaries from source (no 64 bit binary packages available for download, contrary to GTK+). The Linux part is not yet looked into, but I guess it's "just" downloading the gtkmm-dev packages and then adding the correct link switch.

 

gtkmm is much nicer to work with, there is a proper inheritance tree (no stupid GTK_WIDGET() casts), support for member method binding to callbacks, the code is much better readable. I really like the way it's set up, it's a well-designed binding.

 

As for a possible migration plan: it's possible to run GTK+ and gtkmm side by side, gtkmm offers access to the underlying C objects via the gobj() methods. As first test, I migrated the ui::SoundShaderPreview class to gtkmm, which works fine. One thing to watch out for is memory management in terms of "who owns the widgets and who is destroying them". gtkmm is using scoped classes which destroy the widgets in their destructor, unless one specifically allocates and delegates management to gtkmm using for example Gtk::manage(new Gtk::Hbox(false, 6)), RAII-style.

 

A (minor) disadvantage is that gtkmm is not building upon boost, but glib (of course). There is the Gib::RefPtr template which works similarly to boost::shared_ptr, so this is a bit redundant.

[OrbWeaver]

I did a bit of research with regards to using gtkmm for DarkRadiant and a possible migration scenario. In a separate branch I could get the DR+gtkmm combination to work for both the Win32 and Win64 targets, by compiling the gtkmm binaries from source (no 64 bit binary packages available for download, contrary to GTK+). The Linux part is not yet looked into, but I guess it's "just" downloading the gtkmm-dev packages and then adding the correct link switch.

 

gtkmm is much nicer to work with, there is a proper inheritance tree (no stupid GTK_WIDGET() casts), support for member method binding to callbacks, the code is much better readable. I really like the way it's set up, it's a well-designed binding.

 

I saw your commits, and it looks like you are making some good progress. A C++- binding for GTK would be a big step forward for DR, given how horribly verbose all of those gtk_do_something() functions become after a while.

 

I don't think there should be any problems activating this on Linux, there will certainly be a pkg-config script for Gtkmm which means only a few lines in configure.ac plus modifications to the respective Makefile.am's to include the header/library variables.

 

As for a possible migration plan: it's possible to run GTK+ and gtkmm side by side, gtkmm offers access to the underlying C objects via the gobj() methods. As first test, I migrated the ui::SoundShaderPreview class to gtkmm, which works fine. One thing to watch out for is memory management in terms of "who owns the widgets and who is destroying them". gtkmm is using scoped classes which destroy the widgets in their destructor, unless one specifically allocates and delegates management to gtkmm using for example Gtk::manage(new Gtk::Hbox(false, 6)), RAII-style.

 

I have read about the manage thing when looking briefly at Gtkmm documentation, I am familiar with that concept from Qt as well (anything which derives from QObject is destroyed by its parent, otherwise you must destroy it yourself).

 

It is encouraging that it is possible to run both GTK and GTKmm side-by-side, I guess the only decision to be made here is whether to ship intermediate releases with both sets of libraries in use (which will increase total package size slightly), or to wait until all migration has been done and everything is using GTKmm (which is of course a very big job).

 

A (minor) disadvantage is that gtkmm is not building upon boost, but glib (of course). There is the Gib::RefPtr<> template which works similarly to boost::shared_ptr<>, so this is a bit redundant.

 

That doesn't sound like a problem, the shared_ptr template is almost trivial anyway, so it's no big deal if certain libraries are using their own subsitutes.

[Serpentine]

Seems quite interesting, the few times I've played with DR source to fix some annoyance which always tends to be UI related I run into how much I hate GTK - and gtkmm does knock off quite a few of the hate points from what their feature page talks about. So yeah, maybe we'll see some UI work from yours truly in the future

[greebo]

I don't think there should be any problems activating this on Linux, there will certainly be a pkg-config script for Gtkmm which means only a few lines in configure.ac plus modifications to the respective Makefile.am's to include the header/library variables.

Thank you for looking into the Linux side of things, I saw you've already adjusted the makefiles. Seems to have been an easy change?

 

It is encouraging that it is possible to run both GTK and GTKmm side-by-side, I guess the only decision to be made here is whether to ship intermediate releases with both sets of libraries in use (which will increase total package size slightly), or to wait until all migration has been done and everything is using GTKmm (which is of course a very big job).

In Windows at least, the gtkkmm binaries are building on top of the regular GTK+ package, which means we need both sets of binaries in any case, even if we don't include any header of the C API anymore. It's not a big deal though, all gtkmm release binaries weigh about 4 MB in total, which is definitely justified.

 

This means that as soon as the groundwork is done I can go ahead and merge the change back into trunk. There are still a few issues I need to sort out (GTK assertions when unloading the modules, indicating there is some memory mismanagement going on. It's easy to pack gtkmm classes into the C-style functions, but the order of destruction suddenly is important, now that we have proper C++ destructors actually doing their job). Once that's done and the most important utility classes are available (and working) we can aim for a seamless migration from GTK+ to gtkmm. One more thing to figure out is whether gtkglextmm is available and usable.

 

Currently, we have the gtkutil::Window classes and the MainFrame converted to gtkmm, plus a few smaller classes. Right now, I'm hunting down that GTK asertion, but I'm not sure if I can find that one - maybe I'll leave it and assume it will be fixed as soon as we have removed all C API calls.

[OrbWeaver]

Thank you for looking into the Linux side of things, I saw you've already adjusted the makefiles. Seems to have been an easy change?

 

Very simple indeed, the GTKmm flags include all of the required GTK flags as well so it was a simple search and replace.

 

In Windows at least, the gtkkmm binaries are building on top of the regular GTK+ package, which means we need both sets of binaries in any case, even if we don't include any header of the C API anymore. It's not a big deal though, all gtkmm release binaries weigh about 4 MB in total, which is definitely justified.

 

Yes I see that now, in which case there is much less redundancy than I originally assumed, and a progressive migration therefore seems like a good strategy.

 

One more thing to figure out is whether gtkglextmm is available and usable.

 

Well there is at least a gtkglextmm package in Ubuntu, and GNOME are still offering it, so it looks promising.

[AluminumHaste]

Very simple indeed, the GTKmm flags include all of the required GTK flags as well so it was a simple search and replace.

 

 

 

Yes I see that now, in which case there is much less redundancy than I originally assumed, and a progressive migration therefore seems like a good strategy.

 

 

 

Well there is at least a gtkglextmm package in Ubuntu, and GNOME are still offering it, so it looks promising.

 

I also saw this commit and it built just fine, but was wondering if anyone was able to get an updated winbuild so we can compile the DR source again.

[greebo]

Is something not working in the trunk? I'm still switched to the gtkmm branch, for weeks now.

[OrbWeaver]

Is something not working in the trunk? I'm still switched to the gtkmm branch, for weeks now.

 

Yes, my latest commit on trunk would require a Win32 build script update. However, it is not particularly a important change: AluminumHaste, if you check out than earlier revision, e.g. 5712, it should compile fine.

[AluminumHaste]

Yes, my latest commit on trunk would require a Win32 build script update. However, it is not particularly a important change: AluminumHaste, if you check out than earlier revision, e.g. 5712, it should compile fine.

 

Sounds good I'll revert to 5712, but the whole reason I use the svn builds is to test new features.

[OrbWeaver]

Sounds good I'll revert to 5712, but the whole reason I use the svn builds is to test new features.

 

Right, but there haven't been any new features in the trunk for a while. All the recent work has been greebo working on the GTKmm transition, which is in the gtkmm branch; of course you can checkout and build this, but there may be issues and probably no real advantage to using this at the moment.

[AluminumHaste]

Right, but there haven't been any new features in the trunk for a while. All the recent work has been greebo working on the GTKmm transition, which is in the gtkmm branch; of course you can checkout and build this, but there may be issues and probably no real advantage to using this at the moment.

 

I thought I had already switched to this trunk, maybe not.....mmmmm, I'll have to check when get back.

[greebo]

I believe I'm mostly done now with the transition, all UI-related code has been migrated to gtkmm. There are a few classes here and there which rely on glib functions, but this is not a problem.

 

I'm going to merge back the changes into the trunk and compile a first pre-release test package, for some volunteers to try out.

[AluminumHaste]

I believe I'm mostly done now with the transition, all UI-related code has been migrated to gtkmm. There are a few classes here and there which rely on glib functions, but this is not a problem.

 

I'm going to merge back the changes into the trunk and compile a first pre-release test package, for some volunteers to try out.

 

EDIT: Nevermind lol, just read the rest of your post. Cool I'll check out tonight then.

[OrbWeaver]

Linux build is now working post-merge and the application runs, although I haven't done any thorough testing.

 

I've just been looking at some documentation on Glade, which is the "logical next step" in the modernisation of GTK use. It separates UI design from logic by storing the widget structure in an XML file which is then parsed at runtime to build the interface, rather than writing code for each widget individually (this is much closer to how Qt works).

 

In this case converting everything to use Glade would be a monumental task (even more than converting to GTKmm I suspect), because each window would have to be re-designed from scratch in Glade, but it could be useful for development of new dialogs. The Gtk::GtkBuilder object is right there in GTK/GTKmm, so as far as I know it could just be used in various situations without requiring any build adjustments or new libraries.

[AluminumHaste]

Linux build is now working post-merge and the application runs, although I haven't done any thorough testing.

 

I've just been looking at some documentation on Glade, which is the "logical next step" in the modernisation of GTK use. It separates UI design from logic by storing the widget structure in an XML file which is then parsed at runtime to build the interface, rather than writing code for each widget individually (this is much closer to how Qt works).

 

In this case converting everything to use Glade would be a monumental task (even more than converting to GTKmm I suspect), because each window would have to be re-designed from scratch in Glade, but it could be useful for development of new dialogs. The Gtk::GtkBuilder object is right there in GTK/GTKmm, so as far as I know it could just be used in various situations without requiring any build adjustments or new libraries.

 

Is the windows version up?

[OrbWeaver]

Is the windows version up?

 

http://forums.thedarkmod.com/topic/11654-darkradiant-150-pre-release-sanity-check/

[greebo]

Linux build is now working post-merge and the application runs, although I haven't done any thorough testing.

 

I've just been looking at some documentation on Glade, which is the "logical next step" in the modernisation of GTK use. It separates UI design from logic by storing the widget structure in an XML file which is then parsed at runtime to build the interface, rather than writing code for each widget individually (this is much closer to how Qt works).

 

In this case converting everything to use Glade would be a monumental task (even more than converting to GTKmm I suspect), because each window would have to be re-designed from scratch in Glade, but it could be useful for development of new dialogs. The Gtk::GtkBuilder object is right there in GTK/GTKmm, so as far as I know it could just be used in various situations without requiring any build adjustments or new libraries.

Ah, interesting. This sounds very similar to the WPF stuff some folks here at work are using, they also use XML files to store the window structure. Separating our dialog in a Model-View-ViewModel pattern is indeed a huge task.

 

There is always plenty of new material to learn when it comes to coding.

[OrbWeaver]

Ah, interesting. This sounds very similar to the WPF stuff some folks here at work are using, they also use XML files to store the window structure.

 

Indeed, and Qt with its Designer files (although we still use the old system whereby these are compiled into C++ classes, it's only recently they added support for loading dynamically at runtime).

 

There is always plenty of new material to learn when it comes to coding.

 

Absolutely, that's part of the fun of course. If I feel reasonably motivated I might have a go at converting some dialogs which I am familiar with to use Glade, for example the Add Property dialog or something simple. I already wrote a little proof-of-concept test program and it was very easy indeed.

[AluminumHaste]

I see you merged the gtkmm branch into the main repo, but now I won't compile, it's almost there, just got this error.

 

1>C:\darkradiant\w32deps\gtk2\include\gtk-2.0\gtk/gtkwidget.h(40) : fatal error C1083: Cannot open include file: 'atk/atk.h': No such file or directory

 

The file is there of course.

[greebo]

The gtkmm branch has been merged since weeks, and it does compile (I got a new computer a week ago, and I built everything from scratch, it compiled just fine).

 

Are you sure you have w32deps up to date and switched to trunk/w32deps?

[greebo]

Forget it, I get the same here now, it's just an include path missing. Will be fixed when I merge my particles branch back into the trunk.

[AluminumHaste]

Forget it, I get the same here now, it's just an include path missing. Will be fixed when I merge my particles branch back into the trunk.

 

Np,