Splitting debugger in two - specific debugger and common GUI

[m.29]

Thanks for fixes, but after new commits I get SIGSEGV when I close Code::Blocks. It breaks in debuggermenu.cpp on line 199. Here is my debug log.

Code Select Expand

Building to ensure sources are up-to-date
Selecting target:
src
Adding source dir: C:\proj1\clean_cb\src\
Adding source dir: C:\proj1\clean_cb\src\
Adding file: C:\proj1\clean_cb\src\devel\codeblocks.exe
Changing directory to: C:/proj1/clean_cb/src/devel
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.8
Child process PID: 992
At C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
Continuing...
At C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
Continuing...
At C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
Program received signal SIGSEGV, Segmentation fault.
In wxMenuItem::Check () (C:\unix\wxWidgets-2.8.11\lib\gcc_dll\wxmsw28u_gcc_custom.dll)
#1  0x00cf4e9d in DebuggerMenuHandler::RebuildActiveDebuggersMenu (this=0x48401e0) at C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199:8979:beg:0xcf4e9d
At C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
#1  0x00cf4e9d in DebuggerMenuHandler::RebuildActiveDebuggersMenu (this=0x48401e0) at C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199:8979:beg:0xcf4e9d
Continuing...
Program received signal SIGSEGV, Segmentation fault.
In wxMenuItem::Check () (C:\unix\wxWidgets-2.8.11\lib\gcc_dll\wxmsw28u_gcc_custom.dll)
#1  0x00cf4e9d in DebuggerMenuHandler::RebuildActiveDebuggersMenu (this=0x48401e0) at C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199:8979:beg:0xcf4e9d
At C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
#1  0x00cf4e9d in DebuggerMenuHandler::RebuildActiveDebuggersMenu (this=0x48401e0) at C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199:8979:beg:0xcf4e9d
Continuing...
Program exited with code 030000000005.
Debugger finished with status 0


[oBFusCATed]

Hm, pretty strange...
Unfortunately the menus behave differently on windows and at the moment I'm investigating a ::Check related problem.
For some reason calling wxMenu::Check() can fail and the result is that there is no active debugger selected.

If you need to do some real work on C::B please revert to r7086, until I fix the problem or if you can track it, the better

[oBFusCATed]

m.29:
I've committed a fix for the menu handling, can you try it?
If it crashes again please provide the full steps needed to reproduce it.

[m.29]

Sorry for my late answer - busy day today. I tried it and it seems to be all right. Great work :-)

[m.29]

Some new bug in r7121 :-( I just open Code::Blocks then select Settings -> Debugger... and C::B crash on line 97 in file debuggeroptionsdlg.cpp.

[oBFusCATed]

Execute src/update or src/update.bat depending on your OS...

[xhpohanka]

Hello, work on the debugger GUI is promising, but I'd like to ask you - is there a possibility to simply delete or rename a watched variable? I mean by pressing del, or f2 to rename or something similar, not only using context menu. Also I'm lacking the possibility of changing the format (decimal, hex, unsigned, ...) for member variables in expanded structure or class.

Nevertheless the new GUI works really well... Thank you.

[oBFusCATed]

Yes, use linux  :lol: (the buttons are delete and insert)
Something is happening on windows and the shortcuts doesn't work.
I've to investigate why. It is on the TODO list.

[oBFusCATed]

dmoore:
Do you think to work on your debugger plugin soon?
I've tried it bug it failed to compile. I've fixed the compilation (I can provide the patch if you're interested),
but it crashed C::B (should fix the API a bit, but this will be done later), because the new configuration staff is missing.

p.s. have you though of using wxSmith for the GUI? If you use wxSmith it will be easier for others to modify your GUIs, and contribute:)

[cbexaminr]

(items quoted were posted almost 3 months ago back on page 28 of thread)
1of3)Morten, regarding

However, as a compromise how about applying it for a nightly to give a chance to other users to try. If the community benefits from it we can polish out the ToDo's. But this should clearly be done in a continuous work.

My patch does not appear to have been applied to any nightly.  Oversight on my part, or current plans concerning this?

2of3)oBFusCATed , regarding

This one requires major refactoring. If it doesn't bother you, use your version for now. I'll give it a try myself next week, I think I'll have a bit of free time.

Any progress I've overlooked on this refactoring, or if not, a timeline yet when this might be sufficiently complete to host my previously submitted functionality in a form acceptable to you?

3of3)oBFusCATed /Others, the crash possible in Attach to process previously introduced with earlier cdb support related patches does not seem to have been corrected (outside of the not yet accepted/applied patch [with other functionality] I previously submitted.)

[oBFusCATed]

Can you state the name of the patches (or direct links to the posts)?

3of3)oBFusCATed /Others, the crash possible in Attach to process previously introduced with earlier cdb support related patches does not seem to have been corrected (outside of the not yet accepted/applied patch [with other functionality] I previously submitted.)

I've missed this, this could be applied (faster) if you supply a separate patch...(and steps to reproduce the crashes)

BTW Your tooltips patch won't be applied, because it is broken badly on my linux (gentoo + e17). It is pretty complex in its mouse handing/interactions, so it will be hard to maintain.
I've started separate implementation using wxPopupTransientWindow and wxPropertyGrid.

[cbexaminr]

Can you state the name of the patches (or direct links to the posts)?

dbgextprocess.2b.patch
http://forums.next.codeblocks.org/index.php/topic,10908.msg95323.html#msg95323
I believe the fix for the issue was merely to make sure m_Target is not NULL before attempting to use to check for ttConsoleOnly.

3of3)oBFusCATed /Others, the crash possible in Attach to process previously introduced with earlier cdb support related patches does not seem to have been corrected (outside of the not yet accepted/applied patch [with other functionality] I previously submitted.)

I've missed this, this could be applied (faster) if you supply a separate patch...(and steps to reproduce the crashes)

I believe you merely had to start codeblocks without opening a project and then perform an Attach to process.

BTW Your tooltips patch won't be applied, because it is broken badly on my linux (gentoo + e17). It is pretty complex in its mouse handing/interactions, so it will be hard to maintain.

OK.  
("broken" I accept as reason not to aply.  
Complex to maintain I don't accept, unless a)it can be reasonably speculated that some desired functionality will likely have to be added, or, b)that the functiionality it provides is not useful and desireable, or c)that there is a simpler way to accomplish the same functionality without the complexity, or d)it makes use of wxwidgets features that are known to be platform inconsistent, or unstable or likely to change [possibly the situation if it is "broken" on linux].

Further, it was merely intended as a prototype, not necessarily to be applied in its current state - all of that code was exploratory, with regard to the windows without borders on both Windows and Linux and possibly other issues I don't recall at this point)

I've started separate implementation using wxPopupTransientWindow and wxPropertyGrid.

OK.

[oBFusCATed]

I believe the fix for the issue was merely to make sure m_Target is not NULL before attempting to use to check for ttConsoleOnly.

Can you check it, again?

dbgextprocess.2b.patch

I can't give you a time frame for the refactoring. At the moment I'm working on tooltips, as they have more impact on users and plugin writers.

OK. 
("broken" I accept as reason not to aply. 
Complex to maintain I don't accept, unless a)it can be reasonably speculated that some desired functionality will likely have to be added, or, b)that the functiionality it provides is not useful and desireable, or c)that there is a simpler way to accomplish the same functionality without the complexity, or d)it makes use of wxwidgets features that are known to be platform inconsistent, or unstable or likely to change [possibly the situation if it is "broken" on linux].

Further, it was merely intended as a prototype, not necessarily to be applied in its current state - all of that code was exploratory, with regard to the windows without borders on both Windows and Linux and possibly other issues I don't recall at this point)

The thing is that it does many complex things with windows. It needs borderless windows, it needs correctly working hovering.
And implementing this on all platforms will be hard and will increase the maintenance cost.
I'll see if my approach will be simpler. It will be something like this: http://monodevelop.com/@api/deki/files/286/=md24-PinnedDebugValues.png

[oBFusCATed]

OK, I've done some work on the tooltips and there are some problems

The main problem is that the keyboard input inside wxPopupWindow is very buggy or it even doesn't work (on wxMSW).  :evil: :twisted: :cry: :?: :|  :x :shock: :?

The simplest solution is to surrender and make the tooltips read-only. Not a good solution from the usability point of view.
Has anyone done any complex tooltips using wxWidgets?

I'll post a patch with read-only tooltips later today...

[oBFusCATed]

Ok, I have the patch for the tooltips almost ready: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0022.3.patch

Please test it. I'm using it every day on my linux, but have done very little testing on windows, so feedback is welcome.

Changes:
- Added API for showing value tooltips from debugger plugins
- Added implementation of the tooltip using wxPropertyGrid
- Imported std::tr1::shared_ptr in namespace cb, replaced all usages of std::tr1::shared_ptr with cb::shared_ptr (this should make it very easy to change the shader_ptr implementation)
- Some of the functions have been changed to return or take cbWatch::Pointer instead of raw pointers (all should be changed, but this will be done later)
- Added 'Require Ctrl key to be pressed to show the Value tooltip'
- Changed wxPropertyGrid to support the autosizing (logged issue request upstream)
- Added code to correctly hide the CC tooltips
- Some refactoring here and there.

Feedback please...
If there are no reports for problems, I'll commit in the next couple of weeks...