nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 09:58:01 +00:00
Code Issues Projects Releases Wiki Activity
c1a4eda9f6
putty-source/unix/utils/our_dialog.c

136 lines
4.9 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
/*
* 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.
*/
Break up gtkmisc.c. It's another file that should have been subdivided into lots of tiny separate things in the utils library - especially since for some reason I made a completely separate 'guimisc' cmake-level library for it when there was no need.
2021-04-24 06:51:15 +00:00
#include <gtk/gtk.h>
#include "putty.h"
#include "gtkcompat.h"
#include "gtkmisc.h"
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
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
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
gtk_box_pack_start(
GTK_BOX(gtk_dialog_get_content_area(GTK_DIALOG(dlg))),
w, expand, fill, 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
#endif
}
Reference in New Issue Copy Permalink