Re: RFC: Porting DDD to Gtk(mm)
Peter Wainwright <[email protected]>
| Newsgroups | gmane.comp.debugging.ddd.general |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 2006-07-04 at 12:18 +0200, Andrew Gaylard wrote: > 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. > 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 [email protected] http://lists.gnu.org/mailman/listinfo/ddd
signature.asc
(application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBE+ej/ZlbFk+UVjRoRApW2AJ4tSJmu8Hfy6JKvwOMtt6itcRXsygCfUFEj C86/2xWMIOUWwS2MrzMkOQc= =G+6z -----END PGP SIGNATURE-----