Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 23560: /trunk/ /trunk/doc/: wireshar
On Tue, Nov 27, 2007 at 08:16:22AM +0100, Sake Blok wrote:
> On Tue, Nov 27, 2007 at 03:33:48AM +0100, Ulf Lamping wrote:
>
> > There are some other usability things that really needs to be solved:
> >
> > - if no capture file is loaded, both "View/Colorize Conversation" and
> > "View/Reset Coloring" are active and can be clicked - but nothing
> > happens. A usability "no go".
>
> Check, I will add sensitivity to these items.
Fixed in SVN 23654
> > - the main menu and the context menu have a different structure which is
> > a another "no go" IMHO. If it's not possible to have the "View/Colorize
> > Conversation" menu the same way than the context menu, it's probably
> > better to remove it completely from the main menu.
>
> The reasoning behind this is as follows: I wanted to have the same options
> in the context menu as the context menu "conversation filter", this gives
> the user full control over whether ethernet, ip, tcp or udp should be
> used as the conversation filter. For the hot-keys I needed something that
> would choose the upper-most layer as the conversation filter, as this is
> what would be used mostly (IMHO). I could make the context menu the same
> as the "View/Colorize Conversation" menu, but then I need to find a way
> to distinguish whether the user pressed a hot-key or used the menu-structure
> to keep the functionality of the hot-keys. Is something like that already
> been done somewhere within Wireshark?
After looking at the possibilities to change this I come to the following
conclusion:
I really like the conversation hotkeys, they make life a lot easier. I
think they should match a similar function in the main menu, so the
current implementation of the main menu for conversation coloring should
also stay.
That means the packet-list context menu should either
1) work the same way as the main-menu conversation coloring items (ie
dynamically choose which protocol to use for the conversation coloring)
However, that would break the similarity with the conversation filter
items in that context menu.
2) stay like this to give the user some flexibility and similarity
*within* one menu.
3) be deleted completely from the packet-list context menu to fix the
"usability-no-go".
4) use different labels, as the functionality of the packet-list context
menu is a little different from the functionality of the main-menu
items. But that might make things even more blurry actually.
So what do you all think would be the best way forward? I would vote
for 2 myself.
> > This applies as well
> > for the "View/Reset Coloring".
>
> Well, the "View/Reset Coloring" item is within a subsection about coloring
> which doesn't disturb the other items in the menu. I did not want to make
> the context menus unnecessary longer, so there I put this within the
> coloring sub-menus. If it is really not done to have a little difference
> between the main menu structure and the context menu structures I think
> the "Reset Coloring" should be removed from the context menus rather than
> have it one layer deeper in the View menu. What do you think?
OK, I decided to remove the "Reset Coloring" from the context-menus
since it can be (more) easily be accessed through a hotkey anyways
(SVN 23657).
Cheers,
Sake
