nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
3c6ab5bbb7
putty-source/unix/gtkmisc.c

224 lines
7.0 KiB
C
Raw Normal View History

Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
/*
* Miscellaneous GTK helper functions.
*/
#include <assert.h>
#include <stdarg.h>
#include <ctype.h>
#include <time.h>
#include <gtk/gtk.h>
#if !GTK_CHECK_VERSION(3,0,0)
#include <gdk/gdkkeysyms.h>
#endif
#include "putty.h"
#include "gtkcompat.h"
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
#ifndef NOT_X_WINDOWS
#include <gdk/gdkx.h>
#include <X11/Xlib.h>
#endif
Move more functions into the new gtkmisc.c. Several utility functions I've written over the last few weeks were in rather random places because I didn't have a central gtkmisc.c to put them in. Now I've got one, put them there!
2015-08-31 14:44:24 +00:00
void get_label_text_dimensions(const char *text, int *width, int *height)
{
/*
* Determine the dimensions of a piece of text in the standard
* font used in GTK interface elements like labels. We do this by
* instantiating an actual GtkLabel, and then querying its size.
*
* But GTK2 and GTK3 require us to query the size completely
* differently. I'm sure there ought to be an easier approach than
* the way I'm doing this in GTK3, too!
*/
GtkWidget *label = gtk_label_new(text);
#if GTK_CHECK_VERSION(3,0,0)
PangoLayout *layout = gtk_label_get_layout(GTK_LABEL(label));
PangoRectangle logrect;
pango_layout_get_extents(layout, NULL, &logrect);
if (width)
*width = logrect.width / PANGO_SCALE;
if (height)
*height = logrect.height / PANGO_SCALE;
#else
GtkRequisition req;
gtk_widget_size_request(label, &req);
if (width)
*width = req.width;
if (height)
*height = req.height;
#endif
g_object_ref_sink(G_OBJECT(label));
#if GTK_CHECK_VERSION(2,10,0)
g_object_unref(label);
#endif
}
int string_width(const char *text)
{
int ret;
get_label_text_dimensions(text, &ret, NULL);
return ret;
}
void align_label_left(GtkLabel *label)
{
#if GTK_CHECK_VERSION(3,16,0)
gtk_label_set_xalign(label, 0.0);
Implement align_label_left for GTK 3.[14,16). gtk_misc_set_alignment was deprecated in GTK 3.14. But my replacement code using gtk_label_set_xalign doesn't work there, because that function wasn't introduced until GTK 3.16, so there are two minor versions in the middle where a third strategy is needed.
2015-11-22 21:47:21 +00:00
#elif GTK_CHECK_VERSION(3,14,0)
gtk_widget_set_halign(GTK_WIDGET(label), GTK_ALIGN_START);
Move more functions into the new gtkmisc.c. Several utility functions I've written over the last few weeks were in rather random places because I didn't have a central gtkmisc.c to put them in. Now I've got one, put them there!
2015-08-31 14:44:24 +00:00
#else
gtk_misc_set_alignment(GTK_MISC(label), 0.0, 0.0);
#endif
}
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
/* ----------------------------------------------------------------------
* Functions to arrange controls in a basically dialog-like window.
*
* The best method for doing this has varied wildly with versions of
* GTK, hence the set of wrapper functions here.
*
* In GTK 1, a GtkDialog has an 'action_area' at the bottom, which is
* a GtkHBox which stretches to cover the full width of the dialog. So
* we can either add buttons or other widgets to that box directly, or
* alternatively we can fill the hbox with some layout class of our
* own such as a Columns widget.
*
* In GTK 2, the action area has become a GtkHButtonBox, and its
* layout behaviour seems to be different and not what we want. So
* instead we abandon the dialog's action area completely: we
* gtk_widget_hide() it in the below code, and we also call
* gtk_dialog_set_has_separator() to remove the separator above it. We
* then insert our own action area into the end of the dialog's main
* vbox, and add our own separator above that.
*
* In GTK 3, we typically don't even want to use GtkDialog at all,
* because GTK 3 has become a lot more restrictive about what you can
* sensibly use GtkDialog for - it deprecates direct access to the
* action area in favour of making you provide nothing but
* dialog-ending buttons in the form of (text, response code) pairs,
* so you can't put any other kind of control in there, or fiddle with
* alignment and positioning, or even have a button that _doesn't_ end
* the dialog (e.g. 'View Licence' in our About box). So instead of
* GtkDialog, we use a straight-up GtkWindow and have it contain a
* vbox as its (unique) child widget; and we implement the action area
* by adding a separator and another widget at the bottom of that
* vbox.
*/
GtkWidget *our_dialog_new(void)
{
#if GTK_CHECK_VERSION(3,0,0)
/*
* See comment in our_dialog_set_action_area(): in GTK 3, we use
* GtkWindow in place of GtkDialog for most purposes.
*/
GtkWidget *w = gtk_window_new(GTK_WINDOW_TOPLEVEL);
GtkWidget *vbox = gtk_box_new(GTK_ORIENTATION_VERTICAL, 8);
gtk_container_add(GTK_CONTAINER(w), vbox);
gtk_widget_show(vbox);
return w;
#else
return gtk_dialog_new();
#endif
}
void our_dialog_set_action_area(GtkWindow *dlg, GtkWidget *w)
{
#if !GTK_CHECK_VERSION(2,0,0)
gtk_box_pack_start(GTK_BOX(GTK_DIALOG(dlg)->action_area),
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
w, true, true, 0);
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
#elif !GTK_CHECK_VERSION(3,0,0)
GtkWidget *align;
align = gtk_alignment_new(0, 0, 1, 1);
gtk_container_add(GTK_CONTAINER(align), w);
/*
* The purpose of this GtkAlignment is to provide padding
* around the buttons. The padding we use is twice the padding
* used in our GtkColumns, because we nest two GtkColumns most
* of the time (one separating the tree view from the main
* controls, and another for the main controls themselves).
*/
#if GTK_CHECK_VERSION(2,4,0)
gtk_alignment_set_padding(GTK_ALIGNMENT(align), 8, 8, 8, 8);
#endif
gtk_widget_show(align);
gtk_box_pack_end(GTK_BOX(gtk_dialog_get_content_area(GTK_DIALOG(dlg))),
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
align, false, true, 0);
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
w = gtk_hseparator_new();
gtk_box_pack_end(GTK_BOX(gtk_dialog_get_content_area(GTK_DIALOG(dlg))),
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
w, false, true, 0);
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
gtk_widget_show(w);
gtk_widget_hide(gtk_dialog_get_action_area(GTK_DIALOG(dlg)));
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
g_object_set(G_OBJECT(dlg), "has-separator", true, (const char *)NULL);
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
#else /* GTK 3 */
/* GtkWindow is a GtkBin, hence contains exactly one child, which
* here we always expect to be a vbox */
GtkBox *vbox = GTK_BOX(gtk_bin_get_child(GTK_BIN(dlg)));
Fix misplaced separator in GTK3 dialog boxes. When I abandoned GtkDialog for GtkWindow (in dc11417ae), I manually added a horizontal GtkSeparator between the content and action areas. Or rather, I tried to - but I forgot that gtk_box_pack_end works in the opposite order, so that you have to add the bottom-most element first and then the one you want to appear above it. So my separator was below the action area, rather than between it and the content area.
2015-09-25 09:05:57 +00:00
GtkWidget *sep;
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
g_object_set(G_OBJECT(w), "margin", 8, (const char *)NULL);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_box_pack_end(vbox, w, false, true, 0);
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
Fix misplaced separator in GTK3 dialog boxes. When I abandoned GtkDialog for GtkWindow (in dc11417ae), I manually added a horizontal GtkSeparator between the content and action areas. Or rather, I tried to - but I forgot that gtk_box_pack_end works in the opposite order, so that you have to add the bottom-most element first and then the one you want to appear above it. So my separator was below the action area, rather than between it and the content area.
2015-09-25 09:05:57 +00:00
sep = gtk_hseparator_new();
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_box_pack_end(vbox, sep, false, true, 0);
Fix misplaced separator in GTK3 dialog boxes. When I abandoned GtkDialog for GtkWindow (in dc11417ae), I manually added a horizontal GtkSeparator between the content and action areas. Or rather, I tried to - but I forgot that gtk_box_pack_end works in the opposite order, so that you have to add the bottom-most element first and then the one you want to appear above it. So my separator was below the action area, rather than between it and the content area.
2015-09-25 09:05:57 +00:00
gtk_widget_show(sep);
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
#endif
}
GtkBox *our_dialog_make_action_hbox(GtkWindow *dlg)
{
#if GTK_CHECK_VERSION(3,0,0)
GtkWidget *hbox = gtk_box_new(GTK_ORIENTATION_HORIZONTAL, 0);
our_dialog_set_action_area(dlg, hbox);
GTK 3 fake dialog action area: fix margins and spacing. The About box is where it showed up most obviously that I'd hastily bunged a GtkBox inside another GtkBox without considering their margins: the 'action area' had twice the margin it should have had and the rightmost button didn't align with the right edge of the rest of the window contents. Easily fixed by giving the inner hbox margin 0 (fixing the right align and the excessive space around all the buttons), and using the 'spacing' property of GtkBox to ensure multiple buttons in it are nicely separated without having to take care over that in the client code that adds them.
2016-03-24 07:19:09 +00:00
g_object_set(G_OBJECT(hbox), "margin", 0, (const char *)NULL);
g_object_set(G_OBJECT(hbox), "spacing", 8, (const char *)NULL);
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
gtk_widget_show(hbox);
return GTK_BOX(hbox);
#else /* not GTK 3 */
return GTK_BOX(gtk_dialog_get_action_area(GTK_DIALOG(dlg)));
#endif
}
void our_dialog_add_to_content_area(GtkWindow *dlg, GtkWidget *w,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool expand, bool fill, guint padding)
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
{
#if GTK_CHECK_VERSION(3,0,0)
/* GtkWindow is a GtkBin, hence contains exactly one child, which
* here we always expect to be a vbox */
GtkBox *vbox = GTK_BOX(gtk_bin_get_child(GTK_BIN(dlg)));
gtk_box_pack_start(vbox, w, expand, fill, padding);
#else
gtk_box_pack_start
(GTK_BOX(gtk_dialog_get_content_area(GTK_DIALOG(dlg))),
w, expand, fill, padding);
#endif
}
Include the compile-time GTK version in the build info. It's obvious to the trained eye whether GTK PuTTY was compiled against GTK2 or GTK3, but the untrained eye would probably appreciate a little help, and even the trained eye probably can't tell GTK 3.18 from 3.19 at a glance :-)
2017-02-15 19:29:05 +00:00
char *buildinfo_gtk_version(void)
{
return dupprintf("%d.%d.%d",
GTK_MAJOR_VERSION, GTK_MINOR_VERSION, GTK_MICRO_VERSION);
}
Basic support for running under GDK Wayland back end. GTK 3 PuTTY/pterm has always assumed that if it was compiled with _support_ for talking to the raw X11 layer underneath GTK and GDK, then it was entitled to expect that raw X11 layer to exist at all times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X display that it could do useful things with. So if you ran it over the GDK Wayland backend, it would immediately segfault. Modern GTK applications need to cope with multiple GDK backends at run time. It's fine for GTK PuTTY to _contain_ the code to find and use underlying X11 primitives like the display and the X window id, but it should be prepared to find that it's running on Wayland (or something else again!) so those functions don't return anything useful - in which case it should degrade gracefully to the subset of functionality that can be accessed through backend-independent GTK calls. Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a support function get_x_display() in gtkmisc.c, which starts by checking that there actually is one first. All previous direct uses of GDK_*_XDISPLAY now go via that function, and check the result for NULL afterwards. (To save faffing about calling that function too many times, I'm also caching the display pointer in more places, and passing it as an extra argument to various subfunctions, mostly in gtkfont.c.) Similarly, the get_windowid() function that retrieves the window id to put in the environment of pterm's child process has to be prepared for there not to be a window id. This isn't a complete fix for all Wayland-related problems. The other one I'm currently aware of is that the default font is "server:fixed", which is a bad default now that it won't be available on all backends. And I expect that further problems will show up with more testing. But it's a start.
2018-05-09 08:18:20 +00:00
#ifndef NOT_X_WINDOWS
Display *get_x11_display(void)
{
#if GTK_CHECK_VERSION(3,0,0)
if (!GDK_IS_X11_DISPLAY(gdk_display_get_default()))
return NULL;
#endif
return GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
}
#endif
Reference in New Issue Copy Permalink