Jump to content
The Dark Mod Forums

DarkRadiant + gtkmm


Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 4 weeks later...

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.

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

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?

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...

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.

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...