Author Topic: Show debugging information on hover  (Read 26871 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Show debugging information on hover
« Reply #15 on: May 08, 2010, 02:45:53 am »
Try Enlightenment DR17 and it will have border :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline shirsoft

  • Single posting newcomer
  • *
  • Posts: 9
Re: Show debugging information on hover
« Reply #16 on: May 09, 2010, 11:21:02 am »
How about wxFrame? I seem to be able to get rid of the frame.
Is wxFrame generic enough to show similar behavior on other OS's too?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Show debugging information on hover
« Reply #17 on: May 09, 2010, 01:09:53 pm »
Commit your changes to googlecode and I can test them...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Re: Show debugging information on hover
« Reply #18 on: August 19, 2010, 03:19:27 pm »
Morten/obfus/others,

Anybody still working on this?  If not, I may explore it some.  (I might anyway, while awaiting a reply.)


Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Show debugging information on hover
« Reply #19 on: August 19, 2010, 03:27:01 pm »
I'm not working on it...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Re: Show debugging information on hover
« Reply #20 on: August 21, 2010, 05:58:11 am »
Anybody want to give this a try?  (windows only tried thus far by me)

Its progressively based on shirsoft's code (hence is just a DEMO, not integrated into codeblocks), and contains a lot of junk that shows or at least hints at the variations I went through to arrive at what's here.  Not perfect, but I think better than when I started.  Mouse hover over the '+' will open descendants - leaving current will generally close it if it has no descendants.  To close cleanly, each descendant must be exited thru its ancestor, or a return to current top then leaving must be repeated for each level.  Once the user is trained, it works great ;).

Feature still lacking is some means of adding a scroll bar when the number of items for a given entity "level" won't fit on screen.  (Don't know if horizontal scroll might also eventually be needed due to excessive length of any single item.)  Since the existing release implementation doesn't seem to allow for such vertical scrolling I don't feel too bad about that yet.


Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Show debugging information on hover
« Reply #21 on: August 21, 2010, 12:02:15 pm »
Looks good, no border on E17 which is great :)

There are some bugs:
1. When I hover over + for the sph entry the second level opens, then I hover over the second level and then move my mouse out of both levels, the result is that only the second level is closed.
2. You can show the second level when the first level is closed.

Looking at the code the positions of the windows are calculated in advance, but I think the should be calculated when the level is about to be shown.
Also this control should support scrolling: http://farm1.static.flickr.com/174/416944134_f4d123e9bc_o.png
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Re: Show debugging information on hover
« Reply #22 on: August 22, 2010, 08:16:56 pm »
1)Since its apparently too hard to train my users, here's an attempt that may require less training.

2)Do you know what the control is in that image?  Is that an image of a wxwidets application? Or were just suggesting that an effort should be made to create a control that resembles that image?


Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Show debugging information on hover
« Reply #23 on: August 22, 2010, 08:37:23 pm »
2)Do you know what the control is in that image?  Is that an image of a wxwidets application? Or were just suggesting that an effort should be made to create a control that resembles that image?
Hm, it seems that you haven't used Visual Studio >=2005.
The screenshot is from their implementation of the Debug hover window and I suppose it is done with win32 api only (another possibility is .net but I doubt).

p.s. will test the new version in a minute...

Edit:
Now it is way better than before, it is closing a bit too fast when the mouse leaves the window, but this should be fixable with some tweaking.
Can you implement the scrolling behaviour?
« Last Edit: August 22, 2010, 08:43:32 pm by oBFusCATed »
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Re: Show debugging information on hover
« Reply #24 on: September 07, 2010, 09:05:10 pm »
FWIW,

soso news
I have implemented rudimentary scrolling, and I have it integrated into (checkout of) CB wxpropgrid_debugger branch, using the GDBWatch entities.  (I didn't actually get scrolling implemented in the demo, because it was going to require too much throw away framework for data structures, since a specific one was going to need to be supported.  Hence the move to integration into CB branch.)

bad news
It doesn't work nearly as smoothly integrated into the whole as it seemed to in the much smaller demo program, even after a number of "hacks" attempting to address the various visual, and some not-so-visual, issues I have encountered.

(obfuscated, others) Do you want me to bother attempting to post a patch in its current state.  (The code is quite dirty at the moment, as it has my "running history" of the various things I've tried.  It only contains code added to gdb_tipwindow.<cpp,h>, (all classes lifted from the demo, not mods to existing tipwindow stuff), and slight change to gdb_commands.h to invoke it. [well, excepting all the update.bat files that are not winxp sp2 compatible, at least in terms of line-endings, that I changed when I originally obtained and built the branch])

I am currently a bit frustrated, but have not yet given up entirely.  I'm not sure when that might change, based on available resources and other priorities.

ps - it currently does have borders around the frames, as with default (editor) colors on my winxp mach, it was very hard to see without them.  This is currently a minor difference of a flag passed to the underlying frame-descendant constructors.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Show debugging information on hover
« Reply #25 on: September 09, 2010, 09:32:39 pm »
Post your patch, more eyes see better :)
If you can clean your patch it will be great, if not so be it:)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Re: Show debugging information on hover
« Reply #26 on: September 17, 2010, 08:26:50 pm »
current experimental development patch against svn 6604, wxpropgrid_debugger branch.

[edit: note, I had to modify eol properties to get svn to diff it... I don't know what implications are of that for applying this.]

obfusc, have a look when you can.  This may be closer to a starting point than I was before.  The approach is somewhat modified as to point in hierarchy where timer is managed from original demo (and my original point of major frustration.) On (MSW) wxwidgets, I have a timer that seems to be stopping of its own accord (which led me to the gdb/c::b file/path issues noted elsewhere), which I think I've currently hacked around, but would like to find as it may be either a wxwidgets or codeblocks issue of some sort.  Remember, there are borders currently, there's two lines in tipwindow.h that can be swapped, borders are a difference of (currently) a compilation flag.  Number of rows displayed is currently "default"ed to two (plus possible scroll items), but that is constructor value also (envision something like 10 maybe being a medium, maybe user should eventually be allowed some flexibility to choose within limits.) And code is cleaner than when I posted before, but still very much experimental with some retained "history".

Data display is not good, just whatever default comes in GDBValue, which seems a little strange particularly for array of char (don't seem to be any children for array of char.) At any rate, data value display/editing could benefit from a lot of add'l work.  Width of displayed items prob. will require changes too, some adjustment made relative to entity names, but not for data values.

Also can envision desireable possibility of "tack"ing items so that several might be brought up quickly and held, rather than just current single.  (I personally have never faired too well using the "watch" window functionality in debuggers.)

A "history" snapshot/logging function might be pleasant to have as well.  (Until some of this effort I wasn't aware of gdb's "history" value retention from print.)

And I can imagine a little more as well.  (Such as something along the lines of what I think gdb's "watchpoints" can accomplish, breaking briefly to report some state and then continuing - but that's not really part of tips.)

But, I guess the base needs to be there first...
« Last Edit: September 17, 2010, 08:44:32 pm by cbexaminr »