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:
http://www.ceiriog.eclipse.co.uk/ddd-gtk.jpg
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
willing.
Peter
_______________________________________________
Ddd mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/ddd