[Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx>]

On Dec 22, 2012, at 10:55 PM, Evan Huus wrote:
> On Sat, Dec 22, 2012 at 4:37 PM, Michael Tuexen
> <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
>> On Dec 22, 2012, at 8:31 PM, Evan Huus wrote:
>> 
>>> So I finally got back to this and played with some of the
>>> platform-specific features as well as some of the features that have
>>> landed in trunk since 1.8 was released.
>>> 
>>> I have linked two more wireframes.
>>> 
>>> == Input v2 ==
>>> 
>>> The first wireframe [1] is a second draft of the "Input" tab for the
>>> Capture Options dialogue. It is similar to my first draft, with the
>>> following differences:
>>> 
>>> - Replaced "Add Pipe" with "Add..." since there are several different
>>> interface types we might want to add, and put an equivalent "Delete"
>>> button beside it.
>>> 
>>> - Minor string change for "Use promiscuous mode on all interfaces" checkbox
>>> 
>>> - Make it a little clearer that the "Help", "Start Capture" and
>>> "Close" buttons are outside the tab frame. This applies to the other
>>> two tabs of the dialogue as well, but is sufficiently trivial that I
>>> didn't redraw them.
>>> 
>>> - Add the default capture filter field that is now in trunk. I
>>> reworked this slightly by putting it into its own subframe and adding
>>> some buttons. The button that was previously doubling as a label has
>>> now been put on its own as "Manage Filters...". A "Save..." button was
>>> added for creating new saved filters without opening up the Manage
>>> Filters dialogue. "Compile" got a string change - the term "BPF" is
>>> jargon that we shouldn't be exposing except in special circumstances
>>> (I debated removing this button altogether, or perhaps renaming it to
>>> "Show Compiled Form...", any thoughts?).
>>> 
>>> == Add Interface ==
>>> 
>>> The second wireframe [2] is a completely new dialogue that would be
>>> opened when the user chooses "Add..." in the Capture Options dialogue.
>>> It has a Name and Type fields, and a "Details" subframe that changes
>>> depending on which type is chosen. The rest should be fairly
>>> self-explanatory.
>>> 
>>> ====
>>> 
>>> I also plan at some point to wireframe a new version of the "Edit
>>> Interface Settings" dialogue that is launched currently by
>>> double-clicking on an interface, but I'm not sure when I'll get around
>>> to it. I hope to integrate the special Windows-only "Interface
>>> Details" panel into it if I can.
>>> 
>>> Thoughts? Constructive criticism is always welcome :)
>> The table in the Input pane shows next to each other the friendly name,
>> and addresses (and a traffic curve). Does this fit? The friendly name can
>> be long, as the IPv6 addresses are. That is why we currently display
>> them not next to each other, but below.
> 
> I think it ought to fit, but that is something to consider. The linked
> screenshot [1] shows part of the current table (on trunk) at the
> default width. If you line up the columns with the wireframe, then:
> - "Capture" stays the same
> - "Interface" stays the same width but shows only the friendly name
> instead of also showing the addresses. Names long enough to be elided
> should still be distinguishable at the width shown.
Not sure, but on Windows these names are longer, I think...
> - "Link-layer header" becomes "Addresses" and becomes marginally
> shorter. The IPv6 address as printed below wlan0 should fit in that
> column with a bit of room to spare.
> - "Prom. Mode" becomes the "Traffic" sparkline and becomes marginally
> longer (taking up whatever we can shave off of "Addresses").
> - "Snaplen" becomes "Options" at the same width.
> 
> This leaves us with a tiny bit of room left (where you can just see
> the left edge of the "Buffer" column) to allocate where we need it.
> Assuming I've got the approximate dimensions right then this should
> let us make the traffic sparkline a bit wider still..
Some one needs to test. Windows has funny names (at least it had at
the point of time we were testing).
> 
>> It would be nice to have the columns to be configurable, such that I
>> can see the settings (which are important for me) without clicking on
>> the Options button.
> 
> My apologies for being unclear - the columns should of course remain
> configurable, I just didn't draw that. The wireframe I drew showed
> only what I think the defaults should be.
OK. Makes sense.

Best regards
Michael
> 
> Evan
> 
> [1] https://dl.dropbox.com/u/171647/Current_Interface_Table.png
> 
>> Best regards
>> Michael
>>> 
>>> Cheers,
>>> Evan
>>> 
>>> [1] https://dl.dropbox.com/u/171647/Wireshark-Wireframes/1.%20Input%20v2.jpg
>>> [2] https://dl.dropbox.com/u/171647/Wireshark-Wireframes/4.%20Add%20Interface.jpg
>>> 
>>> On Sat, Dec 8, 2012 at 11:06 AM, Michael Tuexen
>>> <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
>>>> On Dec 8, 2012, at 4:17 PM, Evan Huus wrote:
>>>> 
>>>>> On Sat, Dec 8, 2012 at 10:02 AM, Michael Tuexen
>>>>> <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
>>>>>> On Dec 8, 2012, at 3:15 PM, Evan Huus wrote:
>>>>>> 
>>>>>>> On Sat, Dec 8, 2012 at 7:57 AM, Michael Tuexen
>>>>>>> <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
>>>>>>>> On Dec 8, 2012, at 3:49 AM, Evan Huus wrote:
>>>>>>>> 
>>>>>>>>> I have drawn and scanned three mock-up sketches (linked at the
>>>>>>>>> bottom), one for each of the three tabs I proposed in my previous
>>>>>>>>> email. Apologies in advance for my inability to write legibly or draw
>>>>>>>>> straight lines -- I am happy to "translate" for people who can't
>>>>>>>>> decipher it :)
>>>>>>>>> 
>>>>>>>>> Again, these are just what's been kicking around in my head - I'm sure
>>>>>>>>> there are lots of issues with them still. Constructive criticism is
>>>>>>>>> very welcome.
>>>>>>>> One point brought up a couple of times was that increasing the number
>>>>>>>> of clicks to do a specific job is not good. And at least some uses
>>>>>>>> want to navigate with the keyboard. That is my main concern when
>>>>>>>> choosing multiple tabs. What do others think?
>>>>>>> 
>>>>>>> I agree that increasing the number of clicks isn't good if we can
>>>>>>> avoid it, but neither is overwhelming the user with too many options
>>>>>>> at once. The current dialog has (approximately) 7 major sections, one
>>>>>>> of which is quite complex (the interface list). Different UI Design
>>>>>>> guides quote different numbers here, but most of them agree you don't
>>>>>>> want to present any more than 4-6 distinct sections at a time to
>>>>>>> prevent overload.
>>>>>> I have to admit that neither me not Irene have particular GUI
>>>>>> knowledge. We just started what was there and tried to improve it,
>>>>>> without changing it too much...
>>>>> 
>>>>> I don't have any particular training either, I just read a lot of
>>>>> random design stuff on the internet :)
>>>> Haven't even done that...
>>>>> 
>>>>>>> 
>>>>>>> Keyboard navigation is quite possible with tabs (assuming they're
>>>>>>> implemented correctly) and in this case may actually be faster. In the
>>>>>>> current dialogue it takes me 16 keyboard presses to get to "Enable
>>>>>>> transport name resolution" from the default top of the dialogue. In
>>>>>>> the tabbed dialogue I calculate it would take me only 8, which is a
>>>>>>> significant win.
>>>>>> Agreed.
>>>>>>> 
>>>>>>>>> 
>>>>>>>>> A few additional notes on each sketch:
>>>>>>>>> 
>>>>>>>>> == 1. Input ==
>>>>>>>>> 
>>>>>>>>> This tab merges the "Capture" section of the current "Capture Options"
>>>>>>>>> dialogue with the current "Capture Interfaces" dialogue. I have
>>>>>>>>> removed several of the columns from the interface list, as most of
>>>>>>>>> them were unnecessary for a summary view and made the dialogue far
>>>>>>>>> wider than the actual default window size (horizontal scrolling is
>>>>>>>>> bad). I replaced the "Packets" and "Packets per second" columns with a
>>>>>>>> The set of columns currently shown is configurable. I wasn't sure
>>>>>>>> which information is important and which not. I thought it might
>>>>>>>> depend on the use case. Personally, I never use the interfaces
>>>>>>>> dialog... But why do I need the traffic to select which interface
>>>>>>>> I'm going to capture. Most of the time I make the choice based
>>>>>>>> on the interface name or the IP address.
>>>>>>> 
>>>>>>> If it depends on the use case, then configurability is a good thing,
>>>>>>> but the default should be fairly minimal.
>>>>>> I think the old version was showing a lot. That is why we started
>>>>>> with showing it and give the user the possibility to disable
>>>>>> columns.
>>>>>>> 
>>>>>>> How does one configure it? I can't click-and-drag, it has no
>>>>>>> right-click context menu, and I don't see anything obvious in
>>>>>>> Wireshark's global preferences...
>>>>>> Right click on the column title works for me. If that doesn't
>>>>>> work, it is a bug. Haven't tested Windows for a while...
>>>>> 
>>>>> This is actually on 1.8.2 on Ubuntu - it does work in trunk on the
>>>>> same machine, so perhaps this is something that got added after 1.8
>>>>> was released?
>>>> Correct. This is part of the improving of the current capture interface
>>>> dialog I was talking about. Since it doesn't address a real bug, Irene's
>>>> changes were not scheduled for backporting to trunk-1.8. I guess they
>>>> will be included in 1.10 once it will be released.
>>>>> 
>>>>>>> 
>>>>>>> I included the sparklines because the current "Capture Interfaces"
>>>>>>> dialogue includes a live packets/second count. I suspect it's useful
>>>>>>> for new users who don't know their interfaces to be able to see that
>>>>>>> "the one I want to capture on is the one all my traffic is coming on",
>>>>>>> but I'm not particularly attached to it if there isn't actually a use
>>>>>>> case for it.
>>>>>> Maybe... Our decisions were based on our needs and the feddback we
>>>>>> got on the mailing list. So maybe there is a need for real time graphing
>>>>>> in the capture options dialog, just no one complained about that...
>>>>>>> 
>>>>>>>>> single sparkline column, since we're using those other places in
>>>>>>>>> qtshark and they give a good compact overview of the traffic level. I
>>>>>>>>> also kept the explicit "Options" button column since it's more
>>>>>>>>> discoverable than double-clicking.
>>>>>>>> That is correct. However, we didn't go for a button to save space.
>>>>>>>> We could reconsider this choice. What do others think?
>>>>>>> 
>>>>>>> One of the reasons I dropped some of the other columns was to make
>>>>>>> space, since I figure the discoverability of the extra configuration
>>>>>>> options was more important than displaying read-only copies of some of
>>>>>>> those values. Consider the case where the user wants to enable/disable
>>>>>>> promiscuous mode for a specific interface. Currently they can see the
>>>>>>> value but can't edit it directly (which is potentially annoying), and
>>>>>>> to edit it they have to double-click on the row (which isn't bad, but
>>>>>>> is not as discoverable as the button). In the new design it wouldn't
>>>>>>> be visible at all, but there's a nice friendly button for more options
>>>>>>> which brings up a dialogue where they can both see and edit the value
>>>>>>> they want.
>>>>>> The drawback is that I don't see the current configuration. I have
>>>>>> to double check each interface by clicking on the options button.
>>>>> 
>>>>> Yes
>>>>> 
>>>>>> I normally check the capture filter and promiscuous mode settings,
>>>>>> sometime also the buffer size. That is why I found it nice to
>>>>>> see the summary currently presented.
>>>>> 
>>>>> Those columns should certainly be addable, but I'm not convinced
>>>>> they're worth displaying by default (I've never really used any of
>>>>> them, for example).
>>>>> 
>>>>> It would be worth getting more data on which columns people use though...
>>>> I guess this might be crucial point:
>>>> 
>>>> We did our design based on our requirements and asked for feedback on
>>>> the list before implementing and after committing the code. We got some
>>>> before the development, we got really some substantial feedback from
>>>> other developers. Irene implemented most of the suggested stuff and
>>>> improvements. So the solution we have right now is much better than
>>>> what we came up with. However, we didn't get much feedback from users
>>>> not being (core)-developers...
>>>>> 
>>>>>>> 
>>>>>>> One of the other design principles I was working from is that one
>>>>>>> should avoid displaying read-only copies of editable fields, as the
>>>>>>> user will want to edit them and get annoyed when they can't.
>>>>>> I remember that we were thinking about it, but I'm not sure why
>>>>>> we didn't do it that way. Maybe Irene remembers...
>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I also completely got rid of the "Manage Interfaces" dialog by
>>>>>>>>> spreading its functionality around a bit. Local interfaces can be
>>>>>>>>> hidden/unhidden via a "Hide" (or "Unhide", depending) option in their
>>>>>>>>> right-click context menu (not shown in the sketch). The "Show hidden
>>>>>>>>> interfaces" checkbox allows users to unhide otherwise-hidden
>>>>>>>>> interfaces temporarily.
>>>>>>>>> 
>>>>>>>>> Pipes can be added via the "Add Pipe..." button which directly opens a
>>>>>>>>> file-chooser dialog. Pipes can be deleted via a "Delete" item in their
>>>>>>>>> right-click context menu (not shown in the sketch).
>>>>>>>> The Add pipe button doesn't scale. Where do you manage remote interfaces
>>>>>>>> (if available)? We also envisioned the addition of other mechanisms like
>>>>>>>> using PSAMP/IPFIX kind of stuff, integrating ssh based stuff. Scalability
>>>>>>>> to multiple interface types was what we had in mind here.
>>>>>>>> So at least the remote interfaces need to be added back.
>>>>>>> 
>>>>>>> Fair enough, I wasn't aware of these. I still believe that management
>>>>>>> of existing interfaces can (and should) be done through the primary
>>>>>>> list via context menu items and their individual Options dialogues,
>>>>>> Hmm. But adding interfaces of another host is not within the context
>>>>>> of an existing one...
>>>>>>> but perhaps "Add Pipe..." isn't the right choice. Would some sort of
>>>>>>> "Add Interface..." button be more appropriate if it spawned an actual
>>>>>>> minimal dialogue instead of a straight file-chooser?
>>>>>> It can bring up the tab style window. We thought it is a good idea
>>>>>> to have a tab for each kind of interface... Like local ones, remote
>>>>>> ones (rpcap), pipes, and possibly others in the future. We wanted
>>>>>> a generic term like manage, since (I think) we can't only add interface,
>>>>>> but also remove, rescan the local ones and so one.
>>>>> 
>>>>> Again, I think removing/editing should be done from the master list.
>>>>> Perhaps 'rescan' should also be a button in the main window. Limiting
>>>>> the additional dialogue to adding-only should allow us to greatly
>>>>> simplify it, perhaps even using a drop-down list for the type of
>>>>> interface instead of a tab for each.
>>>> The information you need for adding an interface is very different for
>>>> different types of interfaces. We set up a machine with remote capturing
>>>> support for playing with it. So for a named pipe it is just a name, for
>>>> remote capturing there a several options (hostname, protocol, username,
>>>> password, some other options I forgot). That is why we went with a
>>>> tab style window...
>>>>> 
>>>>> I will have to think on this.
>>>> You might want to play with the features. Wireshark has several "plattform
>>>> specific" features we were not aware of initially...
>>>> 
>>>> Best regards
>>>> Michael
>>>>> 
>>>>>>> 
>>>>>>>>> 
>>>>>>>>> There are also a few minor string changes:
>>>>>>>>> - "Capture all in promiscuous mode" -> "Always use promiscuous mode".
>>>>>>>>> - "Start" -> "Start Capture"
>>>>>>>> These can be added to the current solution. I think this makes sense.
>>>>>>>>> 
>>>>>>>>> == 2. Output ==
>>>>>>>>> 
>>>>>>>>> This tab replaces the "Capture File(s)" section of the current
>>>>>>>>> "Capture Options" dialogue. The "Use pcap-ng format" checkbox becomes
>>>>>>>>> a drop-down list for output format, allowing us to add other file
>>>>>>>>> formats if we want, and making it clear what the current alternative
>>>>>>>>> to pcap-ng is.
>>>>>>>>> 
>>>>>>>>> The implicit temp file used when the "File" field is blank becomes an
>>>>>>>>> explicit check-box. I also added an option to create a new file every
>>>>>>>>> N packets in order to be consistent with the "Stop capture after"
>>>>>>>>> options.
>>>>>>>>> 
>>>>>>>>> Also made some more string changes, mostly for clarity and to avoid
>>>>>>>>> technical terms like "Ring buffer".
>>>>>>>>> 
>>>>>>>>> == 3. Options ==
>>>>>>>>> 
>>>>>>>>> This tab replaces the other sections of the current "Capture Options"
>>>>>>>>> dialogue (Display Options, Name Resolution, and Stop Capture...).
>>>>>>>>> 
>>>>>>>>> The only real change (besides more string changes) is that the "Stop
>>>>>>>>> capture" option gets a master checkbox which controls the availability
>>>>>>>>> of three condition checkboxes.
>>>>>>>> So the main question is: Do we want to split up the dialog into multiple
>>>>>>>> tabs? And if yes, for which version? I think we introduced the new rewritten
>>>>>>>> dialog in 1.8 and are now refining it. So the improved version will be in
>>>>>>>> 1.10. So I guess the the tabbed one would be in 1.12. Or are you targeting
>>>>>>>> 1.10? This would mean we should improve the current one anymore.
>>>>>>> 
>>>>>>> Honestly, I was targeting qtshark with this and not the gtk version at
>>>>>>> all (thus the use of sparklines). Some of the easy string changes can
>>>>>>> go into the gtk version for 1.10 obviously, but I don't think it makes
>>>>>>> sense to implement the whole thing twice.
>>>>>> OK. I haven't looked at the qt stuff at all. We had to touch the capture
>>>>>> options window to add support for capturing from multiple interfaces. Since
>>>>>> we wanted it in the current version, we worked on the gtk stuff (not sure
>>>>>> if at the time we started, the qt stuff was already there).
>>>>>> I also don't want to re-spend the effort completely. But whatever we
>>>>>> can improve, we most likely will. So any suggestion is welcome.
>>>>>>> 
>>>>>>> I am curious to hear what others think about the tabs though. Anyone
>>>>>>> else care to weigh in?
>>>>>> Yes, anyone?
>>>>>> 
>>>>>> Best regards
>>>>>> Michael
>>>>>>> 
>>>>>>> Evan
>>>>>>> 
>>>>>>>> 
>>>>>>>> Best regards
>>>>>>>> Michael
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> Evan
>>>>>>>>> 
>>>>>>>>> [1] https://dl.dropbox.com/u/171647/Wireshark-Wireframes/1.%20Input.jpg
>>>>>>>>> [2] https://dl.dropbox.com/u/171647/Wireshark-Wireframes/2.%20Output.jpg
>>>>>>>>> [3] https://dl.dropbox.com/u/171647/Wireshark-Wireframes/3.%20Options.jpg
>>>>>>>>> 
>>>>>>>>> On Fri, Dec 7, 2012 at 9:15 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
>>>>>>>>>> On Fri, Dec 7, 2012 at 3:46 PM, Michael Tuexen
>>>>>>>>>> <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
>>>>>>>>>>> On Dec 7, 2012, at 9:06 PM, Evan Huus wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> On Fri, Dec 7, 2012 at 2:41 PM, Michael Tuexen
>>>>>>>>>>>> <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
>>>>>>>>>>>>> On Dec 7, 2012, at 8:01 PM, Evan Huus wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Fri, Dec 7, 2012 at 1:47 PM, Gerald Combs <gerald@xxxxxxxxxxxxx> wrote:
>>>>>>>>>>>>>>> For the Qt toolbar I created start and stop capture icons based on the
>>>>>>>>>>>>>>> media player/recorder "record" (circle) and "stop" (square)
>>>>>>>>>>>>>>> conventions[1][2]. "Record" makes more sense to me; we are recording
>>>>>>>>>>>>>>> packets to disk after all. It also makes things easier if we ever get
>>>>>>>>>>>>>>> around to adding a playback feature. My versions are
>>>>>>>>>>>>>>> capture_start_24.png, capture_start_active_24.png, and
>>>>>>>>>>>>>>> capture_stop_24.png in the "image" directory.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> A media-player-ized "capture options" icon could be a record button with
>>>>>>>>>>>>>>> a superimposed wrench. I'm not sure about the "interface list" or
>>>>>>>>>>>>>>> "restart capture" buttons however.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> +1 for the "capture options" icon.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I would suggest that (in qtshark) the entire "interface list" dialog
>>>>>>>>>>>>>> be merged into the "capture options" dialog - there's a large amount
>>>>>>>>>>>>>> of information duplicated between them and they do almost the same
>>>>>>>>>>>>>> thing already. The dialog should generally be rethought at the same
>>>>>>>>>>>>>> time, as the current "capture options" dialog is already quite busy --
>>>>>>>>>>>>>> perhaps splitting it into tabs is the way to go? With the dialogues
>>>>>>>>>>>>> Hi Evan,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> the capture options dialog was rethought for 1.8 to support the
>>>>>>>>>>>>> capturing from multiple interfaces. We wanted to clean things up
>>>>>>>>>>>>> on the one hand side, don't change too much on the other.
>>>>>>>>>>>> 
>>>>>>>>>>>> That was already in trunk when I first started hacking on Wireshark :)
>>>>>>>>>>> .. OK.
>>>>>>>>>>>> 
>>>>>>>>>>>> I'm not too familiar with the old (1.6?) dialog, but after a quick
>>>>>>>>>>>> glance at some old documentation screenshots it looks like the 1.8
>>>>>>>>>>>> version is already a lot cleaner than it was.
>>>>>>>>>>>> 
>>>>>>>>>>>>> So if you have concrete suggestions how to improve the capture
>>>>>>>>>>>>> options dialog box, Irene and myself will be more than happy
>>>>>>>>>>>>> to discuss it. Please provide some feedback.
>>>>>>>>>>>> 
>>>>>>>>>>>> I have a bunch of ideas floating around in my head - I will try and do
>>>>>>>>>>>> some simple wireframes tonight, but for now, a quick summary:
>>>>>>>>>>>> 
>>>>>>>>>>>> Three tabs: Input, Output, Options
>>>>>>>>>>>> - Input tab contains some melding of the list of interfaces in
>>>>>>>>>>>> "capture options" and the list of interfaces in "capture interfaces".
>>>>>>>>>>>> - Output tab contains everything from the "Capture File(s)" section in
>>>>>>>>>>>> "capture options", plus possibly a few more we don't expose right now.
>>>>>>>>>>>> - Options tab contains the other three sections from "capture options"
>>>>>>>>>>>> (display options, name resolution, stop capture...)
>>>>>>>>>>> I would like to get input also from others...
>>>>>>>>>>> 
>>>>>>>>>>> Our users are somewhat used to the current layout. So we should have
>>>>>>>>>>> good reasons to change it. One reason would be to have space for
>>>>>>>>>>> more options. Not sure.
>>>>>>>>>> 
>>>>>>>>>> My primary reason for re-organizing it this way is that the interface
>>>>>>>>>> list is already quite large (I have six interfaces listed) and if we
>>>>>>>>>> merge in the other dialog it will just get larger - the window will
>>>>>>>>>> end up too big with too many controls in it at once.
>>>>>>>>>> 
>>>>>>>>>> Open to other suggestions of course, but that's the problem I was
>>>>>>>>>> trying to solve.
>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Some misc other things I've been thinking about:
>>>>>>>>>>>> - it would be nice if the "Capture on all interfaces" checkbox lived
>>>>>>>>>>>> in the column title as a master checkbox (see the "In Store" column at
>>>>>>>>>>>> [1] for an example).
>>>>>>>>>>> I think we follow (to some extend) the Human Interface Guidelines
>>>>>>>>>>> for GTK. Do they have something like this?
>>>>>>>>>> 
>>>>>>>>>> Not that I've been able to find, though they do seem to have
>>>>>>>>>> multiple-selection checkboxes in some circumstances (see figure 6-12
>>>>>>>>>> in [1]).
>>>>>>>>>> 
>>>>>>>>>> [1] http://developer.gnome.org/hig-book/3.5/controls-check-boxes.html.en
>>>>>>>>>> 
>>>>>>>>>>>> - it would be nice if the "Prom. Mode" column contained editable
>>>>>>>>>>>> checkboxes, and the "Capture all in promiscuous mode" was a column
>>>>>>>>>>>> master checkbox as well
>>>>>>>>>>> Same question as above.
>>>>>>>>>>>> - it's not immediately clear in the "Stop Capture..." section whether
>>>>>>>>>>>> multiple checked options will be combined with a logical AND or a
>>>>>>>>>>>> logical OR
>>>>>>>>>>> Not sure, we took it over.
>>>>>>>>>> 
>>>>>>>>>> I suspect it's using OR, but I'm not sure where to look to find out.
>>>>>>>>>> 
>>>>>>>>>>>> - same AND vs OR issue with the various "Use multiple files" options
>>>>>>>>>>> Not sure, we took it over.
>>>>>>>>>>>> - the "capture interfaces" dialog has a button for each interface,
>>>>>>>>>>>> whereas the "capture options" dialog has double-clickable rows -- I'm
>>>>>>>>>>>> not sure which one is better, but we should pick one (I'm leaning
>>>>>>>>>>>> towards the buttons)
>>>>>>>>>>> You must be using Windows... Only on Windows you have a Details button
>>>>>>>>>>> in the capture interfaces dialog. This is different form what you
>>>>>>>>>>> get when double clicking on the capture options dialog box.
>>>>>>>>>>> In the capture options dialog box we didn't use a button to save space...
>>>>>>>>>> 
>>>>>>>>>> I see that the "Details" button doesn't exist on my linux version - do
>>>>>>>>>> we not have access to that extra information on non-windows platforms?
>>>>>>>>>> 
>>>>>>>>>> I will send some simple sketches shortly.
>>>>>>>>>> 
>>>>>>>>>> Evan
>>>>>>>>>> 
>>>>>>>>>>> Best regards
>>>>>>>>>>> Michael
>>>>>>>>>>>> 
>>>>>>>>>>>> I'm be very happy to discuss further, this is all just
>>>>>>>>>>>> back-of-a-napkin ideas right now.
>>>>>>>>>>>> 
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Evan
>>>>>>>>>>>> 
>>>>>>>>>>>> [1] http://dhtmlx.com/docs/products/dhtmlxGrid/samples/08_filtering/03_pro_filter_num.html
>>>>>>>>>>>> 
>>>>>>>>>>>>> Best regards
>>>>>>>>>>>>> Michael
>>>>>>>>>>>>>> merged we only need one icon, which can be the record button with a
>>>>>>>>>>>>>> superimposed wrench.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> For "restart capture" I would think we should be using a record button
>>>>>>>>>>>>>> with superimposed "refresh" circular arrow people know from web
>>>>>>>>>>>>>> browsing. Perhaps the current "reload capture file" icon would be
>>>>>>>>>>>>>> sufficient there?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> At some point I was hoping to see if we could get Elliott Aldrich (who
>>>>>>>>>>>>>>> made the current document icon and several interface icons) to create
>>>>>>>>>>>>>>> updated versions of the main toolbar icons including the capture ones.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [1] http://commons.wikimedia.org/wiki/Tango_icons#Media
>>>>>>>>>>>>>>> [2] http://commons.wikimedia.org/wiki/GNOME_Desktop_icons#Media
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 12/7/12 6:38 AM, Maynard, Chris wrote:
>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> There was mention of these icons some time ago, but no changes were ever made: http://www.wireshark.org/lists/wireshark-dev/201107/msg00092.html
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> - Chris
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> ________________________________________
>>>>>>>>>>>>>>>> From: wireshark-dev-bounces@xxxxxxxxxxxxx [wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris [guy@xxxxxxxxxxxx]
>>>>>>>>>>>>>>>> Sent: Friday, December 07, 2012 4:08 AM
>>>>>>>>>>>>>>>> To: wireshark-dev@xxxxxxxxxxxxx
>>>>>>>>>>>>>>>> Subject: [Wireshark-dev] Capture start and capture stop icons in the toolbar
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Dec 6, 2012, at 5:46 PM, gerald@xxxxxxxxxxxxx wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Use a different "close" button in the main toolbar. It looks better but
>>>>>>>>>>>>>>>>> is still wrong (on OS X at least).
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> As long as we're playing with the toolbar:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I've always found the icon on the "start a capture" button a bit non-obvious.  I guess it's supposed to be an image of a plug-in network adapter card for some parallel bus (although that's not the first thing that comes to mind when I look at it), but:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>  1) the sorts of machines on which a lot of people run Wireshark have built-in network adapters
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>  2) even a lot of the add-on adapters out there plug into serial buses (USB, PCI Express/Thunderbolt)
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> so a "conventional PCI" card might be an out-of-date icon these days, and, in addition, a number of the other sniffers I've seen use the CD player "start" (right-pointing triangle, pick your color), "stop" (square, probably red or black), and, in some cases, "pause" (two parallel vertical lines) icons for the capture buttons.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> ("Pause" means "don't receive packets, but, if you click the pause button again, continue capturing with the same options, without discarding or saving the already-captured packets.")
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> ___________________________________________________________________________
>>>>>>>>>>>>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>>>>>>>>>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>>>>>>>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>>>>>>>>>>>       mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>>>>>>>>>>> ___________________________________________________________________________
>>>>>>>>>>>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>>>>>>>>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>>>>>>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>>>>>>>>>>       mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ___________________________________________________________________________
>>>>>>>>>>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>>>>>>>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>>>>>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>>>>>>>>>        mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>>>>>>>>> ___________________________________________________________________________
>>>>>>>>>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>>>>>>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>>>>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>>>>>>>>        mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> ___________________________________________________________________________
>>>>>>>>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>>>>>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>>>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>>>>>>>         mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>>>>>> ___________________________________________________________________________
>>>>>>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>>>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>>>>>         mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> ___________________________________________________________________________
>>>>>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>>>>          mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>>>> ___________________________________________________________________________
>>>>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>>>          mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>>>> 
>>>>>> 
>>>>>> ___________________________________________________________________________
>>>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>>           mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>> ___________________________________________________________________________
>>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>           mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>> 
>>>> 
>>>> ___________________________________________________________________________
>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>> ___________________________________________________________________________
>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>> 
>> 
>> ___________________________________________________________________________
>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>