Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] corrected graphing patch

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Pavel Mores <pvl@xxxxx>
Date: Mon, 19 Mar 2001 10:04:40 +0100
On Thu, Mar 08, 2001 at 01:34:12AM -0800, Guy Harris wrote:

> On Tue, Feb 27, 2001 at 09:01:56PM +0100, Pavel Mores wrote:
> > Oh, I'm sorry. I'll port it to 0.8.15.
> 
> Why does the left mouse button move the graph rather than selecting a
> packet?  The left mouse button tends to mean "select" in most GUIs (at
> least on systems with mice with more than one button... :-)).

There's no particular reason for this. So far I wanted to focus on
"backend" work and leave ergonomy of the GUI for later stages of
development.

So your suggestion is the left button selects, the middle button zooms
and right button moves? I don't know, I thought I would leave these
decisions up to the users.

One thing that bugs me is that the select function currently uses a
quite naive algorithm for collision detection. The result is that it
could be quite hard to hit the segment you want to select, especially
when it is represented by (just one pixel wide) lines. I'm afraid that
if I put select on left mouse button it could seem to a casual user that
lmb does nothing.

The right solution would be to come up with a better collision
detection. Unfortunatelly, I can't think of one.

> You might want to avoid using bitfields in headers that are supposed to
> match packet headers; for one thing, you'd have to do something such as
> what the BSD header files do:
> 
> 	#if BYTE_ORDER == LITTLE_ENDIAN
> 		u_int	ip_hl:4,		/* header length */
> 			ip_v:4;			/* version */
> 	#endif
> 	#if BYTE_ORDER == BIG_ENDIAN
> 		u_int	ip_v:4,			/* version */
> 			ip_hl:4;		/* header length */
> 	#endif
> 
> in order to handle both big-endian and little-endian machines, and, even
> then, there's no *guarantee* that the bit fields will be put into the
> header in the obvious order, as I remember.
> 
> (There might also be compilers that would object to
> 
> 	guint16 doff:4;
> 
> for example, as that'd declare a bitfield that's an "unsigned short",
> although I don't have my ANSI C standard handy and don't know whether
> ANSI C specifically allows "unsigned short" rather than "unsigned int"
> bitfields.)
> 
> Using bitmasks and shifts might be better.

OK. I will try to correct this.

	pvl