This is mostly easy: it's just like drawing an underline, except that
you put it at a different height in the character cell. The only
question is _where_ in the character cell.
Pango, and Windows GetOutlineTextMetrics, will tell you exactly where
the font wants to have it. Following xterm, I fall back to 3/8 of the
font's ascent (above the baseline) if either of those is unavailable.
Colin reports that on betas of Ubuntu 20.04, Pango has switched to
getting its font metrics from HarfBuzz, and a side effect is
apparently that they're being returned in the full precision of
PANGO_SCALE fixed point.
Previously, Pango appears to have been returning values that were
always a whole number of pixels scaled by PANGO_SCALE. Moreover, it
looks as if it was rounding the font ascent and descent _up_ to a
whole number of pixels, rather than rounding to nearest. But our code
rounds to nearest, which means that now the same font gets allocated
fewer vertical pixels, which can be enough to cut off some ascenders
or descenders.
Pango already provides the macro PANGO_PIXELS_CEIL, so it's easy to
switch over to using it. This should arrange that any text that fits
within the font's stated ascent/descent measurements will also fit in
the character cell.
This is a sweeping change applied across the whole code base by a spot
of Emacs Lisp. Now, everywhere I declare a vtable filled with function
pointers (and the occasional const data member), all the members of
the vtable structure are initialised by name using the '.fieldname =
value' syntax introduced in C99.
We were already using this syntax for a handful of things in the new
key-generation progress report system, so it's not new to the code
base as a whole.
The advantage is that now, when a vtable only declares a subset of the
available fields, I can initialise the rest to NULL or zero just by
leaving them out. This is most dramatic in a couple of the outlying
vtables in things like psocks (which has a ConnectionLayerVtable
containing only one non-NULL method), but less dramatically, it means
that the new 'flags' field in BackendVtable can be completely left out
of every backend definition except for the SUPDUP one which defines it
to a nonzero value. Similarly, the test_for_upstream method only used
by SSH doesn't have to be mentioned in the rest of the backends;
network Plugs for listening sockets don't have to explicitly null out
'receive' and 'sent', and vice versa for 'accepting', and so on.
While I'm at it, I've normalised the declarations so they don't use
the unnecessarily verbose 'struct' keyword. Also a handful of them
weren't const; now they are.
When I came to actually remove the global 'flags' word, I found that I
got compile failures in two functions that should never have been
accessing it at all, because they forgot to declare _local_ variables
of the same name. Yikes!
(Of course, _now_ that's harmless, because I've just removed all the
actual semantics from the global variable. But I'm about to remove the
variable too, so these bugs would become compile failures.)
Up until now, it's been a variadic _function_, whose argument list
consists of 'const char *' ASCIZ strings to concatenate, terminated by
one containing a null pointer. Now, that function is dupcat_fn(), and
it's wrapped by a C99 variadic _macro_ called dupcat(), which
automatically suffixes the null-pointer terminating argument.
This has three benefits. Firstly, it's just less effort at every call
site. Secondly, it protects against the risk of accidentally leaving
off the NULL, causing arbitrary words of stack memory to be
dereferenced as char pointers. And thirdly, it protects against the
more subtle risk of writing a bare 'NULL' as the terminating argument,
instead of casting it explicitly to a pointer. That last one is
necessary because C permits the macro NULL to expand to an integer
constant such as 0, so NULL by itself may not have pointer type, and
worse, it may not be marshalled in a variadic argument list in the
same way as a pointer. (For example, on a 64-bit machine it might only
occupy 32 bits. And yet, on another 64-bit platform, it might work
just fine, so that you don't notice the mistake!)
I was inspired to do this by happening to notice one of those bare
NULL terminators, and thinking I'd better check if there were any
more. Turned out there were quite a few. Now there are none.
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.
uxnet.c's sk_namelookup and the sorting-key construction in
pangofont_enum_fonts() were both using s[n]printf and strncpy into
buffers that had no real need to be fixed-size; format_telnet_command
and the GTK Event Log selection-data builder were doing their own
sresize loops, but now we have strbuf they can just use that and save
redoing the same work.
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'!
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.
x11_char_struct returns a pointer or NULL, so while returning FALSE
would have ended up doing the right thing after macro expansion and
integer->pointer conversion, it wasn't actually how I _meant_ to spell
a failure return.
It's never set to anything but NULL at any call site, and there's been
a FIXME comment in uxucs.c for ages saying it should be removed. I
think it only existed in the first place because it was a facility
supported by the underlying Windows API function and we couldn't see a
reason _not_ to pass it through. But I'm cleaning up FIXMEs, so we
should get rid of it.
(It stood for 'default used', incidentally - as in 'did the function
at any point have to make use of the parameter providing a default
fallback character?'. Nothing to do with _defusing_ things :-)
Ian Jackson points out that the Linux kernel has a macro of this name
with the same purpose, and suggests that it's a good idea to use the
same name as they do, so that at least some people reading one code
base might recognise it from the other.
I never really thought very hard about what order FROMFIELD's
parameters should go in, and therefore I'm pleasantly surprised to
find that my order agrees with the kernel's, so I don't have to
permute every call site as part of making this change :-)
Now that I'm doing that in so many of the new classes as a more
type-safe alternative to ordinary C casts, I should make sure all the
old code is also reaping the benefits. This commit converts the system
of unifont vtables in the GTK front end, and also the 'unifontsel'
structure that exposes only a few of its fields outside gtkfont.c.
This formalises my occasional habit of using a single malloc to make a
block that contains a header structure and a data buffer that a field
of the structure will point to, allowing it to be freed in one go
later. Previously I had to do this by hand, losing the type-checking
advantages of snew; now I've written an snew-style macro to do the
job, plus an accessor macro to cleanly get the auxiliary buffer
pointer afterwards, and switched existing instances of the pattern
over to using that.
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.
I had mistakenly pulled a 'char' value out of a string and passed it
to x11_font_has_glyph and x11_char_struct, each of which takes its two
index bytes as int-typed parameters. But if chars are signed, that
turns high-bit-set characters into out-of-range array indices. Oops.
The range checks in x11_char_struct prevented that from causing any
problem worse than refusal to display any affected glyph. Even so,
that's not particularly helpful. Fixed by changing the index byte
parameters to unsigned char type.
The new font name configured by the keystrokes was missing its
"client:" or "server:" prefix, which could have led to the selection
of the wrong font in rare situations.
Each gtkfont back end now provides a routine that will return the name
of a similar font to the current one but one notch larger or smaller.
For Pango, this is just a matter of incrementing the font size field
in a standard way; for X11 server-side fonts, we have to go and do an
XListFonts query with a wildcard that requests fonts that vary only in
the size fields from the current one, and then iterate over the result
looking for the best one.
(I expect this will be more useful to Pango scalable-font users than
to X11 fonts, but it seemed a shame not to give the X11 side my best
shot while I was at it.)
Choice of hotkey: I know I'm being inconsistent with gnome-terminal's
use of Ctrl-plus and Ctrl-minus. I thought that was because I was
already using Ctrl-minus as a more convenient synonym for
Ctrl-underscore (which sends the actual control code 0x1F), but now I
actually try it, apparently I'm not. However, Ctrl-plus and Ctrl-minus
are quite horrible as a keystroke pair anyway (one has to be typed
with shift and one without!), and I feel as if the 'less' and
'greater' signs are more specific anyway, in that they specifically
indicate _size_ rather than just 'unspecified numerical value'.
There were already two places in the code (x11font_enum_fonts and
x11_guess_derived_font_name) where we retrieved an XLFD from the X
server, sawed it up ad-hoc into its '-'-separated parts and accessed
them by numeric index.
I'm about to add a third, so before I do, let's turn this into a
somewhat principled system where we get to do the decode/encode in
just one place and call all the individual fields by names that are
actually memorable.
No functional change intended by this commit.
When we're displaying bidirectionally active text (that is, text that
the Unicode bidi algorithm will fiddle with), we need to suppress
Pango's bidi because we've already done our own. We were doing this by
calling is_rtl() on each character, and if it returned true,
displaying just that character in a separate Pango call.
Except that, ahem, we were only doing this if the _first_ character
encountered during a scan of the display buffer was rtl-sensitive. If
the first one was fine but a subsequent one was rtl-sensitive, then
that one would just get shoved into the buffer we'd already started.
Running pterm -fn 'client:Monospace 12' and displaying
testdata/utf8.txt now works again.
When I cut it in half so I could fetch the XCharStruct for a given
character, I forgot that the remaining half should check whether it
had got NULL from the XCharStruct finder. Ahem.
I had completely forgotten, when rendering each glyph to a server-side
pixmap and downloading its contents, to only look at the part of the
pixmap that XDrawImageString would have overwritten, as specified by
the metrics in the XCharStruct. Now 'pterm -fn server:variable'
doesn't randomly make up bitmap nonsense outside each character's
bounding rectangle.
When displaying a server-side font, the unified font selector's
font-style list box contains some lines which are character-set
headings, and others which are actually selectable font styles. We tag
the former with the "sensitive"=FALSE attribute, to prevent them from
responding to clicks. In GTK2, this also made them visually distinct
from the normal lines, by greying them out; in GTK3 it makes no visual
difference.
The simplest solution is to bold those lines, hinting that they're
sort of section headings. That looks OK in GTK2 as well, so I've done
it unconditionally.
The top-level loop in gtkwin.c which draws text was expecting that the
right way to draw a printing character plus combining characters was
to overprint them one by one on top of each other. This is an OK
assumption for X bitmap fonts, but in Pango, it works very badly -
most obviously because asking Pango to display a combining char on its
own causes it to print a dotted circle representing the base char, but
also because surely there will be character combinations where Pango
wants to do something more sophisticated than just printing them each
at a standard offset, and it would be a shame not to let it.
So I've moved the previous overprinting loop down into the x11font
subclass of the unifont mechanism. The top-level gtkwin.c drawing code
now calls a new method unifont_draw_combining, which in the X11 case
does the same loop as before, but in the Pango case, just passes a
whole base+combinings string to Pango in one go and lets it do the
best job it can.
By retrieving characters' widths using get_extents and not
get_pixel_extents, we can spot when they're not actually an exact
multiple of a pixel, and avoid getting confused by the overall width
of a long string being off by up to a pixel per character.
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!
We were using it in the main config box to ensure everything expanded
on window resize, but in GTK3 that's the default anyway. And we were
using it to put padding around the edges of the font selector, which
is now done using the "margin" property.
If we're not supporting server-side fonts, it's utterly silly to set
one as the default! Instead, we use Pango's guarantee that some
reasonably sensible monospaced font will be made available under the
name "Monospace", and use that at a reasonable default size of 12pt.
Using GTK to run on OS X is going to require several workarounds and
behaviour tweaks to be enabled at various points in the code, and it's
already getting cumbersome to remember what they all are to put on the
command line. Here's a central #define (OSX_GTK) that enables them all
in one go, and a configure option (--with-quartz) that sets it.
As part of this commit, I've also rearranged the #include order in the
GTK source files, so that they include unix.h (which now might be
where NOT_X_WINDOWS gets defined) before they test NOT_X_WINDOWS to
decide whether to include X11 headers.
The whole of get_label_text_dimensions() should have been outside the
GTK 2 ifdef; I'd left a gtk_label_set_width_chars() unconditional; and
GDK1's gdk_window_set_background() lacks a const in its prototype.
Serves me right for not test-compiling in all three versions!
This was another piece of code that determined text size by
instantiating a GtkLabel and asking for its size, which I had to fix
in gtkfont.c recently because that strategy doesn't work in GTK3.
Replaced the implementation of string_width() with a call to the
function I added in gtkfont.c, and now dialog boxes which depend on
that for their width measurement (e.g. the one in reallyclose()) don't
come out in silly sizes on GTK3 any more.
Profiling reveals that pterm in Pango rendering mode uses an absurd
amount of CPU when it's not even actually _drawing_ the text, because
of all the calls to pango_layout_get_pixel_extents() while
pangofont_draw_text tries to work out which characters it can safely
draw as part of a long string. Caching the results speeds things up
greatly.
If you're trying to arrange that an array size is large enough for
element n to exist, and you also want to round it up to the next
multiple of 0x100, you must set the size to (n + 0x100) & ~0xFF, and
not (n + 0xFF) & ~0xFF. Put another way, the number you have to round
up is not n, but the minimum size n+1 that causes array[n] to exist.
GtkTable is deprecated; the way of the future is GtkGrid, in which you
don't have to specify the number of rows/columns in advance (it's
worked out dynamically by observing what row/column numbers you
actually attached anything to), and also you handle expansion
behaviour by setting the "hexpand", "vexpand" or "expand" properties
on the child widgets rather than setting flags in the container.
In the case where we deselect the previously selected font (e.g.
because we've just changed the filter settings to remove it from the
list), we were leaving the preview pane in its previous state, which
is fine in GTK2 when it just carries on displaying the last thing
drawn to the backing pixmap but goes wrong in GTK3 where we still have
to actually respond to draw events.
But it makes more conceptual sense anyway to actually empty the
preview pane when no font is selected, so now we do that. So now
unifontsel_draw_preview_text() is called from unifontsel_deselect(),
and also the preview-drawing code will still draw the background
rectangle regardless of whether font != NULL.
The call to gtk_list_store_clear() in unifontsel_setup_familylist()
was causing a call to family_changed() via the GTK signal system,
which didn't happen in GTK2. family_changed() in turn was calling
unifontsel_select_font(), which got confused when the tree model
didn't match reality, and tried to access a bogus tree iterator.
This is easily fixed by using the existing fs->inhibit_response flag,
which prevents us responding to GTK events when we know they were
generated by our own fiddling about with the data; it's just that we
never needed to set it in unifontsel_setup_familylist() before.
Also, added a check of the return value from the key get_iter call in
unifontsel_select_font(), so that it'll at least fail an assertion
rather than actually trying to access bogus memory. But that operation
_should_ still always succeed, and if it doesn't, it's probably a sign
that we need another use of fs->inhibit_response.
It turns out that in GTK3, if you instantiate a GtkLabel and
immediately try to find out its preferred size, you get back zero for
both dimensions. Presumably none of that gets figured out properly
until the widget is displayed, or some such.
However, you can retrieve the PangoLayout from the label immediately
and ask Pango for the dimensions of that. That seems like a bit of a
bodge, but it works! The GTK3 unifont selector now comes out with all
the interface elements in sensible sizes - in particular, the preview
drawing area now has non-zero height.
The entire concept has gone away in GTK3, which assumes that everyone
is now using modern true-colour video modes and so there's no longer
any reason you shouldn't just casually make up any RGB triple you like
without bothering to ask the display system's permission.
GDK3 now spells both of those as GDK_WINDOW_XID. (Of course 'drawable'
is no longer a relevant concept in GDK3, since pixmaps are no longer
supported and so all drawables are just windows.) We keep backwards
compatibility, of course.
This replaces GTK 1/2's "expose_event", and provides a ready-made
cairo_t to do the drawing with. My previous work has already separated
all constructions of a cairo_t from the subsequent drawing with it, so
the new draw event handlers just have to call the latter without the
former.
I've just noticed the comment in gtkfont.c that said wouldn't it be
nice to find a way to avoid the GDK pixmap-stretching code when using
Pango fonts. We now do support this, but we support it in gtkwin.c
rather than gtkfont.c - because we do it using a Cairo transformation
matrix, so it still takes place at the level above Pango rather than
in Pango proper. (I never did find out whether Pango itself included
facilities to arbitrarily stretch a font.)
Hence, this comment is useless now. Discard.
We still don't actually support more than one X display active at
once, so it's sufficient to replace every call to that macro with
GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).
We won't be able to use them in GTK3, or when compiling with GTK2 and
-DGDK_DISABLE_DEPRECATED.
This applies to the one we use for the main terminal window, and also
the small one we use for the preview pane in the unified font selector.
Now it's got an inner half that does actual drawing given a draw
context, and an outer half that sets up and tears down the draw
context. Sooner or later the inner half will need calling
independently of the outer, because GTK3's draw event will provide a
ready-made cairo_t.
