Review Request: Memory viewer fixes.

[Friedrich W. H. Kossebau]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104574/#review12402
-----------------------------------------------------------


Never seen this code before, so can only comment from how the KHexEdit interface is used on the quick look I gave. Nothing really bad seen here :)


debuggers/gdb/memviewdlg.cpp
<http://git.reviewboard.kde.org/r/104574/#comment9713>

    In general I wonder if it might make sense to switch from using the KHexEdit interfaces and a run-time dependency on effectively the Okteta libs to using the Okteta libs directly and a build-time dependency on them.
    After all there is already a build-time dependency on the Okteta libs, for the Okteta plugin to allow raw-editing of files.
    
    Having direct access to the richer interfaces of the Okteta libs could perhaps enable things that might have been blocked before.
    
    See http://api.kde.org/4.8-api/kdesdk-apidocs/okteta/html/namespaceOkteta.html (and ignore all the classes in the namespace Kasten* , only useful if using the Kasten framework. Okteta:: is yours for just the Okteta libs). You would ideally subclass the Okteta::AbstractByteArrayModel to provide a model of the memory you want to display/edit. Or just reuse of one the existing and stuff it with the data.
    
    Just food for thoughts for future development :)



debuggers/gdb/memviewdlg.cpp
<http://git.reviewboard.kde.org/r/104574/#comment9715>

    These two lines are contradicting.
    
    It should be decided to either set the widget to a fixed number of bytes per line or to have the widget put as many bytes on a line as possible with the current widget width.



debuggers/gdb/memviewdlg.cpp
<http://git.reviewboard.kde.org/r/104574/#comment9714>

    Could get a comment what this line tries to do, i.e. to prevent access to the data that is deleted on the next line.
    Because on a first look I was puzzled that after the next line this->data_ is no longer existing :)


- Friedrich W. H. Kossebau


On April 13, 2012, 12:19 a.m., Ben Wagner wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104574/
> -----------------------------------------------------------
> 
> (Updated April 13, 2012, 12:19 a.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Description
> -------
> 
> This is a somewhat odd patch, since it changes what is currently dead code. However, uncommenting the relevant portions of debuggerplugin.* and CMakeLists in debuggers/gdb allows it to be used. This change makes the memory viewer at least work and not crash, which is an improvement over the existing state. This code needs more work before being re-enabled, as does the code which calls it (it is rather strange the way it's UI is set up). However, this is a good checkpoint.
> 
> 
> Diffs
> -----
> 
>   debuggers/gdb/memviewdlg.h 1629cd0 
>   debuggers/gdb/memviewdlg.cpp 0500a21 
> 
> Diff: http://git.reviewboard.kde.org/r/104574/diff/
> 
> 
> Testing
> -------
> 
> Got it working. Used it. When Okteta is installed it works and I haven't gotten it to crash again yet.
> 
> 
> Thanks,
> 
> Ben Wagner
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120413/71e43b80/attachment.html>