Re: RFC: Porting DDD to Gtk(mm)

Hi Peter,

On 7/1/06, Peter Wainwright <[email protected]> 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.

_______________________________________________
Ddd mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/ddd