Summary: | khexedit does not handle .hex or .s19 files | ||
---|---|---|---|
Product: | [Applications] okteta | Reporter: | Frieder Ferlemann <frieder.ferlemann> |
Component: | general | Assignee: | Friedrich W. H. Kossebau <kossebau> |
Status: | ASSIGNED --- | ||
Severity: | wishlist | CC: | kossebau, oo.o+kde |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Frieder Ferlemann
2004-12-04 01:51:48 UTC
Hi, I am planning to give the new KHexEdit2 the ability to work with non-continous areas of byte streams. But I am curious how I should design the UI. Could you all please tell me perhaps about existing techniques or how your dream UI would look like? I took a look at srecord and plan to use it as the information source to create the firmware import/export plugins so hopefully I can support all the formats srecord knows about :) Thanks in advance Friedrich PS: If you help me fast enough I might be able to do it for KDE 3.4 :) Hi Friedrich, sorry for the very late response (I don't think the request has lost relevance though:^) > But I am curious how I should design the UI. I'd be fine if undefined regions (here 0x100 to 0x3ff) were shown as: 0000:00e0 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 0000:00f0 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 0000:0100 ?? 0000:0400 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef For the file open/save (or import/export) dialogs there could be two options "load/save from 0xYYYYYY .. 0xZZZZZZ" and "load/save with offset 0x0123". If a file is imported "on top" of another one it is very handy to have highlighted those locations which are newly imported (italics/colors/background). Yet another highlight mode where the newly imported file (or the user) specifies a different content for the same location. > how your dream UI would look like? I'd be very happy if the ideas above would be implemented and think this "would just do". (More ideas are probably near to: http://en.wikipedia.org/wiki/Comparison_of_hex_editors) > so hopefully I can support all the formats srecord knows about :) Intel Hex and Motorola S19 will probably account for more than 95% of the uses. Intentionally restricting to these two would probably be a good idea as users of less widely used formats are very likely to have conversion tools at hand. Thanks, Frieder KhexEdit is now flagged as unmaintained. Okteta replaces it. Closing this bug report. Okteta in trunk (what will become KDE SC 4.5) just received a very initial step into the support of this: a streamencoder to the S-Record format (as used by Export/Copy As). Intel hex is next to come. No idea yet when/if I will do support loading/importing. Supporting undefined regions and marking changes (e.g. by overloading on-top) needs some bigger works in the base models. Can Okteta now work with non-continous areas of bytes? I have seen that there is inital support for exporting ihex. Where would be a decoder for that/those formats be implemented? In the libkasten? Thanks for your work Hi NooN, no, sadly still no support for non-continous areas of bytes (oha, >10 years already old, time flies). I would be happy if you could add your ideas for your related dream UI and workflows you would like to see supported here for now, though. Currently I am working on some bigger restructuring of the Kasten framework. So while I have plans on more features for Okteta myself (incl. non-continuous data) which are also reconsidered in the restructuring, in the next months I will not work on them. The current Kasten has no infrastructure for the concept of loading files in multiple explicit formats, so besides needing a data model, a data view/editor for non-continous areas and decoders for .hex/.s19/etc. formats, it will also need rewiring of loading & saving infrastructure. So its not simply done by a few more plugins right now. But the current restructuring is done with that in mind, so hopefully it will then be just a matter of more plugins, After all that's the idea of a framework. Blocking new features for some time is the disadvantage of creating in general-purpose framework in parallel, instead of just doing what is needed for a hex editor :) |