[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Porting DDD to Gtk(mm)

From: Peter Wainwright
Subject: Re: RFC: Porting DDD to Gtk(mm)
Date: Sat, 02 Sep 2006 21:26:40 +0100

On Tue, 2006-07-04 at 12:18 +0200, Andrew Gaylard wrote:
> Hi Peter,
> On 7/1/06, Peter Wainwright <address@hidden> wrote:
>         Functionally, DDD is the best debugger I've ever used (at
>         least, on
>         a Free Software platform). Over the past 5 years it has become
>         an
>         indispensable part of my programming toolkit.
>         However, visually, it is as UGLY as SIN. Clearly, Motif was
>         an 
>         obvious choice of toolkit when DDD was first conceived, but
>         now
>         it sticks out like a sore thumb on modern Linux systems, with
>         their anti-aliased fonts and desktop themes. 
> Actually, Motif can look quite beautiful with the proper defaults. 
> Try DDD under CDE and see what I mean.  The trouble with Motif
> is that it makes the easy things hard and the hard things bloody
> impossible -- so much so that one has to go behind it's back and
> mess with raw X events and X windows.  For instance, try capturing 
> the ESC keypress when a button has the focus.  And yes, I fully
> agree about anti-aliased fonts.
> Anyway, for all these reasons, Motif isn't the future, that's for
> sure.
>         So, in response
>         to my itch (also popular demand) I've embarked on the process
>         of
>         porting DDD to Gtk - or more precisely the C++ binding
>         thereof,
>         Gtkmm. I notice this question comes up from time to time on
>         the
>         mailing list, but it is a daunting prospect and no-one seems
>         to
>         have grasped the nettle yet. Since I have some experience of
>         both
>         Motif and Gtk, and have ported a small application between
>         these in
>         the past, I felt I should try to start a project to do just
>         that. 
> Excellent! 
>         This work is at a very preliminary stage - I haven't even got
>         the 
>         first version to compile yet. However, some code will be
>         available
>         soon, I promise ;-) 
> OK. 
>         I'm not underestimating the difficulty of this task. At the
>         moment,
>         I am just running through the code, porting the obvious stuff
>         and
>         deferring the tricky (and less important) stuff until I have a
>         working
>         demo. The final code should have a compile-time switch which
>         will 
>         revert to a full-featured Motif version. The approach I am
>         taking is
>         this:
>         (1) Use a compile-time preprocessor macro, IF_MOTIF.
>         (2) Comment out all the Motif, Xt Intrinsics and standard X11
>             include directives thus: 
>            #ifdef IF_MOTIF
>            #include <Xm/...>
>            ...
>            #endif // IF_MOTIF
>         (3) Try to compile - of course the code breaks.
>         (4) Step through the errors: these are all the Xm, Xt and
>         standard
>             X calls; fix each of these in turn (a long job, still
>         ongoing). 
>         (5) All files which included <X11/*>, <Xm/*> now also include
>         asince t
>             "gtk_wrapper.h". This is an abstraction layer. This
>         contains
>             a big preprocessor conditional
>            #ifdef IF_MOTIF 
>            ...
>            #else
>            ...
>            #endif // IF_MOTIF
>         (6) In some cases the equivalences are easily dealt with in
>         the short
>             term by typedefs or macros, where there is a 1-1
>         correspondence
>             between the concepts in Motif and Gtkmm: 
>             typedef Gtk::Widget *Widget;
>             #define XtPopdown(w) (w)->hide()
>         (7) In other cases I have put #ifdef...#else...#endif
>         conditionals. When
>             we have created a prototype we can go back and look though
>         these to 
>             identify the requirements for a portability layer. I hope
>         that in
>             future this could accommodate QT as well (although I have
>         no
>             experience of QT programming). There are a a very limited
>         number
>             of Motif idioms in DDD, which gives me some hope that the
>         task 
>             is not impossible. The main difference is the XtCallback
>         mechanism
>             versus the signal-slot stuff, but there seems to be a
>         natural
>             mapping for most of this.
>             My own feeling is that the most elegant solution would be
>         to 
>             wrap the required parts of Motif (not all of it) in an
>             object-oriented layer like Gtkmm, with
>         constructors/destructors
>             and a signal-slot paradigm such as provided by libsigc++.
>             The result would look a lot more like pure Gtkmm but
>         would 
>             still provide Motif as an alternative backend (Xmmm,
>         perhaps?).
>         I'm still looking at this and hope to post some sample code in
>         the
>         next few months. 
> I guess the #define method is the simplest approach.  However, 
> you'll lose the OO-nature of gtkmm in the process.  As you've
> probably seen by now, much of the DDD source is littered with
> Motif function calls.
> I agree that the neatest way to do this would be to make a GUI 
> layer, separating the debugging logic from the display logic.
> Then it would be a lot easier to swap from one widget set to
> another.  This may be more work than you want, though!
> Keep us posted, and if you'd like CVS access, just ask. 
> Andrew. 

I now have a prototype. I can load an executable and grab
a screenshot:


The patch http://www.ceiriog.eclipse.co.uk/ddd-3.3.11-gtk.patch
is presently littered with IF_MOTIF conditionals. These can
be eliminated progressively if we introduce a proper abstraction
layer for the toolkit.
I think I have slightly broken the Motif version, but I should be
able to restore it easily so that it will compile the Motif or GTK
version according to the "--with-gtk" configure option.

I'd be happy to create a new CVS branch for this if you are


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]