On 3/9/15 4:14 PM, Peter Wu wrote:
> On Mon, Mar 09, 2015 at 02:19:20PM -0700, Gerald Combs wrote:
>> On 3/9/15 1:32 PM, Peter Wu wrote:
>>> On Mon, Mar 09, 2015 at 11:44:21AM -0700, Gerald Combs wrote:
>>>> On 3/9/15 7:56 AM, Peter Wu wrote:
>>>>> Hi,
>>>>>
>>>>> I have recently discovered that the Qt UI gets in an inconsistent state
>>>>> (leading to crashes) whenever a packet dialog is open and packets are
>>>>> re-dissected. This is reported at
>>>>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11044
>>>>>
>>>>> Before proceeding to a reimplementation attempt using Model/View, I
>>>>> would like to solicit for some feedback. Was the QTreeWidget choice done
>>>>> consciously? Do you foresee issues with sharing field items via the same
>>>>> model? Is someone already working on this?
>>>>
>>>> A QTreeWidget was chosen lazily, i.e. it did the job at the time. A custom
>>>> model might make more sense given that we have a large limit on the number
>>>> of tree items (MAX_TREE_ITEMS = 1e6).
>>>>
>>>> Having independent models lets each packet dialog persist across files.
>>>> Would a shared model still allow that?
>>>
>>> As far as I know, you can only have one open capture file. Correct me if
>>> I am wrong.
>>
>> That's correct. That's also *exactly* why many of the Qt dialogs catch
>> captureFileClosing and disconnect themselves from the current capture file.
>> If a user wants packet dialogs from multiple capture files spread across
>> multiple monitors I'm not going to question her motives.
>
> So was your comment more like a wishlist feature or did you mean
> persistence across packet selections?
I mean persistence across files. In the Qt UI I can do the following today:
- Open a.pcap.
- Double-click packet 12, which opens packet 12 in a separate window.
- Close a.pcap.
- Open b.pcap
- Select packet 15.
- Compare packet 12 from a.pcap with packet 15 from b.pcap.
The I/O graph, capture file properties, conversations, endpoints, and other
dialogs behave in a similar fashion, e.g. I can compare the TCP
conversations across files from the same application instance.
>>> Both File sets and opening files manually result in all packet dialogs
>>> getting closed after opening a new capture (v1.99.4rc0-34-g6bc138c).
>>> This is the current GTK+ implementation,
>>
>> This is annoying behavior, IMHO.
>>
>>> Qt crashes for the reasons mentioned in bug 11044.
>>
>> ...as is this. :)
>
> Well, "closing" a capture file should also close other dialogs right? Or
> are you pointing at the File sets feature?
Why should it? Why yank away useful information just because the user
closes the capture file?
