ddd
[Top][All Lists]
Advanced

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

Re: RFC: Porting DDD to Gtk(mm)


From: Andrew Gaylard
Subject: Re: RFC: Porting DDD to Gtk(mm)
Date: Tue, 4 Jul 2006 12:18:34 +0200

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.

reply via email to

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