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

List:       wireshark-dev
Subject:    Re: [Wireshark-dev] Custom widget for packet bytes
From:       Jakub Zawadzki <darkjames-ws () darkjames ! pl>
Date:       2012-06-18 22:17:43
Message-ID: 20120618221743.GB20581 () darkjames ! pl
[Download RAW message or body]

On Sat, Jun 16, 2012 at 06:03:09PM -0700, Guy Harris wrote:
> On Jun 15, 2012, at 2:22 PM, Jakub Zawadzki wrote:
> 
> > I'm in the process of writting custom widget for packet bytes (hex/bits).
> 
> Presumably it'll be "lazy" and not require that the entire hex/ASCII dump be \
> formatted before it can be displayed?  

Yes, maybe it'll have some cache of currently visible lines, but right now it looks \
like that whole content can be  generated on fly.

> For a really big reassembled packet formatting the hex dump can take a while.

Right now I'm testing it on 2 MB XML files.

> > - No horizontal scrolling. Do we need it? For really small screens with big \
> > fonts?
> 
> Horizontal scrolling support is probably not a bad idea, just in case the user \
> shrinks the window for some reason, 

As a workaround I could opaque it in GtkViewport. Generally scrolling is fast when \
you assume  that font characters has the same width. When it's true it's easy to \
calculate how many characters skip in rendering. In Wireshark default is Monospace, \
and it'd be strange if someone use proportional font for hexdump...  

But I'd rather format less bytes of data. When 16 bytes don't fit the screen, use 8, \
4, ... It could be also used in opposite direction, in full screen we could format 32 \
bytes of data  instead of just 16.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe


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