Share this project


Share this project

Leadwerks: Build Linux Games, on Linux.'s video poster

We want to put 3D game development on Linux, so you can build and play games without leaving the Linux operating system. Read more

pledged of $20,000 goal
seconds to go


This project was successfully funded on July 31, 2013.

We want to put 3D game development on Linux, so you can build and play games without leaving the Linux operating system.

GDB Followup


When it comes to usability testing, the best feedback you will ever get is from a new person who has never seen your software before.  Once a person acquires a certain level of knowledge, they become accustom to little quirks and their expectations start to form around previous assumptions the software designer has made.  An individual with a completely fresh perspective can often give the best feedback because they are unburdened with the knowledge of how your application works, and their perspective is the most similar to the market at large.  Because the decision to adopt a product is made in a relatively short period of time, it's important to make that introductory usage period as intuitive as possible.

It's with that philosophy that I wrote up my description of my experience so far working with Code::Blocks and GCC/GDB.  (Yes, I know they are separate things.)  The most valuable feedback I can give is at the beginning of my usage.  As I become more adept with these tools, my feedback will actually become less useful.  I am unlikely to discover anything that hasn't been discussed many times over already, and I will lose sight of my original experience delving into the tools.

The reason I took the time to write a frank description of my experience so far, noobish mistakes included, is because I am interested in helping to identify potential friction in the user experience of Linux tools, so that the experience can be streamlined for new users.

My two chief complaints were that hooking into an external executable caused the debugger to pause inexplicably, and that GDB appeared to display variables values only in the current top-most function.  Once you know to expect that pause, it's a simple matter to just always hit "continue" when the application starts, but that doesn't negate the value of my criticism; the fact remains that the application behaves in a way that is counterintuitive to what most programmers would expect.  (I do not know if this is due to Code::Blocks or to GDB itself.)

As for the second issue, it was pointed out to me that you can actually right-click in the debugger and select "switch to frame" which is great.  This must be an aspect of the Code::Blocks IDE.  It's interesting that I actually did read the Code::Blocks wiki explanation of debugging.  The first thing they talk about are watches, which is a little strange because I consider that functionality somewhat obscure.  I rarely use watches in other debuggers.  The next section is actually titled double-clicking in the callstack window and says "Note : when debugging, double-clicking on a frame in the "call stack" debug window does not automatically update the variables displayed in the "watches" debug window."  That was the point where I stopped reading the documentation, which is unfortunate, because the next line gives you the secret you need to switch to the current frame.

So, to follow up on that post:

  • It is likely that neither of my criticisms had to do with GDB itself, but rather the Code::Blocks interface with GDB.
  • Just because you have documentation, that doesn't mean the user will read it.  Documentation does not absolve your from the responsibility to make the user experience as frictionless as possible.  Although sometimes it's unavoidable, I always consider it a minor failure if the user ever has to rely on documentation to use our tools.

I don't expect tools to be redesigned based on my personal experience, but if the developers notice a common pattern that feedback can be useful in eliminating friction in the user experience.  Because for every one person who gets through each "friction point", ten will walk away.  I like to think of it in terms of efficiency:  If I invest ten hours making the user experience more intuitive, that improvement will result in tens of thousands of cumulative hours saved by my users.  Therefore, identifying and improving little quirks in the user experience gives you a disproportionate benefit.

Building software that's powerful yet easy to use is really the heart of my design philosophy for Leadwerks.  It involves many judgement calls, and the ability to view the application from the eyes of both the expert and the complete novice.  But it's something I am oddly passionate about, and I really enjoy creating things that are able to satisfy these sometimes contradictory demands.

BTW, Code::Blocks has the absolute best target/build configuration dialog I have ever seen, by far.  I wish Xcode looked like this.


    1. Creator Igal Alkon on November 19, 2013

      Thanks for the update Josh, I think it's great you provide insight on your experience with the Linux development tools.

      I think you get to understand GDB better if you use it from the command line shell. even just for one day. worked well for me.
      LLDB indeed sounds like a good alternative looking forward for, the only package I found availble on Arch was in the AUR repository ...

    2. Creator TesX on November 12, 2013

      I think it's the Code::Blocks integration fault here...
      In Eclipse for C / C++ or in QtCreator when I hit debug it launches the program under GDB with all the breakpoints, etc... all set up and it "continue"s automatically...

      PS: Maybe there is an option in the settings of Code::Blocks to make this happen automatically too?

      Anyway, Josh, I really appreciate your and other companies efforts to develop on Linux (and I hope all the Community does... :-)

    3. Creator Jeff Craig on November 11, 2013

      GDB is an *incredibly* powerful and obtuse tool. It is probably the most powerful debugger available anywhere, but using it is not trivial, and there has been little effort among the core GNU dev tools team to make it more user friendly, as far as I can tell.

    4. Creator Oscar Norlander on November 11, 2013

      Interesting and insightful update. It would be very good if the C:B community could refine the GDB integration. I usually use GDB from the terminal or through SlickEdit (not free but has pretty good with GDB). After a quick study it looks like Eclipse with CDT is supposed to have a good integration with GDB.

      On a side note, I found this article "Leadwerks: GDB Is Annoying":…

      Te article also mention LDDB and Valve ...

      A closely related article is this (it linked the above article) "Why FreeBSD Is Liking LLDB For Debugging:…