it specifically works on the main window's tree and hex dump views (it
doesn't apply to packet windows - they are always showing data from a
particular packet), and move its declaration to main_packet_panes.h.
svn path=/trunk/; revision=43293
panes to main_packet_panes.c.
Rename main_tree_view_new() to proto_tree_view_new() - it's not just for
creating the main window's protocol tree view, it's also for creating
protocol tree views in packet windows.
svn path=/trunk/; revision=43292
used for popped-up packet windows, and it includes more than just code
to draw the protocol tree - it includes the hex dump pane code as well.
Rename it packet_panes.c; the stuff specific to the main window should
be moved into a different file.
svn path=/trunk/; revision=43291
used for popped-up packet windows, and it includes more than just code
to draw the protocol tree - it includes the hex dump pane code as well.
Rename it packet_panes.c; the stuff specific to the main window should
be moved into a different file.
svn path=/trunk/; revision=43290
Show all of them in the summary dialog; we will be using it in the
future to figure out what capture file formats we can write to (just
because a capture file format supports per-packet encapsulations, that
doesn't mean that it supports *all possible* encapsulations).
svn path=/trunk/; revision=43278
highlight_field() is also called when we open packet in new window and we click some bytes,
it caused redrawing packet details in *main window* but with protocol tree from (possibly) another frame.
svn path=/trunk/; revision=43277
stopped - there's no guaranteed way to make the UI's close button
inactive (on X11, it depends on whether the window manager allows that),
but we can just do nothing and return TRUE from the delete event handler
to ignore the delete event.
svn path=/trunk/; revision=43252
capture to stop, so that we don't try to quit while we're in the middle
of quitting or try to stop or restart the capture we're in the middle of
stopping.
svn path=/trunk/; revision=43250
the main loop until we're done reading the captured packets. Hopefully
this clears up bug 7318 in Evan Huus's case; I can't reproduce that
myself.
svn path=/trunk/; revision=43248
File name preferences are basically just string preferences except that the
GUI will present a "Browse" button that allows the user to go and find the
file s/he wants (rather than having to blindly type in the full path).
svn path=/trunk/; revision=43228
When building current data for packet details treeview we store two things.
- Generated string with item label
- Pointer to node field_info structure
After epan_dissect_{free, cleanup} pointer to field_info node is no longer
valid so we should clear GtkTreeStore before freeing.
svn path=/trunk/; revision=43188
(Before checking the code it wasn't clear to me what COUNT(*) was counting
and--especially with SCTP's bundling of user messages--counting fields was
really what I wanted/needed.)
Remove a 32-bit cast (should have been part of r43136).
svn path=/trunk/; revision=43137
just tweak the elements in the capture_file structure as necessary and
poke the UI to update stuff such as the windows title.
If we do a Save or Save As with a copy, don't reread the capture file,
just close the old wtap, open a wtap for the copy, and tweak the
elements in the capture_file structure as necessary and poke the UI to
update stuff such as the windows title.
Otherwise, don't do a full read-and-dissect pass on the capture file,
just close the old wtap, open a wtap for the new file, tweak the
elements in the capture_file structure as necessary and poke the UI to
update stuff such as the windows title, and rescan the file to update
the packet offsets (and cause Wiretap to regenerate, for a gzipped file,
the information needed to support fast random access to the gzipped
file).
This should speed up Save and Save As a bit, as well as removing some
glitches in the UI (e.g., you won't see the packet list disappear and
reappear).
svn path=/trunk/; revision=43101
"export specified packets". For "failed", let the user try again with a
different file, in case it failed due to, for example, running out of
space or quota (probably the most likely failure mode for writing, and
trying to a different volume might be the best workaround). For "user
stopped it", presumably they don't want to try again (the most likely
reason is "it was taking too damn long").
Put "Exporting to: ...", not "Saving: ..." in the statusbar if we're
doing "export specified packets".
In process_specified_packets(), allow a null range pointer to be
specified, meaning "save 'em all"; that avoids the possibly-expensive
(with a large capture) operation of initializing the range.
If a "safe save" atop an existing file fails or is stopped, get rid of
the temporary file we created.
svn path=/trunk/; revision=43095
statistics window.
Get rid of the non-modal version (it's not being used any more), and
remove the now-redundant _modal from the modal version.
svn path=/trunk/; revision=43081
really don't belong here - they have nothing to do with capture files).
Absorb the test for the target file's existence into
file_target_exist_ui().
svn path=/trunk/; revision=43077
Windows file dialog, which has its own built-in version of the "do you
want to overwrite that file?" dialog, and Notepad and WordPad, at least,
just appear to error out if you try to overwrite a file with the
read-only flag set, rather than asking whether you want to override
that.
svn path=/trunk/; revision=43072
As..." code path.
Extract the code for the "do you want to overwrite this file" and "OK,
you do - are you aware it's {user-immutable, read-only}?" code paths
into a common routine for use by both of those and, potentially, other
save/export/etc. code paths in the future.
For "Save As", allow us to save atop the current capture file, as that's
just what "Save" does if there are unsaved changes, and "safe save"
makes that work. *Don't* allow that for "Export Selected Packets
As...", however.
The file chooser is run as a modal dialog, so we don't need to worry
about creating more than one of them or about the number of marked
packets etc. being changed out from under us. Get rid of a bunch of
static variables.
svn path=/trunk/; revision=43060
live capture" and colorization, so that the ones in main_menubar.c don't
have to know about anything other than the main menubar.
Move some toolbar routines that should only be used by routines in
main.c into a main_toolbar_private.h header.
svn path=/trunk/; revision=43053
made to the capture file (adding/removing/editing comments, for now) or
if a capture file with unsaved changes are unsaved, updates the menu
bar, the toolbar, *and* the titlebar, which now has a GNOME-style "*" to
indicate unsaved changes.
Make set_menus_for_capture_file() a private interface between main.c and
main_menubar.c, and have its callers, such as
main_update_for_unsaved_changes(), be responsible for updating the
toolbar as well.
svn path=/trunk/; revision=43051
callers either need to free it or their callers need to free it or....
This means that cf_get_display_name() must always return a g_mallocated
string and its callers or... must free it.
For some of those callers, create a new set_window_title() routine to do
the work - they're all using the same pattern.
svn path=/trunk/; revision=43047
a live capture:
have the dialog note that what's being saved are captured
packets;
have the dialog note that the capture will be stopped if you
close/quit;
actually stop the capture before saving the file or closing it.
This should fix bug 7318 (it appears to do so in my tests).
svn path=/trunk/; revision=43045
getting the basename for display purposes, so it's converted from the
GLib/GTK+ locale filename encoding to UTF-8. (For Windows, the locale
filename encoding is UTF-8, and the internal encoding is UTF-16, so the
file names should *probably* all be valid UTF-8 - Windows may not
support invalid UTF-16 in file names. For Qt, I'm not sure whether the
file dialogs ever return file names in some non-UTF-8 encoding.)
svn path=/trunk/; revision=43044
ui/gtk/gui_utils.c into ui/gtk/main_titlebar.c, and the declaration of
one of them out of ui/ui_util.h into ui/gtk/main_titlebar.h, and rename
them to clarify that they work on the window name and titlebar.
svn path=/trunk/; revision=43041
write bits turned off or, on 4.4-Lite-based systems, has its "user
immutable" bit turned on, ask them if they really want to overwrite the
file (as those are both used to say "this file is precious, don't let me
easily accidentally trash it") and, if the "user immutable" bit is set,
turn it off first so that the move in the "safe save" won't fail.
svn path=/trunk/; revision=43006
returned by the file selection dialog are in the locale's character
encoding. Just convert those, and use the formatting capabilities of
the GTK+ message dialog rather than formattting the message to a string
and translating it in its entirety.
Use g_filename_display_basename() to do the locale conversion while
we're at it.
svn path=/trunk/; revision=43005
(I used PPID 0xffffffff as an end-of-list marker so that PPID can no longer
be used in this dialog; if someone starts using that PPID then we'll have
to put a count of PPIDs in pinfo.)
svn path=/trunk/; revision=42991
Patch that creates the filter according to the protocol tree selected.
Fixes
IPv6 filters built from "Protocol Hierarchy Statistics" dialog not specific
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7250
svn path=/trunk/; revision=42960
Wiretap encapsulation values; rename the field in question encap_type to
emphasize that. (Code that looks at that field already assumes it's a
Wiretap encapsulation value.)
For live captures, map the LINKTYPE_ value to a Wiretap encapsulation
value.
wtap_encap_string() never returns NULL, so don't check for a null return
value.
svn path=/trunk/; revision=42871
cppcheck realized that if_info is known not to be null in that code
path, and therefore that checking whether it's null in that code path is
unnecessary. Remove it.
svn path=/trunk/; revision=42867
Fix an ancient copy-and-pasteo of mine ("me" here meaning Guy Harris,
not Evan Huus) - remove an unused data structure (used in the code I
copied and pasted to make this code, not used here).
svn path=/trunk/; revision=42866
saving files, and run it modal (which we're already doing with the
GtkFileChooserDialog); this means less callback-based state machine
stuff, simplifying the code paths a bit.
If we're saving a file before closing it, don't bother reloading it
after saving it.
svn path=/trunk/; revision=42855
whole summary dialog into an editor-like dialog with an OK and Cancel buttons
(OK sets the new capture file comment, Cancel doesn't).
In order to keep the dialog the same regardless of the file type (and avoid
having a Cancel and OK button when there's no text field to edit), allow
users to create or edit capture-file comments even if the file type is not
PCAPNG (they can add a comment via the add/edit comment UI anyway).
Don't include a Clear button: the user can just Ctrl-A + backspace if they
want to do that.
Don't set the comment text to "[None]" if there's no comment, just leave it
blank.
Don't allow the user to create more than 1 Summary dialog at a time.
svn path=/trunk/; revision=42834
summary_update_comment() which is no longer necessary).
cf_update_capture_comment() has the advantage that it doesn't mark the file
as unsaved unless the comment actually changed.
svn path=/trunk/; revision=42832
capture_cb(): if we strrchr() didn't find a seperator, don't use
g_strdup_printf() to format the action_name (since that would have to be
freed), just set it to the action_name.
svn path=/trunk/; revision=42829
only if the capture file format is PCAPNG). This can happen if the user
does not have a PCAPNG file but has added a capture-file comment via the
add/edit capture file comment UI.
Replace some tabs with spaces and wrap a few long lines.
svn path=/trunk/; revision=42827
source isn't compressed and the target is (or vice versa), enable the
"compressed" checkbox in the Save As and Export Specified Packets
dialog. Fix it to clear the checkbox if the selected file format
doesn't support gzipping.
svn path=/trunk/; revision=42822
an API to fetch that.
When doing "Save" on a compressed file, write it out compressed.
In the Statistics -> Summary dialog and in capinfos, report whether the
file is gzip-compressed.
svn path=/trunk/; revision=42818
save" if the destination file exists.
Don't forbid overwriting an existing file in either of those cases (we
still forbid overwriting the current capture file) - the GUI asks the
user whether they want to do the overwrite, and allows them to cancel
out of it - and don't remove the file before writing to it (doing so
makes the save *un*safe).
Attempt to do a save of an unedited temporary file by just moving the
file on Windows as well as on UN*X - ws_rename() will remove the target
if necessary on Windows (and won't do it as a separate operation before
attempting the rename), so it behaves like ws_rename() on UN*X (which is
just a wrapper around rename()).
svn path=/trunk/; revision=42816
new file the current file, as is the case in most if not all other GUI
applications.
A new "Export Specified Packets" menu option allows you to specify which
packets to write out, with the default being the displayed packets (and
those on which the displayed packets depend for, e.g. reassembly), and
never makes the resulting file the current file.
The two operations are conceptually distinct. Lumping them into one
menu item, with the default for "Save As" being "displayed packets only"
and thus making it behave like the latter operation, was causing some
confusion; see, for example, bug 6640.
Make the dialog popped up if you try to "Save As" or "Export Specified
Packets" on top of an existing file ask the "do you want to do this?"
question in the main part of the message, and note in the secondary text
that doing that will overwrite what's in the file; that matches what
TextEdit on OS X and the GNOME text editor say.
svn path=/trunk/; revision=42792
File -> Export Packet Dissections
(for the "print to file", "export as CSV", "export as C array",
"export as PSML", and "export as PDML" items)
File-> Export Selected Packet Bytes
File -> Export SSL Session Keys
File -> Export Objects
(for exporting objects transferred over HTTP, DICOM, or SMB)
menu items.
The operations under Export really weren't that related - about all they
had in common was that they wrote to a file stuff other than packets
in a capture file format; the operations in the groups *under* Export
were related, so the groups are now menu items of their own.
This way, the File menu more immediately indicates what options of that
sort are available.
It also means that the Export Packet Dissections item might make it
clearer that what you get from that is *NOT* something that can just be
read back into Wireshark, as at least one user who asked "how do I get
my capture back from this?" on ask.wireshark.com thought. If that
doesn't suffice, perhaps renaming it to "Export Dissected Packets" would
help; if *that* doesn't suffice, perhaps Kevin Cullimore's suggestion
that it say "Report" rather than "Export" will do the trick:
From: Kevin Cullimore <kcullimo@runbox.com>
Subject: [Wireshark-users] Re: Should the "export as text" item be in an "Export Human-readable..." item in the File menu?
Date: May 19, 2012 8:31:23 PM PDT
To: wireshark-users <wireshark-users@wireshark.org>
Would classifying the asymmetric export (ones that lack a
corresponding "import" action) formats as "reports" help clear
up the original ambiguity/misunderstanding? It seems that most
of the gui-based network tools I'm forced to periodically
interact with rely upon that term with at least some success.
(Or perhaps some other verb would be right in some cases, e.g. "Save SSL
Session Keys".)
This also sets a pattern for another upcoming change - splitting "Save
As" into "Save As", which always saves every packet and makes the new
file the current file, and "{Verb} Specified Packets", which lets you
specify which packets to save and does *not* make the new file the
current file. That'd simplify the code a bit, and might clear up the
new only-in-the-trunk issue in bug 6640 - having "Save As" default to
saving displayed packets currently means that it acts more like the
latter of those functions.
svn path=/trunk/; revision=42778
so "Save" should, for non-temporary files, mean "save the current state
of the capture file on top of the existing file" without prompting for a
file name.
That means we have to do a "safe save" - i.e, write the capture out to a
new file and, if that succeeds, rename the new file on top of the old
file - as the actual packet data to write out is in the file we're
overwriting, not in memory. (We'd want to do that anyway, of
course....)
Update some comments.
Clean up indentation slightly, and get rid of an unnecessary variable
(in all the cases where we use it, we assign it the same value, and that
value isn't modified out from under us before we use it).
Note that after a "Save", or a "Save As" that writes out all captured
packets, we shouldn't have to close the current file and open the new
file and reread it - we should be able to open the new file and update
the frame offsets in the frame_data structures.
Note that we need to do some a better job of reporting rename failures.
svn path=/trunk/; revision=42777
save, we post capture file callback events similar to the ones posted
when reading a capture - otherwise, the reload will leave the welcome
screen up.
Rename cf_cb_file_save_reload_finished to cf_cb_file_reload_finished,
add a cf_cb_file_reload_started callback, have them work similarly to
read_finished and read_started except that the reload uses "Reloading"
in the progress bar and status bar.
Clean up some indentation while we're at it.
svn path=/trunk/; revision=42764
"unsaved_changes", and have it be TRUE iff changes have been made to the
file since it was read - *not* if it's a temporary file from a live
capture.
Check the "is_tempfile" member, and the "unsaved_changes" member, when
appropriate.
Just have a set_toolbar_for_capture_file() routine that updates the
"save", "close", and "reload" toolbar as appropriate, given a
capture_file structure - absorb the function of
set_toolbar_for_unsaved_capture_file() into it.
svn path=/trunk/; revision=42721
We're already checking in gtk if end highlight offsets don't exceed len.
Do the same for start offset.
I wonder if it this checks should be also done when adding items to tree...
svn path=/trunk/; revision=42596
Sort the recent filters list by "most recently used" (that is, put the most
recently used filter at the head of the list).
svn path=/trunk/; revision=42439
Get rid of gtk_widget_set_size_request() calls - at least on my machine
and GTK+ version, they make some of the items too small to show the full
text. Let GTK+ figure out how big things have to be - and if that makes
the toolbar too wide, redesign the toolbar.
svn path=/trunk/; revision=42277
Separate "Toolbar" from the toolbar name in the View menu items.
Use "l", rather than "W", as the whatchamacallit for the wireless
toolbar - "W" is already used for "show packet in new window".
svn path=/trunk/; revision=42275
uses it once it's filled in.
From Evan Huus: in scan_local_interfaces(), pass NULL to
capture_interface_list(), as we don't use the error string (and don't
free it, either).
In fill_capture_box(), for CANT_GET_INTERFACE_LIST, include the error
string in the report, and free it, in all cases, when we're done with
it.
svn path=/trunk/; revision=42089
From me: don't bother initializing if_string in its definition, as if
it's used at all it's set to a different value before all uses.
svn path=/trunk/; revision=42073
or colorize; quit before we even *try* to get the link-layer header
type.
If we don't have an active link-layer header type, that probably means
we don't know what link-layer header types the interface provides, which
would be the case if it were a named pipe or an interface we can't open.
Don't crash in that case, just leave the filter combo box uncolored, to
indicate that we have no clue whether the filter is valid or not.
Fixes bug 7049.
svn path=/trunk/; revision=42059
It was not being highlighted in the bits view.
So add % 8 to avoid shifting the single mask bit right out of the byte
we're supposed to be showing...
svn path=/trunk/; revision=42030
OpenLayers.Layer.Text, insert them into a JSON array and load them using
OpenLayers.Layer.Vector + OpenLayers.Format.GeoJSON. This should fix the
endpoint map feature on modern browsers.
Switch OpenStreetMap to a simpler map from OSGeo.
svn path=/trunk/; revision=41967
from makefiles (and thus from the buildbot).
The intention is to be able to tell when a human is running the tool so we
can provide more code-review guidance.
As a starter, enable the "too many proto_tree_add_text() calls" check when
a human is running the tool.
svn path=/trunk/; revision=41943
popup should also be available through a regular menu. So, make the
"Manually resolve address" function availble in under View->Name Resolution .
(Yes, technically this is an "Edit"-like action, but it just fits so well
under Name Resolution.)
While there, move "Resolve Name" from main_menu_bar_toggle_action_entries[]
into main_menu_bar_entries[] so it doesn't get a (useless) toggle indicator.
(At least as I understand this function, it's supposed to allow you to tell
Wireshark to go off and try to resolve the names in the current frame;
unfortunately it doesn't seem to actually work.)
svn path=/trunk/; revision=41747
are present. However, still only create the graph for the first/only
one.
LTE MAC or RLC frames often contain multiple SDUs that are segments of
the same TCP conversation - this avoids the need to find a frame with
only one SDU.
svn path=/trunk/; revision=41721
capture_opts.h. (It arguably belongs somewhere other than in a file in
ui/gtk, but, if so, move it there, e.g. to something in ui.)
svn path=/trunk/; revision=41712
Guy Harris