As far as debugging on Linux is concerned one look at existing Linux (gui-enabled) debuggers is enough. All of those are written as GDB - front ends. And most of those use the GDB-mi interface. GDB is also available on windows. GDB supports most of what fbdebugger supports (eg setting breakpoints, getting the value of variables etc...). Writing a GDB front end (using gdb-mi) would be one way to create a cross - platform FreeBASIC debugger. Link to gdb-MI interface description https://sourceware.org/gdb/current/onli ... GDB_002fMI
I found a small 'bug' in fbdebugger version 2.81. (my source code compiled with -gen gas) ctrl - clicking on a variable can get you the message
Code: Select all
VARIABLE is not a running variable
even when VARIABLE is known to fbdebugger and is a running variable. The variable shows up in the right pane as a global variable which 'proves' that it's a running variable (otherwise it would not show up as a proc/var in the right pane).
The problem seems to be that the variable is used like so
and VARIABLE is declared in namespace (it's a global variable). VARIABLE might not be known as such but namespace.VARIABLE is known. As mentioned the variable does show up in the right pane. Searching the list of global variables might solve the problem. Something like (pseudo code)
Code: Select all
if variable is not a known running variable then
search list of global variables for variable
if found then variable is a running variable
As far as porting fbdebugger code to fltk goes: reuse of static components (eg 'look' of the debugger) seems like a good place to start. As far as the dynamic part of the gui goes: a lot of messages sent using SendMessage actually set some property of a widget. In fltk that can be done directly using the appropriate functions.
Message handling of buttons is easily replaced with button - specific callbacks. Actions performed when buttons are clicked can be copy-pasted to the button handler (handler code will need editing of course). Menu handling can largely be copied as is because fltk supports easy creation of menus. Again: actions associated when choosing a menu can be copy-pasted to the appropriate handler (some editing needed).
On the whole I think the porting issue isn't all that bad since gui creation in fbdebugger is handled by functions that somewhat 'wrap' the win32 api. Those wrapper functions can just as easily wrap the fltk api.
Personally I wonder whether it would not be a better idea to port fbdebugger to gtk+. It has a C interface so the bindings are easier to create/recreate/update. Using a wrapper around fltk you depend upon someone else to keep bindings to a C++ library up-to-date and working (which isn't all that easy).
How far are you with porting fbdebugger to fltk? Could I 'jump in' and finish the job? I'd prefer to start with a 'vanilla' version of fbdebugger (win32 api) though. My aim would be to make the gui work on both linux and windows. And to make sure the debugger part works on windows. The decision on how to achieve cross - platform debugging capabilities (either using gdb or otherwise) would not be an issue (the linux version will just consist of a gui without debugging capabilities). As far as gui toolkits go I'm fine with using either gtk+ or fltk.