aboutsummaryrefslogtreecommitdiffstats
path: root/gtk/gui_prefs.c
AgeCommit message (Collapse)AuthorFilesLines
2001-04-17Fix to a preferences dialog bug, from <inoue@ainet.or.jp>.Guy Harris1-2/+4
svn path=/trunk/; revision=3315
2001-03-02Calculate the height and width of m_r_font globally, since variousGilbert Ramirez1-3/+2
routines need it. When a user clicks on a hex digit or on the corresponding character (the "text dump" portion) in the hex dump, find the field in the proto_tree that the byte corresponds to, expand the GtkCTree so that the field is viewable, select the field, and center it vertically. LanAlyzer has this feature, and I've missed it in Ethereal. svn path=/trunk/; revision=3096
2000-11-21Add a "color.h" file that declares a nominally-toolkit-independentGuy Harris1-7/+9
"color_t" structure to store color values (although currently it has all the same fields that a GdkColor has; its currently advantage is that you don't have to include any GTK/GDK stuff to declare it). Add routines in the "gtk" directory to convert between "color_t" and GdkColor values. Define, in "prefs.h", all colors as "color_t" values rather than GdkColor values. "prefs.h" now no longer needs to include <gtk/gtk.h>, so don't include it. svn path=/trunk/; revision=2692
2000-11-18Fix a number of problems that caused compiles to fail ifGuy Harris1-11/+11
PLUGINS_NEED_ADDRESS_TABLE was defined. svn path=/trunk/; revision=2662
2000-10-20Remove #include "gtk/colors.h" from file.h, which keep the GTK+ headerGilbert Ramirez1-1/+2
files from being #included in epan/packet.c. Fix the other files that need either "gtk/colors.h" or <gtk/gtk.h> #included as a result of not pulling in gtk/colors.h automatically because of file.h. svn path=/trunk/; revision=2519
2000-10-09Add support for modal message boxes ("simple dialog").Guy Harris1-6/+7
Make the message boxes popped up for errors when selecting a font modal, so that the user has to say "yes, I know, I'll do better next time" before hitting "OK" again, so that you don't get a pile of message boxes. svn path=/trunk/; revision=2485
2000-10-09It appears there's no guarantee that you'll actually get a font nameGuy Harris1-1/+8
from a font selection dialog box; check for a null pointer and, if so, let the user know and don't dismiss the font selection dialog. svn path=/trunk/; revision=2484
2000-09-09In the callback for the "OK" button in the font selection dialog, checkGuy Harris1-36/+71
to make sure we can load the font the user selected *and* the font that would, in theory, be the boldface version of that font; if not, pop up an error dialog, and don't nuke the font selection dialog (i.e., the user either has to pick fonts that work, or give up in disgust and click "Cancel"). Don't set "prefs.gui_font_name" until the "fetch" function is called - stuff the name in a static variable when the user clicks "OK" in the font selection dialog. svn path=/trunk/; revision=2405
2000-09-08Redraw:Guy Harris1-15/+44
the text in all "Follow TCP Stream" windows; the text in the help window if we have one up; all hex dump windows; when GUI preference changes are to be applied, so that font changes and "Follow TCP Stream" color changes show up. Update both the Roman and bold font when the font is changed. Don't decrement the reference counts on the old Roman and bold fonts until that's all done. svn path=/trunk/; revision=2401
2000-09-08Graham Bloice's patch to support inverse video rather than boldfaceGuy Harris1-3/+19
highlighting of the bytes, in the hex dump window, corresponding to a selected field. Also, make "remember_ptree_widget()" static, as it's not used outside "gtk/proto_draw.c". svn path=/trunk/; revision=2399
2000-08-24Fix the appearance of the option menus in the GUI preference box.Gilbert Ramirez1-2/+4
It appears to be a buglet in GTK+; by explicitly calling gtk_widget_show() on the menu item, it comes out with proper spacing. Previously I simply used gtk_widget_show_all() on the topmost vbox, and while the option menu menu-items showed, they came out with incorrect vertical spacing. svn path=/trunk/; revision=2356
2000-08-23If you "save" your preferences without opening the colorLaurent Deniel1-2/+3
selection dialog, the colors are saved with null values. So do not call fetch_colors if the colors_changed boolean is FALSE ... svn path=/trunk/; revision=2350
2000-08-23Do the same as with colors for the font selection dialog.Laurent Deniel1-9/+19
Add a boolean that will be set to TRUE if the user hit OK in the font selection dialog. And do nothing about fonts in the apply routine if the font dialog has not been used by the user. This gets rid of a warning which was displayed each time the preferences are "OK, Saved or cancelled" and that whether the user has used the font selection dialog or not (which was very annoying) ... svn path=/trunk/; revision=2348
2000-08-23Fix a comment.Laurent Deniel1-3/+3
svn path=/trunk/; revision=2347
2000-08-23Don't set the marked-packet foreground and background colors in "prefs"Guy Harris1-4/+61
until the GUI-preferences fetch routine is called, and don't re-colorize marked packets until the GUI-preferences apply routine is called; those preferences shouldn't take effect until the user clicks "OK" or "Apply", as that's the way other preferences work. Treat a request to close the color selection dialog the same as a click on the "Cancel" button. svn path=/trunk/; revision=2346
2000-08-23Bleah. What was I thinking? "dlg_window_new()" should take the titleGuy Harris1-3/+2
for the dialog window as an argument (as various dialog creators in GTK+ do), not oblige every caller of it to cut-and-paste a "gtk_window_set_title()" call after it. svn path=/trunk/; revision=2345
2000-08-22Add "Colors..." button in GUI preferences.Laurent Deniel1-3/+224
Currently, it allows the selection of the foreground and background colors of the marked frames but it could be extended further (e.g. color of normal frames). Add update_marked_frames() in main.c to update the display (e.g. colors) of marked frames. svn path=/trunk/; revision=2339
2000-08-21Explain why we don't currently have to defer settingGuy Harris1-1/+7
"prefs.gui_font_name" until the "fetch" routine is called. svn path=/trunk/; revision=2330
2000-08-21Don't set the "prefs.gui_XXX" values until the "fetch" routine for theGuy Harris1-201/+130
GUI preferences is called. Pull all the code for creating option menus for enumerated "prefs.gui_XXX" items into a common routine. svn path=/trunk/; revision=2328
2000-08-21Instead of each set of built-in preferences having "ok", "save",Guy Harris1-68/+34
"cancel", and "delete" methods, give them: "fetch" - fetch from the notebook tab any values not already stored in "prefs", and store them there, but doesn't apply them; "apply" - apply the settings in "prefs"; "destroy" - clean up any windows created from the tab. As we no longer have "cancel" methods, we don't have per-preference code to revert preference values; instead, we have the common preference dialog box code make a copy of all the current preferences, and, when the "Cancel" button is clicked, free the current preferences and copy the saved preferences to it, and apply the preferences. Add an "Apply" button to the preference dialog box, which applies the current preferences without closing the dialog box. Treat a request to delete the preferences dialog box as equivalent to clicking "Cancel". Have a "remember_ptree_widget()" routine to remember all protocol tree widgets, and use the list of those widgets when we set GUI preferences for the protocol tree widgets, rather than setting the main protocol tree widget and then using the list of packet windows. Move that code out of "main.c" to "proto_draw.c", as it's not used by anything in "main.c", but is used by stuff in "proto_draw.c". Make the font one of the preferences we can set on the fly for protocol tree widgets. Also make it something we can set on the fly for the packet list widget. svn path=/trunk/; revision=2316
2000-08-20Instead of having the normal-weight and bold fonts set separately,Guy Harris1-3/+154
generate the name of the boldface font from the Roman font; if the two fonts don't have the same widths, the display will look weird when a field is selected, and it's a bit of a pain for the user to have to select *two* fonts. On UNIX/X, default to "-*-fixed-medium-r-semicondensed-*-*-120-*-*-*-*-*-" rather than to "-*-lucidatypewriter-medium-r-normal-*-*-120-*-*-*-*-iso8859-1" - some Linux distributions appear to lack the Lucida typewriter font. Add a "gui.font_name" preference to the preferences file, specifying the normal-weight font to use. Have it settable from the "GUI" tab in the Preferences dialog box - the "Font..." button, when clicked, pops up a font selection dialog box. If we either can't open the selected font or the boldfaced version of the font, default to "6x13" and "6x13bold" as fallbacks - the former will probably be "fixed", and the latter would be "fixedbold" if X actually created such an alias, but it doesn't so we use "6x13bold" instead. svn path=/trunk/; revision=2304
2000-08-11Miscellaneous code cleaningLaurent Deniel1-7/+1
- add <stdarg.h> or <varargs.h> in snprintf.h and remove those inclusions in the other #ifdef NEED_SNPRINTF_H codes - remove the check of multiple inclusions in source (.c) code (there is a bit loss of _cpp_ performance, but I prefer the gain of code reading and maintenance; and nowadays, disk caches and VM are correctly optimized ;-). - protect all (well almost) header files against multiple inclusions - add header (i.e. GPL license) in some include files - reorganize a bit the way header files are included: First: #include <system_include_files> #include <external_package_include_files (e.g. gtk, glib etc.)> Then #include "ethereal_include_files" with the correct HAVE_XXX or NEED_XXX protections. - add some HAVE_XXX checks before including some system header files - add the same HAVE_XXX in wiretap as in ethereal Please forgive me, if I break something (I've only compiled and regression tested on Linux). svn path=/trunk/; revision=2254
2000-02-29Jeff Foster's changes, with my additions, to allow the user to pop up aGuy Harris1-11/+11
window showing the protocol tree and hex/ASCII data for the currently selected packet. svn path=/trunk/; revision=1670
1999-12-30Allow user to modify appearance of lines and expanders in GUI protocolGilbert Ramirez1-21/+127
tree. svn path=/trunk/; revision=1400
1999-12-29Changed the protocol tree widget from a GtkTree to a GtkCTree. The two reasonsGilbert Ramirez1-8/+95
I did this: First, Havoc Pennington, in "GTK+/Gnome Application Development", in Appendix seciton A.3.88, recommends using GtkCTree instead of GtkTree because GtkCtree is faster, and GtkTree has limitation on its total row height: since it must fit inside a GdkWindow, it is limited to 32,768 pixels of height. GtkTree is more flexible with regards to the types of widgets that can be placed in the tree, but since we deal only with text, that doesn't matter, at least for now. Secondly, a GtkTree doesn't allow arrow-key navigation (at least as far as I could tell). It always bothered me that the up and down arrow keys worked in the packet list and in the hex dump, but no in the protocol tree. GtkCTree does allow arrow-key navigation. In fact, GtkCTree is a subclass of GtkCList (the packet list widget), so they behave a lot alike. I went ahead and fixed the selection bar which has been bothering Richard for a long time now. :) In the GUI preferences dialogue, you can now set both the packet list selection bar and the protocol tree selection bar to either "browse" or "select" mode. "browse" mode is what you're used to: the arrow keys move an outline of the selection bar, but do not change the selection. "select" mode does change the selection when the arrow keys are pressed. The default behavior is set to "select", which seems more natural for a first-time user. svn path=/trunk/; revision=1393
1999-12-16Add a new page to the Preferences notebook: a GUI page. The soleGilbert Ramirez1-0/+132
option right now is the placement of the vertical scrollbars in the 3 panes. (it's one decision; you can't have the placement of the vertical scrollbar in the packet list pane different than the placement in the protocol tree pane, for example). I did this because I find it convenient to have the vertical scrollbars on the *left* side of the text. My mouse cursor is usually expanding and collapsing the protocol tree widgets, and once the protocol tree changes size, I usually have to scroll. I'd rather move my mouse cursor just a few pixels over to find the vertical scrollbar. svn path=/trunk/; revision=1351