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

Wireshark-dev: Re: [Wireshark-dev] Do we really need port preferences for dissectors?

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 5 Feb 2016 13:18:49 -0800
On Feb 5, 2016, at 1:00 PM, Michael Mann <mmann78@xxxxxxxxxxxx> wrote:

> I'm not surprised we're getting those questions, but for me I'd like to work towards the goal of providing an overall solution for heuristics and get away from dissector specific ones.

There's "dissector-specific" in the code and there's "protocol-specific" in the UI.  The two are not rigidly tied together.

I *really* don't want to have users who just want to tweak the way Ethernet MPLS pseudo-wire dissectors have to pop up "Enabled Protocols" , search for "PW" or "Ethernet" in that huge list, and enable or disable the appropriate protocol - or possibly pop up Decode As and have to *create a new entry* - rather than popping up a dialog that presents an *existing* list that *includes* MPLS, and lets them select the MPLS item and edit it.

I.e., I think 2.x's UI for changing those settings is inferior to 1.x's, even if the underlying *dissector code* is cleaner.  I think the set of questions we're getting is a sign that, at the UI level, we've made a mistake and reduced the usability of Wireshark.

> Right now the functionality I'm talking about fits into our existing Decode As, so that's why I'm suggesting putting it there.

I think we should rethink how the Decode As UI works *now* before adding anything to it.

For example, we should have at least one dialog that includes entries for every protocol for which you *can* adjust settings, *regardless* of whether the user has changed any settings from the default.

> Long term (probably post 2.2 release) I'd like to see Decode As, enable/disable protocols, enable/disable heuristic dissectors, "conversation Decode As" (and maybe other items I'm forgetting) all somehow merged into a single UI data representation.

Single *internal* data representation, fine.

Single *place in the UI*, not necessarily.  From the UI standpoint, what matters is how obvious is it to the user where to do something, *not* how clean the data structures are - we may well have different parts in the UI for different types of things in the data structure.