Version: (using Devel) Installed from: Compiled sources A hex memory view would be a nice thing to have for embedded systems / certain algorithms that deal with data files. okteta already provides a very decent hex view, I wonder if that could be reused/integrated through a kdevelop plugin.
Hint for kdevelop developers: there's the KHexEdit interface in kdelibs.
just a short note: To edit files with a hexeditor there's not much to do, just associate the filetype with okteta and then the okteta kpart should load in kdevelop. Its a bit more involved for the memory viewer thats used while debugging an app.
See http://frinring.wordpress.com/2009/07/24/shorttip-viewing-raw-data-of-files-in-konquerorkdevelop/ for a short tutorial how to at least view files with Okteta. A Readwrite-KPart of Okteta hopefully will be done for KDE 4.4, but do not hold your breath, please.
I believe that in KDevelop3 times, I have raised some concerns about KHexEdit interfaces. In particular, it did not support arbitrary grouping of bytes -- so that one could view a memory area as either sequence of 16-bit things or 32-bit things, or 64-bit things. It also had annoying issue in that the ascii view used fancy colors for characters depending on whether character is printable. Users found that confusing and it was not possible to turn that off. Also, there was no interface for incremental fetch of memory. I do not know if those problems are fixed in KDE4. If not, it might be best to implement a quick-n-dirty memory viewer ourselfs.
Hi Vladimir, Some of your concerns are still valid, and also present in my plans for future development of the Okteta libs (from the KDE Hex Editor Okteta in kdeutils). But forget about the KHexEdit interfaces, better develop directly using the Okteta libs. Their headers were supposed to be installed for SC 4.4, but with no feedback I pulled this recently. Will reconsider for 4.5, if there is serious interest and cooperation. Multi-byte views should be doable for 4.5: With the AbstractByteArrayModel you can subclass and can do the incremental memory fetching/watching yourself already now. Coloring can be switched-off already, too. With the recent work on Write support in the Decoding Table tool, multi-byte support in the main view has received some more foundation. So if a dependency on Okteta of SC 4.5 next summer does it for you, please get in contact :) You can try things yourself in trunk a little, just uncomment the header install instructions in KDE/kdeutils/okteta/{core,gui,includes,designer} and see in designer/examples for some starting code.
(In reply to comment #5) > So if a dependency on Okteta of SC 4.5 next summer does it for you, please get > in contact As Release Coordinator for kdevelop I'm chiming in here to let both of you know that now that we're in extragear depending on any other trunk/KDE module is not a problem. Though this particular dependency on SC 4.5 would have to wait for KDevelop4.1 as 4.0 cannot change its requirement to anything unreleased (and we'll be releasing before 4.5). Andreas
any news on this now that okteta plugin is part of 4.1?
If it's just about loading arbitrary files (which fit completely in memory, deficit in Okteta still), than this bug report could be closed as RESOLVED. (Besides the fancy colors, format highlighting is not yet done to replace this) But as this wish is filed for the debugger component, I expect the wish reporter to be looking after viewing/editing of the working memory of a running process. This is not what the Okteta plugin provides currently.
Git commit a5dc55770165d2ab0a0cec6660cbad1b5d1cf61f by Niko Sams, on behalf of Ben Wagner. Committed on 08/02/2013 at 00:00. Pushed by nsams into branch 'master'. Improve and re-enable memory tool view. REVIEW: 104574 Related: bug 256044 M +1 -1 debuggers/gdb/CMakeLists.txt M +5 -20 debuggers/gdb/debuggerplugin.cpp M +2 -4 debuggers/gdb/debuggerplugin.h M +218 -200 debuggers/gdb/memviewdlg.cpp M +9 -13 debuggers/gdb/memviewdlg.h http://commits.kde.org/kdevelop/a5dc55770165d2ab0a0cec6660cbad1b5d1cf61f