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
0.82
putty-source/unix/config-gtk.c

161 lines
5.9 KiB
C
Raw Permalink Normal View History

Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
/*
Update source file names in comments and docs. Correcting a source file name in the docs just now reminded me that I've seen a lot of outdated source file names elsewhere in the code, due to all the reorganisation since we moved to cmake. Here's a giant pass of trying to make them all accurate again.
2022-01-22 15:38:53 +00:00
* config-gtk.c - the GTK-specific parts of the PuTTY configuration
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
* box.
*/
#include <assert.h>
#include <stdlib.h>
#include "putty.h"
#include "dialog.h"
#include "storage.h"
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
static void about_handler(dlgcontrol *ctrl, dlgparam *dlg,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
void *data, int event)
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
{
if (event == EVENT_ACTION) {
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
about_box(ctrl->context.p);
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
}
}
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
void gtk_setup_config_box(struct controlbox *b, bool midsession, void *win)
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
{
struct controlset *s, *s2;
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
dlgcontrol *c;
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
int i;
if (!midsession) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Add the About button to the standard panel.
*/
s = ctrl_getset(b, "", "", "");
c = ctrl_pushbutton(s, "About", 'a', HELPCTX(no_help),
about_handler, P(win));
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
c->column = 0;
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
}
/*
* GTK makes it rather easier to put the scrollbar on the left
* than Windows does!
*/
s = ctrl_getset(b, "Window", "scrollback",
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"Control the scrollback in the window");
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
ctrl_checkbox(s, "Scrollbar on left", 'l',
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HELPCTX(no_help),
conf_checkbox_handler,
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
I(CONF_scrollbar_on_left));
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
/*
* Really this wants to go just after `Display scrollbar'. See
* if we can find that control, and do some shuffling.
*/
for (i = 0; i < s->ncontrols; i++) {
c = s->ctrls[i];
Restructure dlgcontrol as a struct with an anon union. This gets rid of that awkward STANDARD_PREFIX system in which every branch of the old 'union control' had to repeat all the generic fields, and then call sites had to make an arbitrary decision about which branch to access them through. That was the best we could do before accepting C99 features in this code base. But now we have anonymous unions, so we don't need to put up with that nonsense any more! 'dlgcontrol' is now a struct rather than a union, and the generic fields common to all control types are ordinary members of the struct, so you don't have to refer to them as ctrl->generic.foo at all, just ctrl->foo, which saves verbiage at the point of use. The extra per-control fields are still held in structures named after the control type, so you'll still say ctrl->listbox.height or whatever. But now those structures are themselves members of an anonymous union field following the generic fields, so those sub-structures don't have to reiterate all the standard stuff too. While I'm here, I've promoted 'context2' from an editbox-specific field to a generic one (it just seems silly _not_ to allow any control to have two context fields if it needs it). Also, I had to rename the boolean field 'tabdelay' to avoid it clashing with the subsidiary structure field 'tabdelay', now that the former isn't generic.tabdelay any more.
2022-05-01 08:55:52 +00:00
if (c->type == CTRL_CHECKBOX &&
c->context.i == CONF_scrollbar) {
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
/*
* Control i is the scrollbar checkbox.
* Control s->ncontrols-1 is the scrollbar-on-left one.
*/
if (i < s->ncontrols-2) {
c = s->ctrls[s->ncontrols-1];
memmove(s->ctrls+i+2, s->ctrls+i+1,
New typedef 'dlgcontrol' wrapping 'union control'. I'm about to change my mind about whether its top-level nature is struct or union, and rather than change the key word 'union' to 'struct' at every point of use, it's nicer to just get rid of the keyword completely. So it has a shiny new name.
2022-05-01 08:48:38 +00:00
(s->ncontrols-i-2)*sizeof(dlgcontrol *));
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
s->ctrls[i+1] = c;
}
break;
}
}
/*
* X requires three more fonts: bold, wide, and wide-bold; also
* we need the fiddly shadow-bold-offset control. This would
* make the Window/Appearance panel rather unwieldy and large,
* so I think the sensible thing here is to _move_ this
* controlset into a separate Window/Fonts panel!
*/
s2 = ctrl_getset(b, "Window/Appearance", "font",
"Font settings");
/* Remove this controlset from b. */
for (i = 0; i < b->nctrlsets; i++) {
if (b->ctrlsets[i] == s2) {
memmove(b->ctrlsets+i, b->ctrlsets+i+1,
(b->nctrlsets-i-1) * sizeof(*b->ctrlsets));
b->nctrlsets--;
Fix two small memory leaks in config mechanism. The memory dangling off ssd->sesslist should be freed when ssd itself goes away, and the font settings ctrlset we delete in gtkcfg.c should be freed as well once it's been removed from its containing array. Thanks to Ranjini Aravind for pointing these out.
2015-05-08 17:57:18 +00:00
ctrl_free_set(s2);
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
break;
}
}
ctrl_settitle(b, "Window/Fonts", "Options controlling font usage");
s = ctrl_getset(b, "Window/Fonts", "font",
"Fonts for displaying non-bold text");
ctrl_fontsel(s, "Font used for ordinary text", 'f',
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HELPCTX(no_help),
conf_fontsel_handler, I(CONF_font));
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
ctrl_fontsel(s, "Font used for wide (CJK) text", 'w',
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HELPCTX(no_help),
conf_fontsel_handler, I(CONF_widefont));
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
s = ctrl_getset(b, "Window/Fonts", "fontbold",
"Fonts for displaying bolded text");
ctrl_fontsel(s, "Font used for bolded text", 'b',
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HELPCTX(no_help),
conf_fontsel_handler, I(CONF_boldfont));
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
ctrl_fontsel(s, "Font used for bold wide text", 'i',
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HELPCTX(no_help),
conf_fontsel_handler, I(CONF_wideboldfont));
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
ctrl_checkbox(s, "Use shadow bold instead of bold fonts", 'u',
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HELPCTX(no_help),
conf_checkbox_handler,
I(CONF_shadowbold));
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
ctrl_text(s, "(Note that bold fonts or shadow bolding are only"
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
" used if you have not requested bolding to be done by"
" changing the text colour.)",
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
HELPCTX(no_help));
ctrl_editbox(s, "Horizontal offset for shadow bold:", 'z', 20,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HELPCTX(no_help), conf_editbox_handler,
Replace integer context2 encoding in conf_editbox_handler. I was just about to add another ordinary edit box control, and found I couldn't remember what went in the context2 argument to conf_editbox. When I looked it up, I realised it was one of those horrid integer encodings of the form '1 means this, -1 means that, less than -1 means some parametrised property where the parameter is obtained by negating the encoded integer'. Those are always awkward to remember, and worse to extend. So I've replaced the integer context2 used with conf_editbox_handler with a pointer to a small struct type in which the types and parameters have sensible names and are documented. (To avoid annoying const warnings everywhere, this also meant extending the 'intorptr' union to have a const void * branch as well as a 'void *'. Surprised I haven't needed that before. But if I introduce any more of these parameter structures, it'll come in useful again.)
2022-08-24 06:56:45 +00:00
I(CONF_shadowboldoffset), ED_INT);
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
/*
* Markus Kuhn feels, not totally unreasonably, that it's good
* for all applications to shift into UTF-8 mode if they notice
* that they've been started with a LANG setting dictating it,
* so that people don't have to keep remembering a separate
* UTF-8 option for every application they use. Therefore,
* here's an override option in the Translation panel.
*/
s = ctrl_getset(b, "Window/Translation", "trans",
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"Character set translation on received data");
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
ctrl_checkbox(s, "Override with UTF-8 if locale says so", 'l',
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HELPCTX(translation_utf8_override),
conf_checkbox_handler,
I(CONF_utf8_override));
Allow setting the WM_CLASS X window property as a configuration option in saved sessions, so that a programmable window manager can distinguish different PuTTYs/pterms on startup and assign them different window management properties. [originally from svn r9078]
2011-01-15 11:39:44 +00:00
On OS X, be able to configure either Option or Command as Meta. Personally I like using Command as the Esc-prefixing Meta key in terminal sessions, because it occupies the same physical keyboard position as the Alt key that I'm used to using on non-Macs. OS X Terminal uses Option for that purpose (freeing up Command for the conventional Mac keyboard shortcuts, of course), so I anticipate differences of opinion. Hence, here's a pair of OSX-specific config options which permit a user to set either, or neither, or both of those modifier keys to function as the terminal Meta key.
2015-09-01 18:00:25 +00:00
#ifdef OSX_META_KEY_CONFIG
/*
* On OS X, there are multiple reasonable opinions about whether
* Option or Command (or both, or neither) should act as a Meta
* key, or whether they should have their normal OS functions.
*/
s = ctrl_getset(b, "Terminal/Keyboard", "meta",
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"Choose the Meta key:");
On OS X, be able to configure either Option or Command as Meta. Personally I like using Command as the Esc-prefixing Meta key in terminal sessions, because it occupies the same physical keyboard position as the Alt key that I'm used to using on non-Macs. OS X Terminal uses Option for that purpose (freeing up Command for the conventional Mac keyboard shortcuts, of course), so I anticipate differences of opinion. Hence, here's a pair of OSX-specific config options which permit a user to set either, or neither, or both of those modifier keys to function as the terminal Meta key.
2015-09-01 18:00:25 +00:00
ctrl_checkbox(s, "Option key acts as Meta", 'p',
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HELPCTX(no_help),
conf_checkbox_handler, I(CONF_osx_option_meta));
On OS X, be able to configure either Option or Command as Meta. Personally I like using Command as the Esc-prefixing Meta key in terminal sessions, because it occupies the same physical keyboard position as the Alt key that I'm used to using on non-Macs. OS X Terminal uses Option for that purpose (freeing up Command for the conventional Mac keyboard shortcuts, of course), so I anticipate differences of opinion. Hence, here's a pair of OSX-specific config options which permit a user to set either, or neither, or both of those modifier keys to function as the terminal Meta key.
2015-09-01 18:00:25 +00:00
ctrl_checkbox(s, "Command key acts as Meta", 'm',
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HELPCTX(no_help),
conf_checkbox_handler, I(CONF_osx_command_meta));
On OS X, be able to configure either Option or Command as Meta. Personally I like using Command as the Esc-prefixing Meta key in terminal sessions, because it occupies the same physical keyboard position as the Alt key that I'm used to using on non-Macs. OS X Terminal uses Option for that purpose (freeing up Command for the conventional Mac keyboard shortcuts, of course), so I anticipate differences of opinion. Hence, here's a pair of OSX-specific config options which permit a user to set either, or neither, or both of those modifier keys to function as the terminal Meta key.
2015-09-01 18:00:25 +00:00
#endif
Allow setting the WM_CLASS X window property as a configuration option in saved sessions, so that a programmable window manager can distinguish different PuTTYs/pterms on startup and assign them different window management properties. [originally from svn r9078]
2011-01-15 11:39:44 +00:00
if (!midsession) {
/*
* Allow the user to specify the window class as part of the saved
* configuration, so that they can have their window manager treat
* different kinds of PuTTY and pterm differently if they want to.
*/
s = ctrl_getset(b, "Window/Behaviour", "x11",
"X Window System settings");
ctrl_editbox(s, "Window class name:", 'z', 50,
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
HELPCTX(no_help), conf_editbox_handler,
Replace integer context2 encoding in conf_editbox_handler. I was just about to add another ordinary edit box control, and found I couldn't remember what went in the context2 argument to conf_editbox. When I looked it up, I realised it was one of those horrid integer encodings of the form '1 means this, -1 means that, less than -1 means some parametrised property where the parameter is obtained by negating the encoded integer'. Those are always awkward to remember, and worse to extend. So I've replaced the integer context2 used with conf_editbox_handler with a pointer to a small struct type in which the types and parameters have sensible names and are documented. (To avoid annoying const warnings everywhere, this also meant extending the 'intorptr' union to have a const void * branch as well as a 'void *'. Surprised I haven't needed that before. But if I introduce any more of these parameter structures, it'll come in useful again.)
2022-08-24 06:56:45 +00:00
I(CONF_winclass), ED_STR);
Allow setting the WM_CLASS X window property as a configuration option in saved sessions, so that a programmable window manager can distinguish different PuTTYs/pterms on startup and assign them different window management properties. [originally from svn r9078]
2011-01-15 11:39:44 +00:00
}
Saw uxcfg.c in half down the middle, to separate out config changes that apply to all Unix-like systems from those which apply specifically to the GTK front end. [originally from svn r5292]
2005-02-14 07:41:41 +00:00
}
Reference in New Issue Copy Permalink