Reply to post: Re: lack of good tools for GUI development

You GNOME it: Windows and Apple devs get a compelling reason to turn to Linux

bombastic bob Silver badge

Re: lack of good tools for GUI development

"The Visual Studio debugger is light years ahead of GDB in every way possible. And has been for decades."

not really. gdb was intended to have a wrapper around it, as I understand. It's a lot like the old codeview application, but simpler. Also similar to the way kernel debugging works, for those of us who've done that.

DevStudio's debugging interface isn't any better than 'ddd' as far as I am concerned. In fact, I think it's HARDER to use DevStudio nowadays (compared to '98 which was probably the BEST version for people who like to type and not mousie-clickie every damn thing), with the way the hotkeys and toolbars and displayed source files have been screwed all to hell (as far as I can tell, anyway). It was MUCH easier (and saner) in "the old days".

If you've ever used 'ddd' (a GUI wrapper around gdb) you'll see an example of GUI integration around gdb, which is as good as anything else as far as I'm concerned.

Where 'ddd' falls apart is when you set a breakpoint during event handling from X11 from within the SAME desktop as the process being debugged. Basically there's a lock on the X server so everything freezes up due to the 'deadlock'.

So, there are 2 basic solutions to that: a) use a separate desktop (which I already do) for the debugging session, and b) fix the interface (i.e. re-write your own gdb wrapper) so that it unlocks the X server across debug breakpoints. Managing the 2nd option may require some clever hacking. But I intend to give it a good try anyway.

The X11 library has a locking mechanism for multiple threads accessing the X server, mainly XLockDisplay() and XUnlockDisplay() (if you initialize it for threaded behavior; I keep the events in the main thread to avoid problems). Additionally, you can lock/unlock the server itself via XLockServer and XUnlockServer (you sometimes need to do this with certain operations, like mouse-dragging). These may be implicit with certain kinds of X11 library calls and event handling itself. So if I spend some time digging through the X11 library I bet I'll find something _like_ this being used during event processing, locking the X server (or the library) for concurrency reasons. I would then intercept that when I hit a breakpoint, shut it off while in the debugger GUI, and re-do the state prior to returning to the program.

So yeah once that's solved, everything's good again, you can debug in X11 and Micro-shaft can keep their bloatware developer studio and any incarnations they attempt to make runnable on Linux.

[and I doubt Wayland would "fix" anything, either - it would probably make things WORSE]

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019