[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Hex editor widget
From:       "Friedrich W. H.  Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2003-06-22 1:38:00
[Download RAW message or body]

Am Sonntag, 22. Juni 2003 00:59 schrieb Russell Miller:
> On Sat, Jun 21, 2003 at 12:52:19PM +0200, Friedrich W. H.  Kossebau wrote:
> > Am Samstag, 21. Juni 2003 00:45 schrieb Russell Miller:
> > As much as I understand: Prepared.
> > (what is the meaning of arbitrary in this context? My dictionary didn't
> > help me to get a feeling for it.)
>
> In this context, arbitrary means - that it doesn't care which pointer you
> use, it can be very large or very small, and even a void *.  It just turns
> it into its binary representation.

Okay. My idea of a hex view is that all the data is abstract seen as a string 
of bytes of any length. So the hex editor is mainly a byte editor with the 
additional possibility to edit each byte by its digit representation (of a 
given kind: hexadecimal, decimal, octal, and binary (any other?)). So - think 
this fulfills your request, right?

<snip>
> > Has to be handled by the app (or do you expect the widget to scan the
> > data over and over?;).  A slot "void updateRange( int index1, int
> > index2);" should serve on the widget's side.
> >
> > Oh wait: Are you thinking not of a data range viewer but a simple
> > one-byte edit widget? Hm. Might be usefull, to. Will put this on my TODO
> > list. Should be doable. The basics are the same as for the range hex
> > edit. Might be already implemented in today's KHexEdit.
>
> I think we may be having communication problems here, but if I understand
> you - both.

So let's try another language: please offer some (ascii)-drawing of what you 
think exactly. I guess the range editor is clear - like KHexEdit. But how 
exactly would the other look like?

> I have yet another possible request.  Perhaps the ability to call a slot
> that forces the widget to focus on the beginning of a range of data,
> highlighting it, and the highlighting continuing to the end of the range of
> data?  I can see how this could be useful in kbview.  I could have a list
> view of items in a strtab section, and as you click on them it highlights
> that information in the widget.  But not just strtab, also symbol...

I think the less slots the better (at least for the basic widget). If you 
really want some slot, you can still then subclass the widget and add the app 
specific needs. Or have the slot in another class that has access to the 
widget. The code would perhaps be as simple as:

  HexView->setSelection( int i1, int i2);
  HexView->ensureSelectionVisible();

But selections is what I am right now trying to design. 

> That's not really overly important, though.  Just nice to have.

Well, this will be a quite easy solved problem :)

Friedrich
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]