Thanks for the feedback.
> Having two Copy menu items in the details context menu might
> be too much, however, "remixing" the copy menu items will be
> easy once the functionality is settled, so the menu structure
> shouldn't be a problem.
Yep; I'll just get something working and see how it looks.
> I don't know what the "Copy Packet Data > As Text" would
> actually do?
Similar to copy / text only in the bytes pane. This accepts only the
"printable" ASCII bytes. As that is what is done so far I'll probably
start with that. Perhaps this should try to extract anything that looks
like valid UTF-8 instead of ASCII, but I'd have to investigate how to do
that. I'll probably try to refactor the existing functionality so that
it can share the same code path when called from any pane if I can do so
without too much difficulty, so it is consistent, and can be updated
later.
>
>
> The most interesting question is: which copy functionality
> makes sense in which context menu.
Yep; but I'm going to focus on trying to get individual bits working and
maybe refactored out so that they can be called from any pane more
easily. Then we can see what people really want.
>
> When I remember correct, in principle in GTK/GLib it should
> be possible to put multiple formats into the clipboard (with
> different MIME types), but the Win32 implementation of
> GTK/GLib only implemented the text format.
What MIME type would be appropriate for raw binary?
application/octet-stream? Windows doesn't seem to have a standard
clipboard format for raw bytes (sigh) - the best it does is ANSI text,
which will fall over on embedded zeros. May have to hold off on binary -
I'm primarily a Windows guy and am not sure how I would even test this
on UNIX. What application could I paste into?
> >
> > I think that the menu item should copy the data _only_ for the
> > selected part of the frame - effectively the bytes _highlighted_ in
> > the bytes pane (otherwise it risks being a duplication of
> > functionality in the bytes pane).
> >
> The current byte pane functionality is a bit odd, as a right
> click on the selected bytes selects a smaller subset. We
> might better move this functionality completely to the
> details menu - but I'm not sure on this.
Changed my mind - this should do the whole packet in packet details, so
as to match packet list (see below).
> But it might be a real value to copy the whole packet in this menu.
> Something like:
>
> Copy ->
> Summary as Text
> Summary as CSV
> Packet Bytes as Hex
> Packet Bytes as Binary (when possible)
> >
Yes.
> The current select / browse functionality IS odd in my eyes
> too (at least on Win32). However, selecting multiple packets
> would be really nice, but that would require some deep
> internal changes of the packet list code and a lot of other
> parts of WS. So this is really not the topic for a start to
> "fix" all this...
Will leave well alone. I only have a few days to look at this initially!
> >
> > Cheers
> >
> > Doug
> >
> Regards, ULFL
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies within the Detica Group plc group of companies.
Detica Limited is registered in England under No: 1337451.
Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.
