Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
/*
|
|
|
|
* Unified font management for GTK.
|
2019-09-08 22:29:00 +03:00
|
|
|
*
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
* PuTTY is willing to use both old-style X server-side bitmap
|
|
|
|
* fonts _and_ GTK2/Pango client-side fonts. This requires us to
|
|
|
|
* do a bit of work to wrap the two wildly different APIs into
|
|
|
|
* forms the rest of the code can switch between seamlessly, and
|
|
|
|
* also requires a custom font selector capable of handling both
|
|
|
|
* types of font.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <assert.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
2015-08-31 15:05:51 +03:00
|
|
|
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
#include <gtk/gtk.h>
|
2015-08-08 17:06:15 +03:00
|
|
|
#if !GTK_CHECK_VERSION(3,0,0)
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
#include <gdk/gdkkeysyms.h>
|
2015-08-08 17:06:15 +03:00
|
|
|
#endif
|
2015-08-31 15:05:51 +03:00
|
|
|
|
2015-08-31 15:57:34 +03:00
|
|
|
#define MAY_REFER_TO_GTK_IN_HEADERS
|
|
|
|
|
2015-08-31 15:05:51 +03:00
|
|
|
#include "putty.h"
|
|
|
|
#include "gtkfont.h"
|
|
|
|
#include "gtkcompat.h"
|
2015-08-31 17:44:24 +03:00
|
|
|
#include "gtkmisc.h"
|
2015-08-31 15:05:51 +03:00
|
|
|
#include "tree234.h"
|
|
|
|
|
2015-08-08 18:35:19 +03:00
|
|
|
#ifndef NOT_X_WINDOWS
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
#include <gdk/gdkx.h>
|
|
|
|
#include <X11/Xlib.h>
|
|
|
|
#include <X11/Xutil.h>
|
|
|
|
#include <X11/Xatom.h>
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
#include "x11misc.h"
|
2015-08-08 18:35:19 +03:00
|
|
|
#endif
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Future work:
|
2019-09-08 22:29:00 +03:00
|
|
|
*
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
* - it would be nice to have a display of the current font name,
|
|
|
|
* and in particular whether it's client- or server-side,
|
|
|
|
* during the progress of the font selector.
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
*/
|
|
|
|
|
2012-01-03 23:43:19 +04:00
|
|
|
#if !GLIB_CHECK_VERSION(1,3,7)
|
|
|
|
#define g_ascii_strcasecmp g_strcasecmp
|
|
|
|
#define g_ascii_strncasecmp g_strncasecmp
|
|
|
|
#endif
|
|
|
|
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
/*
|
|
|
|
* Ad-hoc vtable mechanism to allow font structures to be
|
|
|
|
* polymorphic.
|
2019-09-08 22:29:00 +03:00
|
|
|
*
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
* Any instance of `unifont' used in the vtable functions will
|
2018-10-05 09:02:19 +03:00
|
|
|
* actually be an element of a larger structure containing data
|
|
|
|
* specific to the subtype.
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
*/
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
#define FONTFLAG_CLIENTSIDE 0x0001
|
|
|
|
#define FONTFLAG_SERVERSIDE 0x0002
|
|
|
|
#define FONTFLAG_SERVERALIAS 0x0004
|
|
|
|
#define FONTFLAG_NONMONOSPACED 0x0008
|
|
|
|
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
#define FONTFLAG_SORT_MASK 0x0007 /* used to disambiguate font families */
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
typedef void (*fontsel_add_entry)(void *ctx, const char *realfontname,
|
2019-09-08 22:29:00 +03:00
|
|
|
const char *family, const char *charset,
|
|
|
|
const char *style, const char *stylekey,
|
|
|
|
int size, int flags,
|
|
|
|
const struct UnifontVtable *fontclass);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2018-10-05 09:03:46 +03:00
|
|
|
struct UnifontVtable {
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
/*
|
|
|
|
* `Methods' of the `class'.
|
|
|
|
*/
|
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 22:23:19 +03:00
|
|
|
unifont *(*create)(GtkWidget *widget, const char *name, bool wide,
|
|
|
|
bool bold, int shadowoffset, bool shadowalways);
|
|
|
|
unifont *(*create_fallback)(GtkWidget *widget, int height, bool wide,
|
|
|
|
bool bold, int shadowoffset,
|
|
|
|
bool shadowalways);
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
void (*destroy)(unifont *font);
|
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 22:23:19 +03:00
|
|
|
bool (*has_glyph)(unifont *font, wchar_t glyph);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
void (*draw_text)(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string, int len,
|
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 22:23:19 +03:00
|
|
|
bool wide, bool bold, int cellwidth);
|
2015-09-26 12:18:53 +03:00
|
|
|
void (*draw_combining)(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string, int len,
|
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 22:23:19 +03:00
|
|
|
bool wide, bool bold, int cellwidth);
|
2008-03-26 00:49:14 +03:00
|
|
|
void (*enum_fonts)(GtkWidget *widget,
|
2019-09-08 22:29:00 +03:00
|
|
|
fontsel_add_entry callback, void *callback_ctx);
|
2008-03-27 22:41:08 +03:00
|
|
|
char *(*canonify_fontname)(GtkWidget *widget, const char *name, int *size,
|
2019-09-08 22:29:00 +03:00
|
|
|
int *flags, bool resolve_aliases);
|
2008-03-26 00:49:14 +03:00
|
|
|
char *(*scale_fontname)(GtkWidget *widget, const char *name, int size);
|
2016-11-13 16:53:42 +03:00
|
|
|
char *(*size_increment)(unifont *font, int increment);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
/*
|
|
|
|
* `Static data members' of the `class'.
|
|
|
|
*/
|
|
|
|
const char *prefix;
|
|
|
|
};
|
|
|
|
|
2015-08-08 18:35:19 +03:00
|
|
|
#ifndef NOT_X_WINDOWS
|
|
|
|
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
/* ----------------------------------------------------------------------
|
2015-08-08 18:35:19 +03:00
|
|
|
* X11 font implementation, directly using Xlib calls. Conditioned out
|
|
|
|
* if X11 fonts aren't available at all (e.g. building with GTK3 for a
|
|
|
|
* back end other than X).
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03: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 22:23:19 +03:00
|
|
|
static bool x11font_has_glyph(unifont *font, wchar_t glyph);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static void x11font_draw_text(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string, int len,
|
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 22:23:19 +03:00
|
|
|
bool wide, bool bold, int cellwidth);
|
2015-09-26 12:18:53 +03:00
|
|
|
static void x11font_draw_combining(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string,
|
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 22:23:19 +03:00
|
|
|
int len, bool wide, bool bold,
|
|
|
|
int cellwidth);
|
2008-03-26 00:49:14 +03:00
|
|
|
static unifont *x11font_create(GtkWidget *widget, const char *name,
|
2019-09-08 22:29:00 +03:00
|
|
|
bool wide, bool bold,
|
|
|
|
int shadowoffset, bool shadowalways);
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
static void x11font_destroy(unifont *font);
|
2008-03-26 00:49:14 +03:00
|
|
|
static void x11font_enum_fonts(GtkWidget *widget,
|
2019-09-08 22:29:00 +03:00
|
|
|
fontsel_add_entry callback, void *callback_ctx);
|
2008-03-26 00:49:14 +03:00
|
|
|
static char *x11font_canonify_fontname(GtkWidget *widget, const char *name,
|
2019-09-08 22:29:00 +03:00
|
|
|
int *size, int *flags,
|
|
|
|
bool resolve_aliases);
|
2008-03-26 00:49:14 +03:00
|
|
|
static char *x11font_scale_fontname(GtkWidget *widget, const char *name,
|
2019-09-08 22:29:00 +03:00
|
|
|
int size);
|
2016-11-13 16:53:42 +03:00
|
|
|
static char *x11font_size_increment(unifont *font, int increment);
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
struct cairo_cached_glyph {
|
|
|
|
cairo_surface_t *surface;
|
|
|
|
unsigned char *bitmap;
|
|
|
|
};
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Structure storing a single physical XFontStruct, plus associated
|
|
|
|
* data.
|
|
|
|
*/
|
|
|
|
typedef struct x11font_individual {
|
|
|
|
/* The XFontStruct itself. */
|
|
|
|
XFontStruct *xfs;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The `allocated' flag indicates whether we've tried to fetch
|
|
|
|
* this subfont already (thus distinguishing xfs==NULL because we
|
|
|
|
* haven't tried yet from xfs==NULL because we tried and failed,
|
|
|
|
* so that we don't keep trying and failing subsequently).
|
|
|
|
*/
|
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 22:23:19 +03:00
|
|
|
bool allocated;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
/*
|
|
|
|
* A cache of glyph bitmaps downloaded from the X server when
|
|
|
|
* we're in Cairo rendering mode. If glyphcache itself is
|
|
|
|
* non-NULL, then entries in [0,nglyphs) are expected to be
|
|
|
|
* initialised to either NULL or a bitmap pointer.
|
|
|
|
*/
|
|
|
|
struct cairo_cached_glyph *glyphcache;
|
|
|
|
int nglyphs;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* X server paraphernalia for actually downloading the glyphs.
|
|
|
|
*/
|
|
|
|
Pixmap pixmap;
|
|
|
|
GC gc;
|
|
|
|
int pixwidth, pixheight, pixoriginx, pixoriginy;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Paraphernalia for loading the resulting bitmaps into Cairo.
|
|
|
|
*/
|
|
|
|
int rowsize, allsize, indexflip;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
} x11font_individual;
|
|
|
|
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
struct x11font {
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
/*
|
|
|
|
* Copy of the X display handle, so we don't have to keep
|
|
|
|
* extracting it from GDK.
|
|
|
|
*/
|
|
|
|
Display *disp;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
/*
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
* Individual physical X fonts. We store a number of these, for
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
* automatically guessed bold and wide variants.
|
|
|
|
*/
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
x11font_individual fonts[4];
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
/*
|
|
|
|
* `sixteen_bit' is true iff the font object is indexed by
|
|
|
|
* values larger than a byte. That is, this flag tells us
|
2011-09-16 12:49:08 +04:00
|
|
|
* whether we use XDrawString or XDrawString16, etc.
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03: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 22:23:19 +03:00
|
|
|
bool sixteen_bit;
|
2008-03-29 13:48:16 +03:00
|
|
|
/*
|
|
|
|
* `variable' is true iff the font is non-fixed-pitch. This
|
|
|
|
* enables some code which takes greater care over character
|
|
|
|
* positioning during text drawing.
|
|
|
|
*/
|
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 22:23:19 +03:00
|
|
|
bool variable;
|
2011-09-16 23:18:53 +04:00
|
|
|
/*
|
|
|
|
* real_charset is the charset used when translating text into the
|
|
|
|
* font's internal encoding inside draw_text(). This need not be
|
|
|
|
* the same as the public_charset provided to the client; for
|
|
|
|
* example, public_charset might be CS_ISO8859_1 while
|
|
|
|
* real_charset is CS_ISO8859_1_X11.
|
|
|
|
*/
|
|
|
|
int real_charset;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
/*
|
|
|
|
* Data passed in to unifont_create().
|
|
|
|
*/
|
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 22:23:19 +03:00
|
|
|
int shadowoffset;
|
|
|
|
bool wide, bold, shadowalways;
|
2018-10-05 09:02:19 +03:00
|
|
|
|
|
|
|
unifont u;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
};
|
|
|
|
|
Change vtable defs to use C99 designated initialisers.
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.
2020-03-11 00:06:29 +03:00
|
|
|
static const UnifontVtable x11font_vtable = {
|
|
|
|
.create = x11font_create,
|
|
|
|
.create_fallback = NULL, /* no fallback fonts in X11 */
|
|
|
|
.destroy = x11font_destroy,
|
|
|
|
.has_glyph = x11font_has_glyph,
|
|
|
|
.draw_text = x11font_draw_text,
|
|
|
|
.draw_combining = x11font_draw_combining,
|
|
|
|
.enum_fonts = x11font_enum_fonts,
|
|
|
|
.canonify_fontname = x11font_canonify_fontname,
|
|
|
|
.scale_fontname = x11font_scale_fontname,
|
|
|
|
.size_increment = x11font_size_increment,
|
|
|
|
.prefix = "server",
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
};
|
|
|
|
|
2016-11-13 15:02:13 +03:00
|
|
|
#define XLFD_STRING_PARTS_LIST(S,I) \
|
|
|
|
S(foundry) \
|
|
|
|
S(family_name) \
|
|
|
|
S(weight_name) \
|
|
|
|
S(slant) \
|
|
|
|
S(setwidth_name) \
|
|
|
|
S(add_style_name) \
|
|
|
|
I(pixel_size) \
|
|
|
|
I(point_size) \
|
|
|
|
I(resolution_x) \
|
|
|
|
I(resolution_y) \
|
|
|
|
S(spacing) \
|
|
|
|
I(average_width) \
|
|
|
|
S(charset_registry) \
|
|
|
|
S(charset_encoding) \
|
|
|
|
/* end of list */
|
|
|
|
|
2016-11-13 16:53:42 +03:00
|
|
|
/* Special value for int fields that xlfd_recompose will render as "*" */
|
|
|
|
#define XLFD_INT_WILDCARD INT_MIN
|
|
|
|
|
2016-11-13 15:02:13 +03:00
|
|
|
struct xlfd_decomposed {
|
|
|
|
#define STR_FIELD(f) const char *f;
|
|
|
|
#define INT_FIELD(f) int f;
|
|
|
|
XLFD_STRING_PARTS_LIST(STR_FIELD, INT_FIELD)
|
|
|
|
#undef STR_FIELD
|
|
|
|
#undef INT_FIELD
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct xlfd_decomposed *xlfd_decompose(const char *xlfd)
|
|
|
|
{
|
|
|
|
char *p, *components[14];
|
|
|
|
struct xlfd_decomposed *dec;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!xlfd)
|
|
|
|
return NULL;
|
|
|
|
|
2018-06-06 08:42:52 +03:00
|
|
|
dec = snew_plus(struct xlfd_decomposed, strlen(xlfd) + 1);
|
|
|
|
p = snew_plus_get_aux(dec);
|
2016-11-13 15:02:13 +03:00
|
|
|
strcpy(p, xlfd);
|
|
|
|
|
|
|
|
for (i = 0; i < 14; i++) {
|
|
|
|
if (*p != '-') {
|
|
|
|
/* Malformed XLFD: not enough '-' */
|
2018-06-06 08:42:52 +03:00
|
|
|
sfree(dec);
|
2016-11-13 15:02:13 +03:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
*p++ = '\0';
|
|
|
|
components[i] = p;
|
|
|
|
p += strcspn(p, "-");
|
|
|
|
}
|
|
|
|
if (*p) {
|
|
|
|
/* Malformed XLFD: too many '-' */
|
2018-06-06 08:42:52 +03:00
|
|
|
sfree(dec);
|
2016-11-13 15:02:13 +03:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
i = 0;
|
|
|
|
#define STORE_STR(f) dec->f = components[i++];
|
|
|
|
#define STORE_INT(f) dec->f = atoi(components[i++]);
|
|
|
|
XLFD_STRING_PARTS_LIST(STORE_STR, STORE_INT)
|
|
|
|
#undef STORE_STR
|
|
|
|
#undef STORE_INT
|
|
|
|
|
|
|
|
return dec;
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *xlfd_recompose(const struct xlfd_decomposed *dec)
|
|
|
|
{
|
|
|
|
#define FMT_STR(f) "-%s"
|
|
|
|
#define ARG_STR(f) , dec->f
|
2016-11-13 16:53:42 +03:00
|
|
|
#define FMT_INT(f) "%s%.*d"
|
|
|
|
#define ARG_INT(f) \
|
|
|
|
, dec->f == XLFD_INT_WILDCARD ? "-*" : "-" \
|
|
|
|
, dec->f == XLFD_INT_WILDCARD ? 0 : 1 \
|
|
|
|
, dec->f == XLFD_INT_WILDCARD ? 0 : dec->f
|
2016-11-13 15:02:13 +03:00
|
|
|
return dupprintf(XLFD_STRING_PARTS_LIST(FMT_STR, FMT_INT)
|
|
|
|
XLFD_STRING_PARTS_LIST(ARG_STR, ARG_INT));
|
|
|
|
#undef FMT_STR
|
|
|
|
#undef ARG_STR
|
|
|
|
#undef FMT_INT
|
|
|
|
#undef ARG_INT
|
|
|
|
}
|
|
|
|
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
static char *x11_guess_derived_font_name(Display *disp, XFontStruct *xfs,
|
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 22:23:19 +03:00
|
|
|
bool bold, bool wide)
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
{
|
|
|
|
Atom fontprop = XInternAtom(disp, "FONT", False);
|
|
|
|
unsigned long ret;
|
|
|
|
if (XGetFontProperty(xfs, fontprop, &ret)) {
|
2019-09-08 22:29:00 +03:00
|
|
|
char *name = XGetAtomName(disp, (Atom)ret);
|
2016-11-13 15:02:13 +03:00
|
|
|
struct xlfd_decomposed *xlfd = xlfd_decompose(name);
|
|
|
|
if (!xlfd)
|
|
|
|
return NULL;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
|
2016-11-13 15:02:13 +03:00
|
|
|
if (bold)
|
|
|
|
xlfd->weight_name = "bold";
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
|
2016-11-13 15:02:13 +03:00
|
|
|
if (wide) {
|
|
|
|
/* Width name obviously may have changed. */
|
|
|
|
/* Additional style may now become e.g. `ja' or `ko'. */
|
|
|
|
xlfd->setwidth_name = xlfd->add_style_name = "*";
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
|
2016-11-13 15:02:13 +03:00
|
|
|
/* Expect to double the average width. */
|
|
|
|
xlfd->average_width *= 2;
|
|
|
|
}
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
|
2016-11-13 15:02:13 +03:00
|
|
|
{
|
|
|
|
char *ret = xlfd_recompose(xlfd);
|
|
|
|
sfree(xlfd);
|
|
|
|
return ret;
|
|
|
|
}
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
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 22:23:19 +03:00
|
|
|
static int x11_font_width(XFontStruct *xfs, bool sixteen_bit)
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
{
|
|
|
|
if (sixteen_bit) {
|
2019-09-08 22:29:00 +03:00
|
|
|
XChar2b space;
|
|
|
|
space.byte1 = 0;
|
|
|
|
space.byte2 = '0';
|
|
|
|
return XTextWidth16(xfs, &space, 1);
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
} else {
|
2019-09-08 22:29:00 +03:00
|
|
|
return XTextWidth(xfs, "0", 1);
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-11 01:22:49 +03:00
|
|
|
static const XCharStruct *x11_char_struct(
|
|
|
|
XFontStruct *xfs, unsigned char byte1, unsigned char byte2)
|
2011-09-16 23:18:54 +04:00
|
|
|
{
|
|
|
|
int index;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The man page for XQueryFont is rather confusing about how the
|
|
|
|
* per_char array in the XFontStruct is laid out, because it gives
|
|
|
|
* formulae for determining the two-byte X character code _from_
|
|
|
|
* an index into the per_char array. Going the other way, it's
|
|
|
|
* rather simpler:
|
|
|
|
*
|
|
|
|
* The valid character codes have byte1 between min_byte1 and
|
|
|
|
* max_byte1 inclusive, and byte2 between min_char_or_byte2 and
|
|
|
|
* max_char_or_byte2 inclusive. This gives a rectangle of size
|
|
|
|
* (max_byte2-min_byte1+1) by
|
|
|
|
* (max_char_or_byte2-min_char_or_byte2+1), which is precisely the
|
|
|
|
* rectangle encoded in the per_char array. Hence, given a
|
|
|
|
* character code which is valid in the sense that it falls
|
|
|
|
* somewhere in that rectangle, its index in per_char is given by
|
|
|
|
* setting
|
|
|
|
*
|
|
|
|
* x = byte2 - min_char_or_byte2
|
|
|
|
* y = byte1 - min_byte1
|
|
|
|
* index = y * (max_char_or_byte2-min_char_or_byte2+1) + x
|
|
|
|
*
|
|
|
|
* If min_byte1 and min_byte2 are both zero, that's a special case
|
|
|
|
* which can be treated as if min_byte2 was 1 instead, i.e. the
|
|
|
|
* per_char array just runs from min_char_or_byte2 to
|
|
|
|
* max_char_or_byte2 inclusive, and byte1 should always be zero.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (byte2 < xfs->min_char_or_byte2 || byte2 > xfs->max_char_or_byte2)
|
2018-10-29 10:23:32 +03:00
|
|
|
return NULL;
|
2011-09-16 23:18:54 +04:00
|
|
|
|
|
|
|
if (xfs->min_byte1 == 0 && xfs->max_byte1 == 0) {
|
|
|
|
index = byte2 - xfs->min_char_or_byte2;
|
|
|
|
} else {
|
|
|
|
if (byte1 < xfs->min_byte1 || byte1 > xfs->max_byte1)
|
2018-10-29 10:23:32 +03:00
|
|
|
return NULL;
|
2011-09-16 23:18:54 +04:00
|
|
|
index = ((byte2 - xfs->min_char_or_byte2) +
|
|
|
|
((byte1 - xfs->min_byte1) *
|
|
|
|
(xfs->max_char_or_byte2 - xfs->min_char_or_byte2 + 1)));
|
|
|
|
}
|
|
|
|
|
2011-09-17 18:50:18 +04:00
|
|
|
if (!xfs->per_char) /* per_char NULL => everything in range exists */
|
2016-03-20 20:39:43 +03:00
|
|
|
return &xfs->max_bounds;
|
|
|
|
|
|
|
|
return &xfs->per_char[index];
|
|
|
|
}
|
2011-09-17 18:50:18 +04: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 22:23:19 +03:00
|
|
|
static bool x11_font_has_glyph(
|
2017-01-11 01:22:49 +03:00
|
|
|
XFontStruct *xfs, unsigned char byte1, unsigned char byte2)
|
2016-03-20 20:39:43 +03:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Not to be confused with x11font_has_glyph, which is a method of
|
|
|
|
* the x11font 'class' and hence takes a unifont as argument. This
|
|
|
|
* is the low-level function which grubs about in an actual
|
|
|
|
* XFontStruct to see if a given glyph exists.
|
|
|
|
*
|
|
|
|
* We must do this ourselves rather than letting Xlib's
|
|
|
|
* XTextExtents16 do the job, because XTextExtents will helpfully
|
|
|
|
* substitute the font's default_char for any missing glyph and
|
|
|
|
* not tell us it did so, which precisely won't help us find out
|
|
|
|
* which glyphs _are_ missing.
|
|
|
|
*/
|
|
|
|
const XCharStruct *xcs = x11_char_struct(xfs, byte1, byte2);
|
2016-03-20 22:55:22 +03:00
|
|
|
return xcs && (xcs->ascent + xcs->descent > 0 || xcs->width > 0);
|
2011-09-16 23:18:54 +04:00
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
static unifont *x11font_create(GtkWidget *widget, const char *name,
|
2019-09-08 22:29:00 +03:00
|
|
|
bool wide, bool bold,
|
|
|
|
int shadowoffset, bool shadowalways)
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
{
|
|
|
|
struct x11font *xfont;
|
|
|
|
XFontStruct *xfs;
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
Display *disp;
|
2008-03-29 13:48:16 +03:00
|
|
|
Atom charset_registry, charset_encoding, spacing;
|
|
|
|
unsigned long registry_ret, encoding_ret, spacing_ret;
|
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 22:23:19 +03:00
|
|
|
int pubcs, realcs;
|
|
|
|
bool sixteen_bit, variable;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
int i;
|
|
|
|
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
if ((disp = get_x11_display()) == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
2011-09-16 12:49:08 +04:00
|
|
|
xfs = XLoadQueryFont(disp, name);
|
|
|
|
if (!xfs)
|
2019-09-08 22:29:00 +03:00
|
|
|
return NULL;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
|
|
|
|
charset_registry = XInternAtom(disp, "CHARSET_REGISTRY", False);
|
|
|
|
charset_encoding = XInternAtom(disp, "CHARSET_ENCODING", False);
|
|
|
|
|
|
|
|
pubcs = realcs = CS_NONE;
|
2018-10-29 22:50:29 +03:00
|
|
|
sixteen_bit = false;
|
|
|
|
variable = true;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
|
|
|
|
if (XGetFontProperty(xfs, charset_registry, ®istry_ret) &&
|
2019-09-08 22:29:00 +03:00
|
|
|
XGetFontProperty(xfs, charset_encoding, &encoding_ret)) {
|
|
|
|
char *reg, *enc;
|
|
|
|
reg = XGetAtomName(disp, (Atom)registry_ret);
|
|
|
|
enc = XGetAtomName(disp, (Atom)encoding_ret);
|
|
|
|
if (reg && enc) {
|
Make dupcat() into a variadic macro.
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.
2019-10-14 21:42:37 +03:00
|
|
|
char *encoding = dupcat(reg, "-", enc);
|
2019-09-08 22:29:00 +03:00
|
|
|
pubcs = realcs = charset_from_xenc(encoding);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* iso10646-1 is the only wide font encoding we
|
|
|
|
* support. In this case, we expect clients to give us
|
|
|
|
* UTF-8, which this module must internally convert
|
|
|
|
* into 16-bit Unicode.
|
|
|
|
*/
|
|
|
|
if (!strcasecmp(encoding, "iso10646-1")) {
|
|
|
|
sixteen_bit = true;
|
|
|
|
pubcs = realcs = CS_UTF8;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Hack for X line-drawing characters: if the primary font
|
|
|
|
* is encoded as ISO-8859-1, and has valid glyphs in the
|
|
|
|
* low character positions, it is assumed that those
|
|
|
|
* glyphs are the VT100 line-drawing character set.
|
|
|
|
*/
|
|
|
|
if (pubcs == CS_ISO8859_1) {
|
2011-09-16 23:18:54 +04:00
|
|
|
int ch;
|
|
|
|
for (ch = 1; ch < 32; ch++)
|
|
|
|
if (!x11_font_has_glyph(xfs, 0, ch))
|
|
|
|
break;
|
|
|
|
if (ch == 32)
|
|
|
|
realcs = CS_ISO8859_1_X11;
|
|
|
|
}
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
sfree(encoding);
|
|
|
|
}
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
|
|
|
|
2008-03-29 13:48:16 +03:00
|
|
|
spacing = XInternAtom(disp, "SPACING", False);
|
|
|
|
if (XGetFontProperty(xfs, spacing, &spacing_ret)) {
|
2019-09-08 22:29:00 +03:00
|
|
|
char *spc;
|
|
|
|
spc = XGetAtomName(disp, (Atom)spacing_ret);
|
2008-03-29 13:48:16 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
if (spc && strchr("CcMm", spc[0]))
|
|
|
|
variable = false;
|
2008-03-29 13:48:16 +03:00
|
|
|
}
|
|
|
|
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
xfont = snew(struct x11font);
|
|
|
|
xfont->u.vt = &x11font_vtable;
|
2011-09-16 12:49:08 +04:00
|
|
|
xfont->u.width = x11_font_width(xfs, sixteen_bit);
|
|
|
|
xfont->u.ascent = xfs->ascent;
|
|
|
|
xfont->u.descent = xfs->descent;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
xfont->u.height = xfont->u.ascent + xfont->u.descent;
|
|
|
|
xfont->u.public_charset = pubcs;
|
2018-10-29 22:50:29 +03:00
|
|
|
xfont->u.want_fallback = true;
|
2020-08-13 23:08:53 +03:00
|
|
|
xfont->u.strikethrough_y = xfont->u.ascent - (xfont->u.ascent * 3 / 8);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#ifdef DRAW_TEXT_GDK
|
|
|
|
xfont->u.preferred_drawtype = DRAWTYPE_GDK;
|
|
|
|
#elif defined DRAW_TEXT_CAIRO
|
|
|
|
xfont->u.preferred_drawtype = DRAWTYPE_CAIRO;
|
|
|
|
#else
|
|
|
|
#error No drawtype available at all
|
|
|
|
#endif
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
xfont->disp = disp;
|
2011-09-16 23:18:53 +04:00
|
|
|
xfont->real_charset = realcs;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
xfont->sixteen_bit = sixteen_bit;
|
2008-03-29 13:48:16 +03:00
|
|
|
xfont->variable = variable;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
xfont->wide = wide;
|
|
|
|
xfont->bold = bold;
|
|
|
|
xfont->shadowoffset = shadowoffset;
|
|
|
|
xfont->shadowalways = shadowalways;
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
for (i = 0; i < lenof(xfont->fonts); i++) {
|
2019-09-08 22:29:00 +03:00
|
|
|
xfont->fonts[i].xfs = NULL;
|
|
|
|
xfont->fonts[i].allocated = false;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
2019-09-08 22:29:00 +03:00
|
|
|
xfont->fonts[i].glyphcache = NULL;
|
|
|
|
xfont->fonts[i].nglyphs = 0;
|
|
|
|
xfont->fonts[i].pixmap = None;
|
|
|
|
xfont->fonts[i].gc = None;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#endif
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
xfont->fonts[0].xfs = xfs;
|
2018-10-29 22:50:29 +03:00
|
|
|
xfont->fonts[0].allocated = true;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
|
2018-10-05 09:02:19 +03:00
|
|
|
return &xfont->u;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void x11font_destroy(unifont *font)
|
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
struct x11font *xfont = container_of(font, struct x11font, u);
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
Display *disp = xfont->disp;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
int i;
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
for (i = 0; i < lenof(xfont->fonts); i++) {
|
2019-09-08 22:29:00 +03:00
|
|
|
if (xfont->fonts[i].xfs)
|
|
|
|
XFreeFont(disp, xfont->fonts[i].xfs);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
2019-09-08 22:29:00 +03:00
|
|
|
if (xfont->fonts[i].gc != None)
|
|
|
|
XFreeGC(disp, xfont->fonts[i].gc);
|
|
|
|
if (xfont->fonts[i].pixmap != None)
|
|
|
|
XFreePixmap(disp, xfont->fonts[i].pixmap);
|
|
|
|
if (xfont->fonts[i].glyphcache) {
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
int j;
|
|
|
|
for (j = 0; j < xfont->fonts[i].nglyphs; j++) {
|
|
|
|
cairo_surface_destroy(xfont->fonts[i].glyphcache[j].surface);
|
|
|
|
sfree(xfont->fonts[i].glyphcache[j].bitmap);
|
|
|
|
}
|
|
|
|
sfree(xfont->fonts[i].glyphcache);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
2018-10-05 09:02:19 +03:00
|
|
|
sfree(xfont);
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void x11_alloc_subfont(struct x11font *xfont, int sfid)
|
|
|
|
{
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
Display *disp = xfont->disp;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
char *derived_name = x11_guess_derived_font_name
|
2019-09-08 22:29:00 +03:00
|
|
|
(disp, xfont->fonts[0].xfs, sfid & 1, !!(sfid & 2));
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
xfont->fonts[sfid].xfs = XLoadQueryFont(disp, derived_name);
|
2018-10-29 22:50:29 +03:00
|
|
|
xfont->fonts[sfid].allocated = true;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
sfree(derived_name);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
/* Note that xfont->fonts[sfid].xfs may still be NULL, if XLQF failed. */
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03: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 22:23:19 +03:00
|
|
|
static bool x11font_has_glyph(unifont *font, wchar_t glyph)
|
2011-09-16 23:18:54 +04:00
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
struct x11font *xfont = container_of(font, struct x11font, u);
|
2011-09-16 23:18:54 +04:00
|
|
|
|
|
|
|
if (xfont->sixteen_bit) {
|
2019-09-08 22:29:00 +03:00
|
|
|
/*
|
|
|
|
* This X font has 16-bit character indices, which means
|
|
|
|
* we can directly use our Unicode input value.
|
|
|
|
*/
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
return x11_font_has_glyph(xfont->fonts[0].xfs,
|
|
|
|
glyph >> 8, glyph & 0xFF);
|
2011-09-16 23:18:54 +04:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* This X font has 8-bit indices, so we must convert to the
|
|
|
|
* appropriate character set.
|
|
|
|
*/
|
|
|
|
char sbstring[2];
|
|
|
|
int sblen = wc_to_mb(xfont->real_charset, 0, &glyph, 1,
|
2018-10-06 13:45:26 +03:00
|
|
|
sbstring, 2, "", NULL);
|
2012-04-22 18:22:08 +04:00
|
|
|
if (sblen == 0 || !sbstring[0])
|
2018-10-29 22:50:29 +03:00
|
|
|
return false; /* not even in the charset */
|
2011-09-16 23:18:54 +04:00
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
return x11_font_has_glyph(xfont->fonts[0].xfs, 0,
|
2011-09-17 12:11:11 +04:00
|
|
|
(unsigned char)sbstring[0]);
|
2011-09-16 23:18:54 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-09-16 12:49:08 +04:00
|
|
|
#if !GTK_CHECK_VERSION(2,0,0)
|
|
|
|
#define GDK_DRAWABLE_XID(d) GDK_WINDOW_XWINDOW(d) /* GTK1's name for this */
|
2015-08-16 16:16:23 +03:00
|
|
|
#elif GTK_CHECK_VERSION(3,0,0)
|
|
|
|
#define GDK_DRAWABLE_XID(d) GDK_WINDOW_XID(d) /* GTK3's name for this */
|
2011-09-16 12:49:08 +04:00
|
|
|
#endif
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static int x11font_width_16(unifont_drawctx *ctx, x11font_individual *xfi,
|
|
|
|
const void *vstring, int start, int length)
|
2008-03-29 13:48:16 +03:00
|
|
|
{
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
const XChar2b *string = (const XChar2b *)vstring;
|
|
|
|
return XTextWidth16(xfi->xfs, string+start, length);
|
|
|
|
}
|
2008-03-29 13:48:16 +03:00
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static int x11font_width_8(unifont_drawctx *ctx, x11font_individual *xfi,
|
|
|
|
const void *vstring, int start, int length)
|
|
|
|
{
|
|
|
|
const char *string = (const char *)vstring;
|
|
|
|
return XTextWidth(xfi->xfs, string+start, length);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef DRAW_TEXT_GDK
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
static void x11font_gdk_setup(unifont_drawctx *ctx, x11font_individual *xfi,
|
|
|
|
Display *disp)
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
{
|
2015-08-16 11:23:32 +03:00
|
|
|
XSetFont(disp, GDK_GC_XGC(ctx->u.gdk.gc), xfi->xfs->fid);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
}
|
|
|
|
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
static void x11font_gdk_draw_16(unifont_drawctx *ctx, x11font_individual *xfi,
|
|
|
|
Display *disp, int x, int y,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
const void *vstring, int start, int length)
|
|
|
|
{
|
|
|
|
const XChar2b *string = (const XChar2b *)vstring;
|
2015-08-16 11:23:32 +03:00
|
|
|
XDrawString16(disp, GDK_DRAWABLE_XID(ctx->u.gdk.target),
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
GDK_GC_XGC(ctx->u.gdk.gc), x, y, string+start, length);
|
|
|
|
}
|
|
|
|
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
static void x11font_gdk_draw_8(unifont_drawctx *ctx, x11font_individual *xfi,
|
|
|
|
Display *disp, int x, int y,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
const void *vstring, int start, int length)
|
|
|
|
{
|
|
|
|
const char *string = (const char *)vstring;
|
2015-08-16 11:23:32 +03:00
|
|
|
XDrawString(disp, GDK_DRAWABLE_XID(ctx->u.gdk.target),
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
GDK_GC_XGC(ctx->u.gdk.gc), x, y, string+start, length);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
static void x11font_cairo_setup(
|
|
|
|
unifont_drawctx *ctx, x11font_individual *xfi, Display *disp)
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
{
|
|
|
|
if (xfi->pixmap == None) {
|
|
|
|
XGCValues gcvals;
|
|
|
|
GdkWindow *widgetwin = gtk_widget_get_window(ctx->u.cairo.widget);
|
|
|
|
int widgetscr = GDK_SCREEN_XNUMBER(gdk_window_get_screen(widgetwin));
|
|
|
|
|
|
|
|
xfi->pixwidth =
|
|
|
|
xfi->xfs->max_bounds.rbearing - xfi->xfs->min_bounds.lbearing;
|
|
|
|
xfi->pixheight =
|
|
|
|
xfi->xfs->max_bounds.ascent + xfi->xfs->max_bounds.descent;
|
|
|
|
xfi->pixoriginx = -xfi->xfs->min_bounds.lbearing;
|
|
|
|
xfi->pixoriginy = xfi->xfs->max_bounds.ascent;
|
|
|
|
|
|
|
|
xfi->rowsize = cairo_format_stride_for_width(CAIRO_FORMAT_A1,
|
|
|
|
xfi->pixwidth);
|
|
|
|
xfi->allsize = xfi->rowsize * xfi->pixheight;
|
|
|
|
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Test host endianness and use it to set xfi->indexflip,
|
|
|
|
* which is XORed into our left-shift counts in order to
|
|
|
|
* implement the CAIRO_FORMAT_A1 specification, in which
|
|
|
|
* each bitmap byte is oriented LSB-first on little-endian
|
|
|
|
* platforms and MSB-first on big-endian ones.
|
|
|
|
*
|
|
|
|
* This is the same technique Cairo itself uses to test
|
|
|
|
* endianness, so hopefully it'll work in any situation
|
|
|
|
* where Cairo is usable at all.
|
|
|
|
*/
|
|
|
|
static const int endianness_test = 1;
|
|
|
|
xfi->indexflip = (*((char *) &endianness_test) == 1) ? 0 : 7;
|
|
|
|
}
|
|
|
|
|
|
|
|
xfi->pixmap = XCreatePixmap
|
2015-08-16 11:23:32 +03:00
|
|
|
(disp,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
GDK_DRAWABLE_XID(gtk_widget_get_window(ctx->u.cairo.widget)),
|
|
|
|
xfi->pixwidth, xfi->pixheight, 1);
|
2015-08-16 11:23:32 +03:00
|
|
|
gcvals.foreground = WhitePixel(disp, widgetscr);
|
|
|
|
gcvals.background = BlackPixel(disp, widgetscr);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
gcvals.font = xfi->xfs->fid;
|
2015-08-16 11:23:32 +03:00
|
|
|
xfi->gc = XCreateGC(disp, xfi->pixmap,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
GCForeground | GCBackground | GCFont, &gcvals);
|
2008-03-29 13:48:16 +03:00
|
|
|
}
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
}
|
2008-03-29 13:48:16 +03:00
|
|
|
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
static void x11font_cairo_cache_glyph(
|
|
|
|
Display *disp, x11font_individual *xfi, int glyphindex)
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
{
|
|
|
|
XImage *image;
|
|
|
|
int x, y;
|
|
|
|
unsigned char *bitmap;
|
2016-03-20 20:39:43 +03:00
|
|
|
const XCharStruct *xcs = x11_char_struct(xfi->xfs, glyphindex >> 8,
|
|
|
|
glyphindex & 0xFF);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
|
|
|
|
bitmap = snewn(xfi->allsize, unsigned char);
|
|
|
|
memset(bitmap, 0, xfi->allsize);
|
|
|
|
|
2015-08-16 11:23:32 +03:00
|
|
|
image = XGetImage(disp, xfi->pixmap, 0, 0,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
xfi->pixwidth, xfi->pixheight, AllPlanes, XYPixmap);
|
2016-03-20 20:39:43 +03:00
|
|
|
for (y = xfi->pixoriginy - xcs->ascent;
|
|
|
|
y < xfi->pixoriginy + xcs->descent; y++) {
|
|
|
|
for (x = xfi->pixoriginx + xcs->lbearing;
|
|
|
|
x < xfi->pixoriginx + xcs->rbearing; x++) {
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
unsigned long pixel = XGetPixel(image, x, y);
|
|
|
|
if (pixel) {
|
|
|
|
int byteindex = y * xfi->rowsize + x/8;
|
|
|
|
int bitindex = (x & 7) ^ xfi->indexflip;
|
|
|
|
bitmap[byteindex] |= 1U << bitindex;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
XDestroyImage(image);
|
|
|
|
|
|
|
|
if (xfi->nglyphs <= glyphindex) {
|
|
|
|
/* Round up to the next multiple of 256 on the general
|
|
|
|
* principle that Unicode characters come in contiguous blocks
|
|
|
|
* often used together */
|
|
|
|
int old_nglyphs = xfi->nglyphs;
|
2015-08-23 16:10:59 +03:00
|
|
|
xfi->nglyphs = (glyphindex + 0x100) & ~0xFF;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
xfi->glyphcache = sresize(xfi->glyphcache, xfi->nglyphs,
|
|
|
|
struct cairo_cached_glyph);
|
|
|
|
|
|
|
|
while (old_nglyphs < xfi->nglyphs) {
|
|
|
|
xfi->glyphcache[old_nglyphs].surface = NULL;
|
|
|
|
xfi->glyphcache[old_nglyphs].bitmap = NULL;
|
|
|
|
old_nglyphs++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
xfi->glyphcache[glyphindex].bitmap = bitmap;
|
|
|
|
xfi->glyphcache[glyphindex].surface = cairo_image_surface_create_for_data
|
|
|
|
(bitmap, CAIRO_FORMAT_A1, xfi->pixwidth, xfi->pixheight, xfi->rowsize);
|
|
|
|
}
|
2008-03-29 13:48:16 +03:00
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static void x11font_cairo_draw_glyph(unifont_drawctx *ctx,
|
|
|
|
x11font_individual *xfi, int x, int y,
|
|
|
|
int glyphindex)
|
|
|
|
{
|
|
|
|
if (xfi->glyphcache[glyphindex].surface) {
|
|
|
|
cairo_mask_surface(ctx->u.cairo.cr,
|
|
|
|
xfi->glyphcache[glyphindex].surface,
|
|
|
|
x - xfi->pixoriginx, y - xfi->pixoriginy);
|
|
|
|
}
|
|
|
|
}
|
2008-03-29 13:48:16 +03:00
|
|
|
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
static void x11font_cairo_draw_16(
|
|
|
|
unifont_drawctx *ctx, x11font_individual *xfi, Display *disp,
|
|
|
|
int x, int y, const void *vstring, int start, int length)
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
{
|
|
|
|
const XChar2b *string = (const XChar2b *)vstring + start;
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < length; i++) {
|
|
|
|
if (x11_font_has_glyph(xfi->xfs, string[i].byte1, string[i].byte2)) {
|
|
|
|
int glyphindex = (256 * (unsigned char)string[i].byte1 +
|
|
|
|
(unsigned char)string[i].byte2);
|
|
|
|
if (glyphindex >= xfi->nglyphs ||
|
|
|
|
!xfi->glyphcache[glyphindex].surface) {
|
2015-08-16 11:23:32 +03:00
|
|
|
XDrawImageString16(disp, xfi->pixmap, xfi->gc,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
xfi->pixoriginx, xfi->pixoriginy,
|
|
|
|
string+i, 1);
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
x11font_cairo_cache_glyph(disp, xfi, glyphindex);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
}
|
|
|
|
x11font_cairo_draw_glyph(ctx, xfi, x, y, glyphindex);
|
|
|
|
x += XTextWidth16(xfi->xfs, string+i, 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
static void x11font_cairo_draw_8(
|
|
|
|
unifont_drawctx *ctx, x11font_individual *xfi, Display *disp,
|
|
|
|
int x, int y, const void *vstring, int start, int length)
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
{
|
|
|
|
const char *string = (const char *)vstring + start;
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < length; i++) {
|
|
|
|
if (x11_font_has_glyph(xfi->xfs, 0, string[i])) {
|
|
|
|
int glyphindex = (unsigned char)string[i];
|
|
|
|
if (glyphindex >= xfi->nglyphs ||
|
|
|
|
!xfi->glyphcache[glyphindex].surface) {
|
2015-08-16 11:23:32 +03:00
|
|
|
XDrawImageString(disp, xfi->pixmap, xfi->gc,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
xfi->pixoriginx, xfi->pixoriginy,
|
|
|
|
string+i, 1);
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
x11font_cairo_cache_glyph(disp, xfi, glyphindex);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
}
|
|
|
|
x11font_cairo_draw_glyph(ctx, xfi, x, y, glyphindex);
|
|
|
|
x += XTextWidth(xfi->xfs, string+i, 1);
|
|
|
|
}
|
2008-03-29 13:48:16 +03:00
|
|
|
}
|
|
|
|
}
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#endif /* DRAW_TEXT_CAIRO */
|
|
|
|
|
|
|
|
struct x11font_drawfuncs {
|
|
|
|
int (*width)(unifont_drawctx *ctx, x11font_individual *xfi,
|
|
|
|
const void *vstring, int start, int length);
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
void (*setup)(unifont_drawctx *ctx, x11font_individual *xfi,
|
|
|
|
Display *disp);
|
|
|
|
void (*draw)(unifont_drawctx *ctx, x11font_individual *xfi, Display *disp,
|
|
|
|
int x, int y, const void *vstring, int start, int length);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This array has two entries per compiled-in drawtype; of each pair,
|
|
|
|
* the first is for an 8-bit font and the second for 16-bit.
|
|
|
|
*/
|
|
|
|
static const struct x11font_drawfuncs x11font_drawfuncs[2*DRAWTYPE_NTYPES] = {
|
|
|
|
#ifdef DRAW_TEXT_GDK
|
|
|
|
/* gdk, 8-bit */
|
|
|
|
{
|
|
|
|
x11font_width_8,
|
|
|
|
x11font_gdk_setup,
|
|
|
|
x11font_gdk_draw_8,
|
|
|
|
},
|
|
|
|
/* gdk, 16-bit */
|
|
|
|
{
|
|
|
|
x11font_width_16,
|
|
|
|
x11font_gdk_setup,
|
|
|
|
x11font_gdk_draw_16,
|
|
|
|
},
|
|
|
|
#endif
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
/* cairo, 8-bit */
|
|
|
|
{
|
|
|
|
x11font_width_8,
|
|
|
|
x11font_cairo_setup,
|
|
|
|
x11font_cairo_draw_8,
|
|
|
|
},
|
|
|
|
/* [3] cairo, 16-bit */
|
|
|
|
{
|
|
|
|
x11font_width_16,
|
|
|
|
x11font_cairo_setup,
|
|
|
|
x11font_cairo_draw_16,
|
|
|
|
},
|
|
|
|
#endif
|
|
|
|
};
|
2008-03-29 13:48:16 +03:00
|
|
|
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
static void x11font_really_draw_text(
|
|
|
|
const struct x11font_drawfuncs *dfns, unifont_drawctx *ctx,
|
|
|
|
x11font_individual *xfi, Display *disp,
|
|
|
|
int x, int y, const void *string, int nchars,
|
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 22:23:19 +03:00
|
|
|
int shadowoffset, bool fontvariable, int cellwidth)
|
2011-09-16 12:49:08 +04: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 22:23:19 +03:00
|
|
|
int start = 0, step, nsteps;
|
|
|
|
bool centre;
|
2011-09-16 12:49:08 +04:00
|
|
|
|
|
|
|
if (fontvariable) {
|
2019-09-08 22:29:00 +03:00
|
|
|
/*
|
|
|
|
* In a variable-pitch font, we draw one character at a
|
|
|
|
* time, and centre it in the character cell.
|
|
|
|
*/
|
|
|
|
step = 1;
|
|
|
|
nsteps = nchars;
|
|
|
|
centre = true;
|
2011-09-16 12:49:08 +04:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* In a fixed-pitch font, we can draw the whole lot in one go.
|
|
|
|
*/
|
|
|
|
step = nchars;
|
|
|
|
nsteps = 1;
|
2018-10-29 22:50:29 +03:00
|
|
|
centre = false;
|
2011-09-16 12:49:08 +04:00
|
|
|
}
|
|
|
|
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
dfns->setup(ctx, xfi, disp);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
|
2011-09-16 12:49:08 +04:00
|
|
|
while (nsteps-- > 0) {
|
2019-09-08 22:29:00 +03:00
|
|
|
int X = x;
|
|
|
|
if (centre)
|
|
|
|
X += (cellwidth - dfns->width(ctx, xfi, string, start, step)) / 2;
|
2011-09-16 12:49:08 +04:00
|
|
|
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
dfns->draw(ctx, xfi, disp, X, y, string, start, step);
|
2019-09-08 22:29:00 +03:00
|
|
|
if (shadowoffset)
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
dfns->draw(ctx, xfi, disp, X + shadowoffset, y,
|
|
|
|
string, start, step);
|
2011-09-16 12:49:08 +04:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
x += cellwidth;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
start += step;
|
2011-09-16 12:49:08 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static void x11font_draw_text(unifont_drawctx *ctx, unifont *font,
|
2019-09-08 22:29:00 +03:00
|
|
|
int x, int y, const wchar_t *string, int len,
|
|
|
|
bool wide, bool bold, int cellwidth)
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
struct x11font *xfont = container_of(font, struct x11font, u);
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
int sfid;
|
2011-09-16 12:49:08 +04:00
|
|
|
int shadowoffset = 0;
|
2008-03-29 13:48:16 +03:00
|
|
|
int mult = (wide ? 2 : 1);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
int index = 2 * (int)ctx->type;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03: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 22:23:19 +03:00
|
|
|
wide = wide && !xfont->wide;
|
|
|
|
bold = bold && !xfont->bold;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Decide which subfont we're using, and whether we have to
|
|
|
|
* use shadow bold.
|
|
|
|
*/
|
|
|
|
if (xfont->shadowalways && bold) {
|
2019-09-08 22:29:00 +03:00
|
|
|
shadowoffset = xfont->shadowoffset;
|
|
|
|
bold = false;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
|
|
|
sfid = 2 * wide + bold;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
if (!xfont->fonts[sfid].allocated)
|
2019-09-08 22:29:00 +03:00
|
|
|
x11_alloc_subfont(xfont, sfid);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
if (bold && !xfont->fonts[sfid].xfs) {
|
2019-09-08 22:29:00 +03:00
|
|
|
bold = false;
|
|
|
|
shadowoffset = xfont->shadowoffset;
|
|
|
|
sfid = 2 * wide + bold;
|
|
|
|
if (!xfont->fonts[sfid].allocated)
|
|
|
|
x11_alloc_subfont(xfont, sfid);
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
if (!xfont->fonts[sfid].xfs)
|
2019-09-08 22:29:00 +03:00
|
|
|
return; /* we've tried our best, but no luck */
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
|
|
|
|
if (xfont->sixteen_bit) {
|
2019-09-08 22:29:00 +03:00
|
|
|
/*
|
|
|
|
* This X font has 16-bit character indices, which means
|
|
|
|
* we can directly use our Unicode input string.
|
|
|
|
*/
|
|
|
|
XChar2b *xcs;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
xcs = snewn(len, XChar2b);
|
|
|
|
for (i = 0; i < len; i++) {
|
|
|
|
xcs[i].byte1 = string[i] >> 8;
|
|
|
|
xcs[i].byte2 = string[i];
|
|
|
|
}
|
|
|
|
|
|
|
|
x11font_really_draw_text(x11font_drawfuncs + index + 1, ctx,
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
&xfont->fonts[sfid], xfont->disp, x, y,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
xcs, len, shadowoffset,
|
|
|
|
xfont->variable, cellwidth * mult);
|
2019-09-08 22:29:00 +03:00
|
|
|
sfree(xcs);
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
} else {
|
2011-09-16 23:18:53 +04:00
|
|
|
/*
|
|
|
|
* This X font has 8-bit indices, so we must convert to the
|
|
|
|
* appropriate character set.
|
|
|
|
*/
|
|
|
|
char *sbstring = snewn(len+1, char);
|
|
|
|
int sblen = wc_to_mb(xfont->real_charset, 0, string, len,
|
2018-10-06 13:45:26 +03:00
|
|
|
sbstring, len+1, ".", NULL);
|
2019-09-08 22:29:00 +03:00
|
|
|
x11font_really_draw_text(x11font_drawfuncs + index + 0, ctx,
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
&xfont->fonts[sfid], xfont->disp, x, y,
|
2019-09-08 22:29:00 +03:00
|
|
|
sbstring, sblen, shadowoffset,
|
|
|
|
xfont->variable, cellwidth * mult);
|
2011-09-16 23:18:53 +04:00
|
|
|
sfree(sbstring);
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-26 12:18:53 +03:00
|
|
|
static void x11font_draw_combining(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string,
|
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 22:23:19 +03:00
|
|
|
int len, bool wide, bool bold,
|
|
|
|
int cellwidth)
|
2015-09-26 12:18:53 +03:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* For server-side fonts, there's no sophisticated system for
|
|
|
|
* combining characters intelligently, so the best we can do is to
|
|
|
|
* overprint them on each other in the obvious way.
|
|
|
|
*/
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < len; i++)
|
|
|
|
x11font_draw_text(ctx, font, x, y, string+i, 1, wide, bold, cellwidth);
|
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
static void x11font_enum_fonts(GtkWidget *widget,
|
2019-09-08 22:29:00 +03:00
|
|
|
fontsel_add_entry callback, void *callback_ctx)
|
2008-03-26 00:49:14 +03:00
|
|
|
{
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
Display *disp;
|
2008-03-26 00:49:14 +03:00
|
|
|
char **fontnames;
|
|
|
|
char *tmp = NULL;
|
|
|
|
int nnames, i, max, tmpsize;
|
|
|
|
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
if ((disp = get_x11_display()) == NULL)
|
|
|
|
return;
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
max = 32768;
|
|
|
|
while (1) {
|
2019-09-08 22:29:00 +03:00
|
|
|
fontnames = XListFonts(disp, "*", max, &nnames);
|
|
|
|
if (nnames >= max) {
|
|
|
|
XFreeFontNames(fontnames);
|
|
|
|
max *= 2;
|
|
|
|
} else
|
|
|
|
break;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
tmpsize = 0;
|
|
|
|
|
|
|
|
for (i = 0; i < nnames; i++) {
|
2016-11-13 15:02:13 +03:00
|
|
|
struct xlfd_decomposed *xlfd = xlfd_decompose(fontnames[i]);
|
2019-09-08 22:29:00 +03:00
|
|
|
if (xlfd) {
|
2016-11-13 15:02:13 +03:00
|
|
|
char *p, *font, *style, *stylekey, *charset;
|
|
|
|
int weightkey, slantkey, setwidthkey;
|
|
|
|
int thistmpsize;
|
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
/*
|
|
|
|
* Convert a dismembered XLFD into the format we'll be
|
|
|
|
* using in the font selector.
|
|
|
|
*/
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2016-11-13 15:02:13 +03:00
|
|
|
thistmpsize = 4 * strlen(fontnames[i]) + 256;
|
|
|
|
if (tmpsize < thistmpsize) {
|
|
|
|
tmpsize = thistmpsize;
|
|
|
|
tmp = sresize(tmp, tmpsize, char);
|
|
|
|
}
|
2019-09-08 22:29:00 +03:00
|
|
|
p = tmp;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Font name is in the form "family (foundry)". (This is
|
|
|
|
* what the GTK 1.2 X font selector does, and it seems to
|
|
|
|
* come out looking reasonably sensible.)
|
|
|
|
*/
|
|
|
|
font = p;
|
|
|
|
p += 1 + sprintf(p, "%s (%s)", xlfd->family_name, xlfd->foundry);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Character set.
|
|
|
|
*/
|
|
|
|
charset = p;
|
|
|
|
p += 1 + sprintf(p, "%s-%s", xlfd->charset_registry,
|
2016-11-13 15:02:13 +03:00
|
|
|
xlfd->charset_encoding);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
/*
|
|
|
|
* Style is a mixture of quite a lot of the fields,
|
|
|
|
* with some strange formatting.
|
|
|
|
*/
|
|
|
|
style = p;
|
|
|
|
p += sprintf(p, "%s", xlfd->weight_name[0] ? xlfd->weight_name :
|
|
|
|
"regular");
|
|
|
|
if (!g_ascii_strcasecmp(xlfd->slant, "i"))
|
|
|
|
p += sprintf(p, " italic");
|
|
|
|
else if (!g_ascii_strcasecmp(xlfd->slant, "o"))
|
|
|
|
p += sprintf(p, " oblique");
|
|
|
|
else if (!g_ascii_strcasecmp(xlfd->slant, "ri"))
|
|
|
|
p += sprintf(p, " reverse italic");
|
|
|
|
else if (!g_ascii_strcasecmp(xlfd->slant, "ro"))
|
|
|
|
p += sprintf(p, " reverse oblique");
|
|
|
|
else if (!g_ascii_strcasecmp(xlfd->slant, "ot"))
|
|
|
|
p += sprintf(p, " other-slant");
|
|
|
|
if (xlfd->setwidth_name[0] &&
|
2016-11-13 15:02:13 +03:00
|
|
|
g_ascii_strcasecmp(xlfd->setwidth_name, "normal"))
|
2019-09-08 22:29:00 +03:00
|
|
|
p += sprintf(p, " %s", xlfd->setwidth_name);
|
|
|
|
if (!g_ascii_strcasecmp(xlfd->spacing, "m"))
|
|
|
|
p += sprintf(p, " [M]");
|
|
|
|
if (!g_ascii_strcasecmp(xlfd->spacing, "c"))
|
|
|
|
p += sprintf(p, " [C]");
|
|
|
|
if (xlfd->add_style_name[0])
|
|
|
|
p += sprintf(p, " %s", xlfd->add_style_name);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Style key is the same stuff as above, but with a
|
|
|
|
* couple of transformations done on it to make it
|
|
|
|
* sort more sensibly.
|
|
|
|
*/
|
|
|
|
p++;
|
|
|
|
stylekey = p;
|
|
|
|
if (!g_ascii_strcasecmp(xlfd->weight_name, "medium") ||
|
|
|
|
!g_ascii_strcasecmp(xlfd->weight_name, "regular") ||
|
|
|
|
!g_ascii_strcasecmp(xlfd->weight_name, "normal") ||
|
|
|
|
!g_ascii_strcasecmp(xlfd->weight_name, "book"))
|
|
|
|
weightkey = 0;
|
|
|
|
else if (!g_ascii_strncasecmp(xlfd->weight_name, "demi", 4) ||
|
|
|
|
!g_ascii_strncasecmp(xlfd->weight_name, "semi", 4))
|
|
|
|
weightkey = 1;
|
|
|
|
else
|
|
|
|
weightkey = 2;
|
|
|
|
if (!g_ascii_strcasecmp(xlfd->slant, "r"))
|
|
|
|
slantkey = 0;
|
|
|
|
else if (!g_ascii_strncasecmp(xlfd->slant, "r", 1))
|
|
|
|
slantkey = 2;
|
|
|
|
else
|
|
|
|
slantkey = 1;
|
|
|
|
if (!g_ascii_strcasecmp(xlfd->setwidth_name, "normal"))
|
|
|
|
setwidthkey = 0;
|
|
|
|
else
|
|
|
|
setwidthkey = 1;
|
|
|
|
|
|
|
|
p += sprintf(
|
2016-11-13 15:02:13 +03:00
|
|
|
p, "%04d%04d%s%04d%04d%s%04d%04d%s%04d%s%04d%s",
|
|
|
|
weightkey, (int)strlen(xlfd->weight_name), xlfd->weight_name,
|
|
|
|
slantkey, (int)strlen(xlfd->slant), xlfd->slant,
|
|
|
|
setwidthkey,
|
|
|
|
(int)strlen(xlfd->setwidth_name), xlfd->setwidth_name,
|
|
|
|
(int)strlen(xlfd->spacing), xlfd->spacing,
|
|
|
|
(int)strlen(xlfd->add_style_name), xlfd->add_style_name);
|
2008-03-27 00:33:10 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
assert(p - tmp < thistmpsize);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Flags: we need to know whether this is a monospaced
|
|
|
|
* font, which we do by examining the spacing field
|
|
|
|
* again.
|
|
|
|
*/
|
2020-01-30 09:40:21 +03:00
|
|
|
int flags = FONTFLAG_SERVERSIDE;
|
2019-09-08 22:29:00 +03:00
|
|
|
if (!strchr("CcMm", xlfd->spacing[0]))
|
|
|
|
flags |= FONTFLAG_NONMONOSPACED;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Some fonts have a pixel size of zero, meaning they're
|
|
|
|
* treated as scalable. For these purposes, we only want
|
|
|
|
* fonts whose pixel size we actually know, so filter
|
|
|
|
* those out.
|
|
|
|
*/
|
|
|
|
if (xlfd->pixel_size)
|
2016-11-13 15:02:13 +03:00
|
|
|
callback(callback_ctx, fontnames[i], font, charset,
|
|
|
|
style, stylekey, xlfd->pixel_size, flags,
|
|
|
|
&x11font_vtable);
|
|
|
|
|
|
|
|
sfree(xlfd);
|
2019-09-08 22:29:00 +03:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* This isn't an XLFD, so it must be an alias.
|
|
|
|
* Transmit it with mostly null data.
|
|
|
|
*
|
|
|
|
* It would be nice to work out if it's monospaced
|
|
|
|
* here, but at the moment I can't see that being
|
|
|
|
* anything but computationally hideous. Ah well.
|
|
|
|
*/
|
|
|
|
callback(callback_ctx, fontnames[i], fontnames[i], NULL,
|
|
|
|
NULL, NULL, 0, FONTFLAG_SERVERALIAS, &x11font_vtable);
|
2016-11-13 15:02:13 +03:00
|
|
|
|
|
|
|
sfree(xlfd);
|
2019-09-08 22:29:00 +03:00
|
|
|
}
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
XFreeFontNames(fontnames);
|
2017-02-14 23:42:26 +03:00
|
|
|
sfree(tmp);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static char *x11font_canonify_fontname(GtkWidget *widget, const char *name,
|
2019-09-08 22:29:00 +03:00
|
|
|
int *size, int *flags,
|
|
|
|
bool resolve_aliases)
|
2008-03-26 00:49:14 +03:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* When given an X11 font name to try to make sense of for a
|
|
|
|
* font selector, we must attempt to load it (to see if it
|
|
|
|
* exists), and then canonify it by extracting its FONT
|
|
|
|
* property, which should give its full XLFD even if what we
|
2008-03-27 22:41:08 +03:00
|
|
|
* originally had was a wildcard.
|
2019-09-08 22:29:00 +03:00
|
|
|
*
|
2008-03-27 22:41:08 +03:00
|
|
|
* However, we must carefully avoid canonifying font
|
|
|
|
* _aliases_, unless specifically asked to, because the font
|
|
|
|
* selector treats them as worthwhile in their own right.
|
2008-03-26 00:49:14 +03:00
|
|
|
*/
|
|
|
|
XFontStruct *xfs;
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
Display *disp;
|
2008-03-26 00:49:14 +03:00
|
|
|
Atom fontprop, fontprop2;
|
|
|
|
unsigned long ret;
|
|
|
|
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
if ((disp = get_x11_display()) == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
2011-09-16 12:49:08 +04:00
|
|
|
xfs = XLoadQueryFont(disp, name);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2011-09-16 12:49:08 +04:00
|
|
|
if (!xfs)
|
2019-09-08 22:29:00 +03:00
|
|
|
return NULL; /* didn't make sense to us, sorry */
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
fontprop = XInternAtom(disp, "FONT", False);
|
|
|
|
|
|
|
|
if (XGetFontProperty(xfs, fontprop, &ret)) {
|
2019-09-08 22:29:00 +03:00
|
|
|
char *newname = XGetAtomName(disp, (Atom)ret);
|
|
|
|
if (newname) {
|
|
|
|
unsigned long fsize = 12;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
fontprop2 = XInternAtom(disp, "PIXEL_SIZE", False);
|
|
|
|
if (XGetFontProperty(xfs, fontprop2, &fsize) && fsize > 0) {
|
|
|
|
*size = fsize;
|
2011-09-16 12:49:08 +04:00
|
|
|
XFreeFont(disp, xfs);
|
2019-09-08 22:29:00 +03:00
|
|
|
if (flags) {
|
|
|
|
if (name[0] == '-' || resolve_aliases)
|
|
|
|
*flags = FONTFLAG_SERVERSIDE;
|
|
|
|
else
|
|
|
|
*flags = FONTFLAG_SERVERALIAS;
|
|
|
|
}
|
|
|
|
return dupstr(name[0] == '-' || resolve_aliases ?
|
|
|
|
newname : name);
|
|
|
|
}
|
|
|
|
}
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
2011-09-16 12:49:08 +04:00
|
|
|
XFreeFont(disp, xfs);
|
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
return NULL; /* something went wrong */
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static char *x11font_scale_fontname(GtkWidget *widget, const char *name,
|
2019-09-08 22:29:00 +03:00
|
|
|
int size)
|
2008-03-26 00:49:14 +03:00
|
|
|
{
|
2019-09-08 22:29:00 +03:00
|
|
|
return NULL; /* shan't */
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
2016-11-13 16:53:42 +03:00
|
|
|
static char *x11font_size_increment(unifont *font, int increment)
|
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
struct x11font *xfont = container_of(font, struct x11font, u);
|
Basic support for running under GDK Wayland back end.
GTK 3 PuTTY/pterm has always assumed that if it was compiled with
_support_ for talking to the raw X11 layer underneath GTK and GDK,
then it was entitled to expect that raw X11 layer to exist at all
times, i.e. that GDK_DISPLAY_XDISPLAY would return a meaningful X
display that it could do useful things with. So if you ran it over the
GDK Wayland backend, it would immediately segfault.
Modern GTK applications need to cope with multiple GDK backends at run
time. It's fine for GTK PuTTY to _contain_ the code to find and use
underlying X11 primitives like the display and the X window id, but it
should be prepared to find that it's running on Wayland (or something
else again!) so those functions don't return anything useful - in
which case it should degrade gracefully to the subset of functionality
that can be accessed through backend-independent GTK calls.
Accordingly, I've centralised the use of GDK_DISPLAY_XDISPLAY into a
support function get_x_display() in gtkmisc.c, which starts by
checking that there actually is one first. All previous direct uses of
GDK_*_XDISPLAY now go via that function, and check the result for NULL
afterwards. (To save faffing about calling that function too many
times, I'm also caching the display pointer in more places, and
passing it as an extra argument to various subfunctions, mostly in
gtkfont.c.)
Similarly, the get_windowid() function that retrieves the window id to
put in the environment of pterm's child process has to be prepared for
there not to be a window id.
This isn't a complete fix for all Wayland-related problems. The other
one I'm currently aware of is that the default font is "server:fixed",
which is a bad default now that it won't be available on all backends.
And I expect that further problems will show up with more testing. But
it's a start.
2018-05-09 11:18:20 +03:00
|
|
|
Display *disp = xfont->disp;
|
2016-11-13 16:53:42 +03:00
|
|
|
Atom fontprop = XInternAtom(disp, "FONT", False);
|
|
|
|
char *returned_name = NULL;
|
|
|
|
unsigned long ret;
|
|
|
|
if (XGetFontProperty(xfont->fonts[0].xfs, fontprop, &ret)) {
|
|
|
|
struct xlfd_decomposed *xlfd;
|
|
|
|
struct xlfd_decomposed *xlfd_best;
|
|
|
|
char *wc;
|
|
|
|
char **fontnames;
|
|
|
|
int nnames, i, max;
|
|
|
|
|
|
|
|
xlfd = xlfd_decompose(XGetAtomName(disp, (Atom)ret));
|
|
|
|
if (!xlfd)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Form a wildcard consisting of everything in the
|
|
|
|
* original XLFD except for the size-related fields.
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
struct xlfd_decomposed xlfd_wc = *xlfd; /* structure copy */
|
|
|
|
xlfd_wc.pixel_size = XLFD_INT_WILDCARD;
|
|
|
|
xlfd_wc.point_size = XLFD_INT_WILDCARD;
|
|
|
|
xlfd_wc.average_width = XLFD_INT_WILDCARD;
|
|
|
|
wc = xlfd_recompose(&xlfd_wc);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Fetch all the font names matching that wildcard.
|
|
|
|
*/
|
|
|
|
max = 32768;
|
|
|
|
while (1) {
|
|
|
|
fontnames = XListFonts(disp, wc, max, &nnames);
|
|
|
|
if (nnames >= max) {
|
|
|
|
XFreeFontNames(fontnames);
|
|
|
|
max *= 2;
|
|
|
|
} else
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
sfree(wc);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Iterate over those to find the one closest in size to the
|
|
|
|
* original font, in the correct direction.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define FLIPPED_SIZE(xlfd) \
|
|
|
|
(((xlfd)->pixel_size + (xlfd)->point_size) * \
|
|
|
|
(increment < 0 ? -1 : +1))
|
|
|
|
|
|
|
|
xlfd_best = NULL;
|
|
|
|
for (i = 0; i < nnames; i++) {
|
|
|
|
struct xlfd_decomposed *xlfd2 = xlfd_decompose(fontnames[i]);
|
|
|
|
if (!xlfd2)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (xlfd2->pixel_size != 0 &&
|
|
|
|
FLIPPED_SIZE(xlfd2) > FLIPPED_SIZE(xlfd) &&
|
|
|
|
(!xlfd_best || FLIPPED_SIZE(xlfd2)<FLIPPED_SIZE(xlfd_best))) {
|
|
|
|
sfree(xlfd_best);
|
|
|
|
xlfd_best = xlfd2;
|
|
|
|
xlfd2 = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
sfree(xlfd2);
|
|
|
|
}
|
|
|
|
|
|
|
|
#undef FLIPPED_SIZE
|
|
|
|
|
2016-11-17 01:02:54 +03:00
|
|
|
if (xlfd_best) {
|
|
|
|
char *bare_returned_name = xlfd_recompose(xlfd_best);
|
|
|
|
returned_name = dupcat(
|
Make dupcat() into a variadic macro.
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.
2019-10-14 21:42:37 +03:00
|
|
|
xfont->u.vt->prefix, ":", bare_returned_name);
|
2016-11-17 01:02:54 +03:00
|
|
|
sfree(bare_returned_name);
|
|
|
|
}
|
2016-11-13 16:53:42 +03:00
|
|
|
|
|
|
|
XFreeFontNames(fontnames);
|
|
|
|
sfree(xlfd);
|
|
|
|
sfree(xlfd_best);
|
|
|
|
}
|
|
|
|
return returned_name;
|
|
|
|
}
|
|
|
|
|
2015-08-08 18:35:19 +03:00
|
|
|
#endif /* NOT_X_WINDOWS */
|
|
|
|
|
2008-04-04 14:56:26 +04:00
|
|
|
#if GTK_CHECK_VERSION(2,0,0)
|
|
|
|
|
2008-03-22 21:11:17 +03:00
|
|
|
/* ----------------------------------------------------------------------
|
2008-04-04 14:56:26 +04:00
|
|
|
* Pango font implementation (for GTK 2 only).
|
2008-03-22 21:11:17 +03:00
|
|
|
*/
|
|
|
|
|
2008-05-31 23:23:45 +04:00
|
|
|
#if defined PANGO_PRE_1POINT4 && !defined PANGO_PRE_1POINT6
|
2019-09-08 22:29:00 +03:00
|
|
|
#define PANGO_PRE_1POINT6 /* make life easier for pre-1.4 folk */
|
2008-05-31 23:23:45 +04:00
|
|
|
#endif
|
|
|
|
|
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 22:23:19 +03:00
|
|
|
static bool pangofont_has_glyph(unifont *font, wchar_t glyph);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static void pangofont_draw_text(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string, int len,
|
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 22:23:19 +03:00
|
|
|
bool wide, bool bold, int cellwidth);
|
2015-09-26 12:18:53 +03:00
|
|
|
static void pangofont_draw_combining(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string,
|
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 22:23:19 +03:00
|
|
|
int len, bool wide, bool bold,
|
2015-09-26 12:18:53 +03:00
|
|
|
int cellwidth);
|
2008-03-26 00:49:14 +03:00
|
|
|
static unifont *pangofont_create(GtkWidget *widget, const char *name,
|
2019-09-08 22:29:00 +03:00
|
|
|
bool wide, bool bold,
|
|
|
|
int shadowoffset, bool shadowalways);
|
2011-09-16 23:18:54 +04:00
|
|
|
static unifont *pangofont_create_fallback(GtkWidget *widget, int height,
|
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 22:23:19 +03:00
|
|
|
bool wide, bool bold,
|
|
|
|
int shadowoffset, bool shadowalways);
|
2008-03-22 21:11:17 +03:00
|
|
|
static void pangofont_destroy(unifont *font);
|
2008-03-26 00:49:14 +03:00
|
|
|
static void pangofont_enum_fonts(GtkWidget *widget, fontsel_add_entry callback,
|
2019-09-08 22:29:00 +03:00
|
|
|
void *callback_ctx);
|
2008-03-26 00:49:14 +03:00
|
|
|
static char *pangofont_canonify_fontname(GtkWidget *widget, const char *name,
|
2019-09-08 22:29:00 +03:00
|
|
|
int *size, int *flags,
|
|
|
|
bool resolve_aliases);
|
2008-03-26 00:49:14 +03:00
|
|
|
static char *pangofont_scale_fontname(GtkWidget *widget, const char *name,
|
2019-09-08 22:29:00 +03:00
|
|
|
int size);
|
2016-11-13 16:53:42 +03:00
|
|
|
static char *pangofont_size_increment(unifont *font, int increment);
|
2008-03-22 21:11:17 +03:00
|
|
|
|
|
|
|
struct pangofont {
|
|
|
|
/*
|
|
|
|
* Pango objects.
|
|
|
|
*/
|
|
|
|
PangoFontDescription *desc;
|
|
|
|
PangoFontset *fset;
|
|
|
|
/*
|
|
|
|
* The containing widget.
|
|
|
|
*/
|
|
|
|
GtkWidget *widget;
|
|
|
|
/*
|
|
|
|
* Data passed in to unifont_create().
|
|
|
|
*/
|
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 22:23:19 +03:00
|
|
|
int shadowoffset;
|
|
|
|
bool bold, shadowalways;
|
2015-08-23 16:13:30 +03:00
|
|
|
/*
|
|
|
|
* Cache of character widths, indexed by Unicode code point. In
|
|
|
|
* pixels; -1 means we haven't asked Pango about this character
|
|
|
|
* before.
|
|
|
|
*/
|
|
|
|
int *widthcache;
|
|
|
|
unsigned nwidthcache;
|
2018-10-05 09:02:19 +03:00
|
|
|
|
|
|
|
struct unifont u;
|
2008-03-22 21:11:17 +03:00
|
|
|
};
|
|
|
|
|
Change vtable defs to use C99 designated initialisers.
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.
2020-03-11 00:06:29 +03:00
|
|
|
static const UnifontVtable pangofont_vtable = {
|
|
|
|
.create = pangofont_create,
|
|
|
|
.create_fallback = pangofont_create_fallback,
|
|
|
|
.destroy = pangofont_destroy,
|
|
|
|
.has_glyph = pangofont_has_glyph,
|
|
|
|
.draw_text = pangofont_draw_text,
|
|
|
|
.draw_combining = pangofont_draw_combining,
|
|
|
|
.enum_fonts = pangofont_enum_fonts,
|
|
|
|
.canonify_fontname = pangofont_canonify_fontname,
|
|
|
|
.scale_fontname = pangofont_scale_fontname,
|
|
|
|
.size_increment = pangofont_size_increment,
|
|
|
|
.prefix = "client",
|
2008-03-22 21:11:17 +03:00
|
|
|
};
|
|
|
|
|
2008-03-29 18:44:32 +03:00
|
|
|
/*
|
|
|
|
* This function is used to rigorously validate a
|
|
|
|
* PangoFontDescription. Later versions of Pango have a nasty
|
|
|
|
* habit of accepting _any_ old string as input to
|
|
|
|
* pango_font_description_from_string and returning a font
|
|
|
|
* description which can actually be used to display text, even if
|
|
|
|
* they have to do it by falling back to their most default font.
|
|
|
|
* This is doubtless helpful in some situations, but not here,
|
|
|
|
* because we need to know if a Pango font string actually _makes
|
|
|
|
* sense_ in order to fall back to treating it as an X font name
|
|
|
|
* if it doesn't. So we check that the font family is actually one
|
|
|
|
* supported by Pango.
|
|
|
|
*/
|
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 22:23:19 +03:00
|
|
|
static bool pangofont_check_desc_makes_sense(PangoContext *ctx,
|
|
|
|
PangoFontDescription *desc)
|
2008-03-29 18:44:32 +03:00
|
|
|
{
|
|
|
|
#ifndef PANGO_PRE_1POINT6
|
|
|
|
PangoFontMap *map;
|
|
|
|
#endif
|
|
|
|
PangoFontFamily **families;
|
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 22:23:19 +03:00
|
|
|
int i, nfamilies;
|
|
|
|
bool matched;
|
2008-03-29 18:44:32 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Ask Pango for a list of font families, and iterate through
|
|
|
|
* them to see if one of them matches the family in the
|
|
|
|
* PangoFontDescription.
|
|
|
|
*/
|
|
|
|
#ifndef PANGO_PRE_1POINT6
|
|
|
|
map = pango_context_get_font_map(ctx);
|
|
|
|
if (!map)
|
2019-09-08 22:29:00 +03:00
|
|
|
return false;
|
2008-03-29 18:44:32 +03:00
|
|
|
pango_font_map_list_families(map, &families, &nfamilies);
|
|
|
|
#else
|
|
|
|
pango_context_list_families(ctx, &families, &nfamilies);
|
|
|
|
#endif
|
|
|
|
|
2018-10-29 22:50:29 +03:00
|
|
|
matched = false;
|
2008-03-29 18:44:32 +03:00
|
|
|
for (i = 0; i < nfamilies; i++) {
|
2019-09-08 22:29:00 +03:00
|
|
|
if (!g_ascii_strcasecmp(pango_font_family_get_name(families[i]),
|
|
|
|
pango_font_description_get_family(desc))) {
|
|
|
|
matched = true;
|
|
|
|
break;
|
|
|
|
}
|
2008-03-29 18:44:32 +03:00
|
|
|
}
|
|
|
|
g_free(families);
|
|
|
|
|
|
|
|
return matched;
|
|
|
|
}
|
|
|
|
|
2011-09-16 23:18:54 +04:00
|
|
|
static unifont *pangofont_create_internal(GtkWidget *widget,
|
|
|
|
PangoContext *ctx,
|
|
|
|
PangoFontDescription *desc,
|
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 22:23:19 +03:00
|
|
|
bool wide, bool bold,
|
|
|
|
int shadowoffset, bool shadowalways)
|
2008-03-22 21:11:17 +03:00
|
|
|
{
|
|
|
|
struct pangofont *pfont;
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT6
|
2008-03-22 21:11:17 +03:00
|
|
|
PangoFontMap *map;
|
2008-03-26 21:30:20 +03:00
|
|
|
#endif
|
2008-03-22 21:11:17 +03:00
|
|
|
PangoFontset *fset;
|
|
|
|
PangoFontMetrics *metrics;
|
|
|
|
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT6
|
2008-03-22 21:11:17 +03:00
|
|
|
map = pango_context_get_font_map(ctx);
|
|
|
|
if (!map) {
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
2008-03-22 21:11:17 +03:00
|
|
|
}
|
|
|
|
fset = pango_font_map_load_fontset(map, ctx, desc,
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_context_get_language(ctx));
|
2008-03-26 21:30:20 +03:00
|
|
|
#else
|
|
|
|
fset = pango_context_load_fontset(ctx, desc,
|
|
|
|
pango_context_get_language(ctx));
|
|
|
|
#endif
|
2008-03-22 21:11:17 +03:00
|
|
|
if (!fset) {
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
2008-03-22 21:11:17 +03:00
|
|
|
}
|
|
|
|
metrics = pango_fontset_get_metrics(fset);
|
|
|
|
if (!metrics ||
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_font_metrics_get_approximate_digit_width(metrics) == 0) {
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
g_object_unref(fset);
|
|
|
|
return NULL;
|
2008-03-22 21:11:17 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
pfont = snew(struct pangofont);
|
|
|
|
pfont->u.vt = &pangofont_vtable;
|
|
|
|
pfont->u.width =
|
2019-09-08 22:29:00 +03:00
|
|
|
PANGO_PIXELS(pango_font_metrics_get_approximate_digit_width(metrics));
|
2020-04-05 13:20:25 +03:00
|
|
|
pfont->u.ascent =
|
|
|
|
PANGO_PIXELS_CEIL(pango_font_metrics_get_ascent(metrics));
|
|
|
|
pfont->u.descent =
|
|
|
|
PANGO_PIXELS_CEIL(pango_font_metrics_get_descent(metrics));
|
2008-03-22 21:11:17 +03:00
|
|
|
pfont->u.height = pfont->u.ascent + pfont->u.descent;
|
2020-08-13 23:08:53 +03:00
|
|
|
pfont->u.strikethrough_y =
|
|
|
|
PANGO_PIXELS(pango_font_metrics_get_ascent(metrics) -
|
|
|
|
pango_font_metrics_get_strikethrough_position(metrics));
|
2018-10-29 22:50:29 +03:00
|
|
|
pfont->u.want_fallback = false;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
pfont->u.preferred_drawtype = DRAWTYPE_CAIRO;
|
|
|
|
#elif defined DRAW_TEXT_GDK
|
|
|
|
pfont->u.preferred_drawtype = DRAWTYPE_GDK;
|
|
|
|
#else
|
|
|
|
#error No drawtype available at all
|
|
|
|
#endif
|
2008-03-22 21:11:17 +03:00
|
|
|
/* The Pango API is hardwired to UTF-8 */
|
|
|
|
pfont->u.public_charset = CS_UTF8;
|
|
|
|
pfont->desc = desc;
|
|
|
|
pfont->fset = fset;
|
|
|
|
pfont->widget = widget;
|
|
|
|
pfont->bold = bold;
|
|
|
|
pfont->shadowoffset = shadowoffset;
|
|
|
|
pfont->shadowalways = shadowalways;
|
2015-08-23 16:13:30 +03:00
|
|
|
pfont->widthcache = NULL;
|
|
|
|
pfont->nwidthcache = 0;
|
2008-03-22 21:11:17 +03:00
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
pango_font_metrics_unref(metrics);
|
|
|
|
|
2018-10-05 09:02:19 +03:00
|
|
|
return &pfont->u;
|
2008-03-22 21:11:17 +03:00
|
|
|
}
|
|
|
|
|
2011-09-16 23:18:54 +04:00
|
|
|
static unifont *pangofont_create(GtkWidget *widget, const char *name,
|
2019-09-08 22:29:00 +03:00
|
|
|
bool wide, bool bold,
|
|
|
|
int shadowoffset, bool shadowalways)
|
2011-09-16 23:18:54 +04:00
|
|
|
{
|
|
|
|
PangoContext *ctx;
|
|
|
|
PangoFontDescription *desc;
|
|
|
|
|
|
|
|
desc = pango_font_description_from_string(name);
|
|
|
|
if (!desc)
|
2019-09-08 22:29:00 +03:00
|
|
|
return NULL;
|
2011-09-16 23:18:54 +04:00
|
|
|
ctx = gtk_widget_get_pango_context(widget);
|
|
|
|
if (!ctx) {
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
2011-09-16 23:18:54 +04:00
|
|
|
}
|
|
|
|
if (!pangofont_check_desc_makes_sense(ctx, desc)) {
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
2011-09-16 23:18:54 +04:00
|
|
|
}
|
|
|
|
return pangofont_create_internal(widget, ctx, desc, wide, bold,
|
|
|
|
shadowoffset, shadowalways);
|
|
|
|
}
|
|
|
|
|
|
|
|
static unifont *pangofont_create_fallback(GtkWidget *widget, int height,
|
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 22:23:19 +03:00
|
|
|
bool wide, bool bold,
|
|
|
|
int shadowoffset, bool shadowalways)
|
2011-09-16 23:18:54 +04:00
|
|
|
{
|
|
|
|
PangoContext *ctx;
|
|
|
|
PangoFontDescription *desc;
|
|
|
|
|
|
|
|
desc = pango_font_description_from_string("Monospace");
|
|
|
|
if (!desc)
|
2019-09-08 22:29:00 +03:00
|
|
|
return NULL;
|
2011-09-16 23:18:54 +04:00
|
|
|
ctx = gtk_widget_get_pango_context(widget);
|
|
|
|
if (!ctx) {
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
2011-09-16 23:18:54 +04:00
|
|
|
}
|
|
|
|
pango_font_description_set_absolute_size(desc, height * PANGO_SCALE);
|
|
|
|
return pangofont_create_internal(widget, ctx, desc, wide, bold,
|
|
|
|
shadowoffset, shadowalways);
|
|
|
|
}
|
|
|
|
|
2008-03-22 21:11:17 +03:00
|
|
|
static void pangofont_destroy(unifont *font)
|
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
struct pangofont *pfont = container_of(font, struct pangofont, u);
|
2008-03-22 21:11:17 +03:00
|
|
|
pango_font_description_free(pfont->desc);
|
2015-08-23 16:13:30 +03:00
|
|
|
sfree(pfont->widthcache);
|
2008-03-22 21:11:17 +03:00
|
|
|
g_object_unref(pfont->fset);
|
2018-10-05 09:02:19 +03:00
|
|
|
sfree(pfont);
|
2008-03-22 21:11:17 +03:00
|
|
|
}
|
|
|
|
|
2015-08-23 16:13:30 +03:00
|
|
|
static int pangofont_char_width(PangoLayout *layout, struct pangofont *pfont,
|
|
|
|
wchar_t uchr, const char *utfchr, int utflen)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Here we check whether a character has the same width as the
|
|
|
|
* character cell it'll be drawn in. Because profiling showed that
|
2015-08-31 18:37:05 +03:00
|
|
|
* asking Pango for text sizes was a huge bottleneck when we were
|
|
|
|
* calling it every time we needed to know this, we instead call
|
|
|
|
* it only on characters we don't already know about, and cache
|
|
|
|
* the results.
|
2015-08-23 16:13:30 +03:00
|
|
|
*/
|
|
|
|
|
|
|
|
if ((unsigned)uchr >= pfont->nwidthcache) {
|
|
|
|
unsigned newsize = ((int)uchr + 0x100) & ~0xFF;
|
|
|
|
pfont->widthcache = sresize(pfont->widthcache, newsize, int);
|
|
|
|
while (pfont->nwidthcache < newsize)
|
|
|
|
pfont->widthcache[pfont->nwidthcache++] = -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pfont->widthcache[uchr] < 0) {
|
|
|
|
PangoRectangle rect;
|
|
|
|
pango_layout_set_text(layout, utfchr, utflen);
|
2015-08-31 18:37:05 +03:00
|
|
|
pango_layout_get_extents(layout, NULL, &rect);
|
2015-08-23 16:13:30 +03:00
|
|
|
pfont->widthcache[uchr] = rect.width;
|
|
|
|
}
|
|
|
|
|
|
|
|
return pfont->widthcache[uchr];
|
|
|
|
}
|
|
|
|
|
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 22:23:19 +03:00
|
|
|
static bool pangofont_has_glyph(unifont *font, wchar_t glyph)
|
2011-09-16 23:18:54 +04:00
|
|
|
{
|
|
|
|
/* Pango implements font fallback, so assume it has everything */
|
2018-10-29 22:50:29 +03:00
|
|
|
return true;
|
2011-09-16 23:18:54 +04:00
|
|
|
}
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#ifdef DRAW_TEXT_GDK
|
|
|
|
static void pango_gdk_draw_layout(unifont_drawctx *ctx,
|
|
|
|
gint x, gint y, PangoLayout *layout)
|
|
|
|
{
|
|
|
|
gdk_draw_layout(ctx->u.gdk.target, ctx->u.gdk.gc, x, y, layout);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
static void pango_cairo_draw_layout(unifont_drawctx *ctx,
|
|
|
|
gint x, gint y, PangoLayout *layout)
|
|
|
|
{
|
|
|
|
cairo_move_to(ctx->u.cairo.cr, x, y);
|
|
|
|
pango_cairo_show_layout(ctx->u.cairo.cr, layout);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2015-09-26 12:18:53 +03:00
|
|
|
static void pangofont_draw_internal(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string,
|
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 22:23:19 +03:00
|
|
|
int len, bool wide, bool bold,
|
|
|
|
int cellwidth, bool combining)
|
2008-03-22 21:11:17 +03:00
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
struct pangofont *pfont = container_of(font, struct pangofont, u);
|
2008-03-22 21:11:17 +03:00
|
|
|
PangoLayout *layout;
|
|
|
|
PangoRectangle rect;
|
2011-09-16 23:18:53 +04:00
|
|
|
char *utfstring, *utfptr;
|
|
|
|
int utflen;
|
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 22:23:19 +03:00
|
|
|
bool shadowbold = false;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
void (*draw_layout)(unifont_drawctx *ctx,
|
|
|
|
gint x, gint y, PangoLayout *layout) = NULL;
|
|
|
|
|
|
|
|
#ifdef DRAW_TEXT_GDK
|
|
|
|
if (ctx->type == DRAWTYPE_GDK) {
|
|
|
|
draw_layout = pango_gdk_draw_layout;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
if (ctx->type == DRAWTYPE_CAIRO) {
|
|
|
|
draw_layout = pango_cairo_draw_layout;
|
|
|
|
}
|
|
|
|
#endif
|
2018-12-01 17:13:37 +03:00
|
|
|
assert(draw_layout);
|
2008-03-22 21:11:17 +03:00
|
|
|
|
|
|
|
if (wide)
|
2019-09-08 22:29:00 +03:00
|
|
|
cellwidth *= 2;
|
2008-03-22 21:11:17 +03:00
|
|
|
|
|
|
|
y -= pfont->u.ascent;
|
|
|
|
|
|
|
|
layout = pango_layout_new(gtk_widget_get_pango_context(pfont->widget));
|
|
|
|
pango_layout_set_font_description(layout, pfont->desc);
|
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 22:23:19 +03:00
|
|
|
if (bold && !pfont->bold) {
|
2019-09-08 22:29:00 +03:00
|
|
|
if (pfont->shadowalways)
|
|
|
|
shadowbold = true;
|
|
|
|
else {
|
|
|
|
PangoFontDescription *desc2 =
|
|
|
|
pango_font_description_copy_static(pfont->desc);
|
|
|
|
pango_font_description_set_weight(desc2, PANGO_WEIGHT_BOLD);
|
|
|
|
pango_layout_set_font_description(layout, desc2);
|
|
|
|
}
|
2008-03-22 21:11:17 +03:00
|
|
|
}
|
|
|
|
|
2011-09-16 23:18:53 +04:00
|
|
|
/*
|
|
|
|
* Pango always expects UTF-8, so convert the input wide character
|
|
|
|
* string to UTF-8.
|
|
|
|
*/
|
|
|
|
utfstring = snewn(len*6+1, char); /* UTF-8 has max 6 bytes/char */
|
|
|
|
utflen = wc_to_mb(CS_UTF8, 0, string, len,
|
2018-10-06 13:45:26 +03:00
|
|
|
utfstring, len*6+1, ".", NULL);
|
2011-09-16 23:18:53 +04:00
|
|
|
|
|
|
|
utfptr = utfstring;
|
|
|
|
while (utflen > 0) {
|
2019-09-08 22:29:00 +03:00
|
|
|
int clen, n;
|
2015-08-31 18:37:05 +03:00
|
|
|
int desired = cellwidth * PANGO_SCALE;
|
2008-03-22 21:11:17 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
/*
|
|
|
|
* We want to display every character from this string in
|
|
|
|
* the centre of its own character cell. In the worst case,
|
|
|
|
* this requires a separate text-drawing call for each
|
|
|
|
* character; but in the common case where the font is
|
|
|
|
* properly fixed-width, we can draw many characters in one
|
|
|
|
* go which is much faster.
|
|
|
|
*
|
|
|
|
* This still isn't really ideal. If you look at what
|
|
|
|
* happens in the X protocol as a result of all of this, you
|
|
|
|
* find - naturally enough - that each call to
|
|
|
|
* gdk_draw_layout() generates a separate set of X RENDER
|
|
|
|
* operations involving creating a picture, setting a clip
|
|
|
|
* rectangle, doing some drawing and undoing the whole lot.
|
|
|
|
* In an ideal world, we should _always_ be able to turn the
|
|
|
|
* contents of this loop into a single RenderCompositeGlyphs
|
|
|
|
* operation which internally specifies inter-character
|
|
|
|
* deltas to get the spacing right, which would give us full
|
|
|
|
* speed _even_ in the worst case of a non-fixed-width font.
|
|
|
|
* However, Pango's architecture and documentation are so
|
|
|
|
* unhelpful that I have no idea how if at all to persuade
|
|
|
|
* them to do that.
|
|
|
|
*/
|
2009-05-11 12:46:17 +04:00
|
|
|
|
2015-09-26 12:18:53 +03:00
|
|
|
if (combining) {
|
2011-09-16 23:18:58 +04:00
|
|
|
/*
|
2015-09-26 12:18:53 +03:00
|
|
|
* For a character with combining stuff, we just dump the
|
|
|
|
* whole lot in one go, and expect it to take up just one
|
|
|
|
* character cell.
|
2011-09-16 23:18:58 +04:00
|
|
|
*/
|
2015-09-26 12:18:53 +03:00
|
|
|
clen = utflen;
|
|
|
|
n = 1;
|
2015-08-23 16:13:30 +03:00
|
|
|
} else {
|
|
|
|
/*
|
2015-09-26 12:18:53 +03:00
|
|
|
* Start by extracting a single UTF-8 character from the
|
|
|
|
* string.
|
2015-08-23 16:13:30 +03:00
|
|
|
*/
|
2015-09-26 12:18:53 +03:00
|
|
|
clen = 1;
|
|
|
|
while (clen < utflen &&
|
|
|
|
(unsigned char)utfptr[clen] >= 0x80 &&
|
|
|
|
(unsigned char)utfptr[clen] < 0xC0)
|
|
|
|
clen++;
|
|
|
|
n = 1;
|
|
|
|
|
|
|
|
if (is_rtl(string[0]) ||
|
|
|
|
pangofont_char_width(layout, pfont, string[n-1],
|
|
|
|
utfptr, clen) != desired) {
|
|
|
|
/*
|
|
|
|
* If this character is a right-to-left one, or has an
|
|
|
|
* unusual width, then we must display it on its own.
|
|
|
|
*/
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Try to amalgamate a contiguous string of characters
|
|
|
|
* with the expected sensible width, for the common case
|
|
|
|
* in which we're using a monospaced font and everything
|
|
|
|
* works as expected.
|
|
|
|
*/
|
|
|
|
while (clen < utflen) {
|
|
|
|
int oldclen = clen;
|
2019-09-08 22:29:00 +03:00
|
|
|
clen++; /* skip UTF-8 introducer byte */
|
2015-09-26 12:18:53 +03:00
|
|
|
while (clen < utflen &&
|
|
|
|
(unsigned char)utfptr[clen] >= 0x80 &&
|
|
|
|
(unsigned char)utfptr[clen] < 0xC0)
|
|
|
|
clen++;
|
|
|
|
n++;
|
2016-03-20 23:04:26 +03:00
|
|
|
if (is_rtl(string[n-1]) ||
|
|
|
|
pangofont_char_width(layout, pfont,
|
2015-09-26 12:18:53 +03:00
|
|
|
string[n-1], utfptr + oldclen,
|
|
|
|
clen - oldclen) != desired) {
|
|
|
|
clen = oldclen;
|
|
|
|
n--;
|
|
|
|
break;
|
|
|
|
}
|
2011-09-16 23:18:58 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2009-05-11 12:46:17 +04:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_layout_set_text(layout, utfptr, clen);
|
|
|
|
pango_layout_get_pixel_extents(layout, NULL, &rect);
|
|
|
|
|
|
|
|
draw_layout(ctx,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
x + (n*cellwidth - rect.width)/2,
|
|
|
|
y + (pfont->u.height - rect.height)/2, layout);
|
2019-09-08 22:29:00 +03:00
|
|
|
if (shadowbold)
|
|
|
|
draw_layout(ctx,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
x + (n*cellwidth - rect.width)/2 + pfont->shadowoffset,
|
|
|
|
y + (pfont->u.height - rect.height)/2, layout);
|
2008-03-22 21:11:17 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
utflen -= clen;
|
|
|
|
utfptr += clen;
|
2011-09-16 23:18:58 +04:00
|
|
|
string += n;
|
2019-09-08 22:29:00 +03:00
|
|
|
x += n * cellwidth;
|
2008-03-22 21:11:17 +03:00
|
|
|
}
|
|
|
|
|
2011-09-16 23:18:53 +04:00
|
|
|
sfree(utfstring);
|
|
|
|
|
2008-03-22 21:11:17 +03:00
|
|
|
g_object_unref(layout);
|
|
|
|
}
|
|
|
|
|
2015-09-26 12:18:53 +03:00
|
|
|
static void pangofont_draw_text(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string, int len,
|
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 22:23:19 +03:00
|
|
|
bool wide, bool bold, int cellwidth)
|
2015-09-26 12:18:53 +03:00
|
|
|
{
|
|
|
|
pangofont_draw_internal(ctx, font, x, y, string, len, wide, bold,
|
2018-10-29 22:50:29 +03:00
|
|
|
cellwidth, false);
|
2015-09-26 12:18:53 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void pangofont_draw_combining(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string,
|
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 22:23:19 +03:00
|
|
|
int len, bool wide, bool bold,
|
2015-09-26 12:18:53 +03:00
|
|
|
int cellwidth)
|
|
|
|
{
|
|
|
|
wchar_t *tmpstring = NULL;
|
|
|
|
if (mk_wcwidth(string[0]) == 0) {
|
|
|
|
/*
|
|
|
|
* If we've been told to draw a sequence of _only_ combining
|
|
|
|
* characters, prefix a space so that they have something to
|
|
|
|
* combine with.
|
|
|
|
*/
|
|
|
|
tmpstring = snewn(len+1, wchar_t);
|
|
|
|
memcpy(tmpstring+1, string, len * sizeof(wchar_t));
|
|
|
|
tmpstring[0] = L' ';
|
|
|
|
string = tmpstring;
|
|
|
|
len++;
|
|
|
|
}
|
|
|
|
pangofont_draw_internal(ctx, font, x, y, string, len, wide, bold,
|
2018-10-29 22:50:29 +03:00
|
|
|
cellwidth, true);
|
2015-09-26 12:18:53 +03:00
|
|
|
sfree(tmpstring);
|
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
/*
|
|
|
|
* Dummy size value to be used when converting a
|
|
|
|
* PangoFontDescription of a scalable font to a string for
|
|
|
|
* internal use.
|
|
|
|
*/
|
|
|
|
#define PANGO_DUMMY_SIZE 12
|
|
|
|
|
|
|
|
static void pangofont_enum_fonts(GtkWidget *widget, fontsel_add_entry callback,
|
2019-09-08 22:29:00 +03:00
|
|
|
void *callback_ctx)
|
2008-03-26 00:49:14 +03:00
|
|
|
{
|
|
|
|
PangoContext *ctx;
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT6
|
2008-03-26 00:49:14 +03:00
|
|
|
PangoFontMap *map;
|
2008-03-26 21:30:20 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
PangoFontFamily **families;
|
|
|
|
int i, nfamilies;
|
|
|
|
|
|
|
|
ctx = gtk_widget_get_pango_context(widget);
|
|
|
|
if (!ctx)
|
2019-09-08 22:29:00 +03:00
|
|
|
return;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
2008-03-26 21:30:20 +03:00
|
|
|
* Ask Pango for a list of font families, and iterate through
|
|
|
|
* them.
|
2008-03-26 00:49:14 +03:00
|
|
|
*/
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT6
|
|
|
|
map = pango_context_get_font_map(ctx);
|
|
|
|
if (!map)
|
2019-09-08 22:29:00 +03:00
|
|
|
return;
|
2008-03-26 00:49:14 +03:00
|
|
|
pango_font_map_list_families(map, &families, &nfamilies);
|
2008-03-26 21:30:20 +03:00
|
|
|
#else
|
|
|
|
pango_context_list_families(ctx, &families, &nfamilies);
|
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
for (i = 0; i < nfamilies; i++) {
|
2019-09-08 22:29:00 +03:00
|
|
|
PangoFontFamily *family = families[i];
|
|
|
|
const char *familyname;
|
|
|
|
int flags;
|
|
|
|
PangoFontFace **faces;
|
|
|
|
int j, nfaces;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set up our flags for this font family, and get the name
|
|
|
|
* string.
|
|
|
|
*/
|
|
|
|
flags = FONTFLAG_CLIENTSIDE;
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT4
|
|
|
|
/*
|
|
|
|
* In very early versions of Pango, we can't tell
|
|
|
|
* monospaced fonts from non-monospaced.
|
|
|
|
*/
|
2019-09-08 22:29:00 +03:00
|
|
|
if (!pango_font_family_is_monospace(family))
|
|
|
|
flags |= FONTFLAG_NONMONOSPACED;
|
2008-03-26 21:30:20 +03:00
|
|
|
#endif
|
2019-09-08 22:29:00 +03:00
|
|
|
familyname = pango_font_family_get_name(family);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Go through the available font faces in this family.
|
|
|
|
*/
|
|
|
|
pango_font_family_list_faces(family, &faces, &nfaces);
|
|
|
|
for (j = 0; j < nfaces; j++) {
|
|
|
|
PangoFontFace *face = faces[j];
|
|
|
|
PangoFontDescription *desc;
|
|
|
|
const char *facename;
|
|
|
|
int *sizes;
|
|
|
|
int k, nsizes, dummysize;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Get the face name string.
|
|
|
|
*/
|
|
|
|
facename = pango_font_face_get_face_name(face);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set up a font description with what we've got so
|
|
|
|
* far. We'll fill in the size field manually and then
|
|
|
|
* call pango_font_description_to_string() to give the
|
|
|
|
* full real name of the specific font.
|
|
|
|
*/
|
|
|
|
desc = pango_font_face_describe(face);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* See if this font has a list of specific sizes.
|
|
|
|
*/
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT4
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_font_face_list_sizes(face, &sizes, &nsizes);
|
2008-03-26 21:30:20 +03:00
|
|
|
#else
|
|
|
|
/*
|
|
|
|
* In early versions of Pango, that call wasn't
|
|
|
|
* supported; we just have to assume everything is
|
|
|
|
* scalable.
|
|
|
|
*/
|
|
|
|
sizes = NULL;
|
|
|
|
#endif
|
2019-09-08 22:29:00 +03:00
|
|
|
if (!sizes) {
|
|
|
|
/*
|
|
|
|
* Write a single entry with a dummy size.
|
|
|
|
*/
|
|
|
|
dummysize = PANGO_DUMMY_SIZE * PANGO_SCALE;
|
|
|
|
sizes = &dummysize;
|
|
|
|
nsizes = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If so, go through them one by one.
|
|
|
|
*/
|
|
|
|
for (k = 0; k < nsizes; k++) {
|
|
|
|
char *fullname, *stylekey;
|
|
|
|
|
|
|
|
pango_font_description_set_size(desc, sizes[k]);
|
|
|
|
|
|
|
|
fullname = pango_font_description_to_string(desc);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Construct the sorting key for font styles.
|
|
|
|
*/
|
|
|
|
{
|
2018-12-01 12:35:52 +03:00
|
|
|
strbuf *buf = strbuf_new();
|
2008-03-26 23:20:25 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
int weight = pango_font_description_get_weight(desc);
|
|
|
|
/* Weight: normal, then lighter, then bolder */
|
|
|
|
if (weight <= PANGO_WEIGHT_NORMAL)
|
|
|
|
weight = PANGO_WEIGHT_NORMAL - weight;
|
|
|
|
strbuf_catf(buf, "%4d", weight);
|
2008-03-26 23:20:25 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
strbuf_catf(buf, " %2d",
|
2018-12-01 12:35:52 +03:00
|
|
|
pango_font_description_get_style(desc));
|
2008-03-26 23:20:25 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
int stretch = pango_font_description_get_stretch(desc);
|
|
|
|
/* Stretch: closer to normal sorts earlier */
|
|
|
|
stretch = 2 * abs(PANGO_STRETCH_NORMAL - stretch) +
|
|
|
|
(stretch < PANGO_STRETCH_NORMAL);
|
|
|
|
strbuf_catf(buf, " %2d", stretch);
|
2008-03-26 23:20:25 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
strbuf_catf(buf, " %2d",
|
2018-12-01 12:35:52 +03:00
|
|
|
pango_font_description_get_variant(desc));
|
|
|
|
|
|
|
|
stylekey = strbuf_to_str(buf);
|
2019-09-08 22:29:00 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Got everything. Hand off to the callback.
|
|
|
|
* (The charset string is NULL, because only
|
|
|
|
* server-side X fonts use it.)
|
|
|
|
*/
|
|
|
|
callback(callback_ctx, fullname, familyname, NULL, facename,
|
|
|
|
stylekey,
|
|
|
|
(sizes == &dummysize ? 0 : PANGO_PIXELS(sizes[k])),
|
|
|
|
flags, &pangofont_vtable);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2018-12-01 12:35:52 +03:00
|
|
|
sfree(stylekey);
|
2019-09-08 22:29:00 +03:00
|
|
|
g_free(fullname);
|
|
|
|
}
|
|
|
|
if (sizes != &dummysize)
|
|
|
|
g_free(sizes);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_font_description_free(desc);
|
|
|
|
}
|
|
|
|
g_free(faces);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
g_free(families);
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *pangofont_canonify_fontname(GtkWidget *widget, const char *name,
|
2019-09-08 22:29:00 +03:00
|
|
|
int *size, int *flags,
|
|
|
|
bool resolve_aliases)
|
2008-03-26 00:49:14 +03:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* When given a Pango font name to try to make sense of for a
|
|
|
|
* font selector, we must normalise it to PANGO_DUMMY_SIZE and
|
|
|
|
* extract its original size (in pixels) into the `size' field.
|
|
|
|
*/
|
|
|
|
PangoContext *ctx;
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT6
|
2008-03-26 00:49:14 +03:00
|
|
|
PangoFontMap *map;
|
2008-03-26 21:30:20 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
PangoFontDescription *desc;
|
|
|
|
PangoFontset *fset;
|
|
|
|
PangoFontMetrics *metrics;
|
|
|
|
char *newname, *retname;
|
|
|
|
|
|
|
|
desc = pango_font_description_from_string(name);
|
|
|
|
if (!desc)
|
2019-09-08 22:29:00 +03:00
|
|
|
return NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
ctx = gtk_widget_get_pango_context(widget);
|
|
|
|
if (!ctx) {
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
2008-03-29 18:44:32 +03:00
|
|
|
if (!pangofont_check_desc_makes_sense(ctx, desc)) {
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
2008-03-29 18:44:32 +03:00
|
|
|
}
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT6
|
2008-03-26 00:49:14 +03:00
|
|
|
map = pango_context_get_font_map(ctx);
|
|
|
|
if (!map) {
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
fset = pango_font_map_load_fontset(map, ctx, desc,
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_context_get_language(ctx));
|
2008-03-26 21:30:20 +03:00
|
|
|
#else
|
|
|
|
fset = pango_context_load_fontset(ctx, desc,
|
|
|
|
pango_context_get_language(ctx));
|
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
if (!fset) {
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
metrics = pango_fontset_get_metrics(fset);
|
|
|
|
if (!metrics ||
|
2019-09-08 22:29:00 +03:00
|
|
|
pango_font_metrics_get_approximate_digit_width(metrics) == 0) {
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
g_object_unref(fset);
|
|
|
|
return NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
*size = PANGO_PIXELS(pango_font_description_get_size(desc));
|
2008-04-13 11:48:10 +04:00
|
|
|
*flags = FONTFLAG_CLIENTSIDE;
|
2008-03-26 00:49:14 +03:00
|
|
|
pango_font_description_set_size(desc, PANGO_DUMMY_SIZE * PANGO_SCALE);
|
|
|
|
newname = pango_font_description_to_string(desc);
|
|
|
|
retname = dupstr(newname);
|
|
|
|
g_free(newname);
|
|
|
|
|
|
|
|
pango_font_metrics_unref(metrics);
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
g_object_unref(fset);
|
|
|
|
|
|
|
|
return retname;
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *pangofont_scale_fontname(GtkWidget *widget, const char *name,
|
2019-09-08 22:29:00 +03:00
|
|
|
int size)
|
2008-03-26 00:49:14 +03:00
|
|
|
{
|
|
|
|
PangoFontDescription *desc;
|
|
|
|
char *newname, *retname;
|
|
|
|
|
|
|
|
desc = pango_font_description_from_string(name);
|
|
|
|
if (!desc)
|
2019-09-08 22:29:00 +03:00
|
|
|
return NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
pango_font_description_set_size(desc, size * PANGO_SCALE);
|
|
|
|
newname = pango_font_description_to_string(desc);
|
|
|
|
retname = dupstr(newname);
|
|
|
|
g_free(newname);
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
|
|
|
|
return retname;
|
|
|
|
}
|
|
|
|
|
2016-11-13 16:53:42 +03:00
|
|
|
static char *pangofont_size_increment(unifont *font, int increment)
|
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
struct pangofont *pfont = container_of(font, struct pangofont, u);
|
2016-11-13 16:53:42 +03:00
|
|
|
PangoFontDescription *desc;
|
|
|
|
int size;
|
|
|
|
char *newname, *retname;
|
|
|
|
|
|
|
|
desc = pango_font_description_copy_static(pfont->desc);
|
|
|
|
|
|
|
|
size = pango_font_description_get_size(desc);
|
|
|
|
size += PANGO_SCALE * increment;
|
|
|
|
|
|
|
|
if (size <= 0) {
|
|
|
|
retname = NULL;
|
|
|
|
} else {
|
|
|
|
pango_font_description_set_size(desc, size);
|
|
|
|
newname = pango_font_description_to_string(desc);
|
Make dupcat() into a variadic macro.
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.
2019-10-14 21:42:37 +03:00
|
|
|
retname = dupcat(pfont->u.vt->prefix, ":", newname);
|
2016-11-13 16:53:42 +03:00
|
|
|
g_free(newname);
|
|
|
|
}
|
|
|
|
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
return retname;
|
|
|
|
}
|
|
|
|
|
2008-04-04 14:56:26 +04:00
|
|
|
#endif /* GTK_CHECK_VERSION(2,0,0) */
|
|
|
|
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
/* ----------------------------------------------------------------------
|
|
|
|
* Outermost functions which do the vtable dispatch.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2008-03-26 00:49:14 +03:00
|
|
|
* Complete list of font-type subclasses. Listed in preference
|
|
|
|
* order for unifont_create(). (That is, in the extremely unlikely
|
|
|
|
* event that the same font name is valid as both a Pango and an
|
|
|
|
* X11 font, it will be interpreted as the former in the absence
|
|
|
|
* of an explicit type-disambiguating prefix.)
|
2011-09-16 23:18:54 +04:00
|
|
|
*
|
|
|
|
* The 'multifont' subclass is omitted here, as discussed above.
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
*/
|
2018-10-05 09:03:46 +03:00
|
|
|
static const struct UnifontVtable *unifont_types[] = {
|
2008-04-04 14:56:26 +04:00
|
|
|
#if GTK_CHECK_VERSION(2,0,0)
|
2008-03-22 21:11:17 +03:00
|
|
|
&pangofont_vtable,
|
2008-04-04 14:56:26 +04:00
|
|
|
#endif
|
2015-08-08 18:35:19 +03:00
|
|
|
#ifndef NOT_X_WINDOWS
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
&x11font_vtable,
|
2015-08-08 18:35:19 +03:00
|
|
|
#endif
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
};
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Function which takes a font name and processes the optional
|
|
|
|
* scheme prefix. Returns the tail of the font name suitable for
|
|
|
|
* passing to individual font scheme functions, and also provides
|
|
|
|
* a subrange of the unifont_types[] array above.
|
2019-09-08 22:29:00 +03:00
|
|
|
*
|
2008-03-26 00:49:14 +03:00
|
|
|
* The return values `start' and `end' denote a half-open interval
|
|
|
|
* in unifont_types[]; that is, the correct way to iterate over
|
|
|
|
* them is
|
2019-09-08 22:29:00 +03:00
|
|
|
*
|
2008-03-26 00:49:14 +03:00
|
|
|
* for (i = start; i < end; i++) {...}
|
|
|
|
*/
|
|
|
|
static const char *unifont_do_prefix(const char *name, int *start, int *end)
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
{
|
|
|
|
int colonpos = strcspn(name, ":");
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (name[colonpos]) {
|
2019-09-08 22:29:00 +03:00
|
|
|
/*
|
|
|
|
* There's a colon prefix on the font name. Use it to work
|
|
|
|
* out which subclass to use.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < lenof(unifont_types); i++) {
|
|
|
|
if (strlen(unifont_types[i]->prefix) == colonpos &&
|
|
|
|
!strncmp(unifont_types[i]->prefix, name, colonpos)) {
|
|
|
|
*start = i;
|
|
|
|
*end = i+1;
|
|
|
|
return name + colonpos + 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* None matched, so return an empty scheme list to prevent
|
|
|
|
* any scheme from being called at all.
|
|
|
|
*/
|
|
|
|
*start = *end = 0;
|
|
|
|
return name + colonpos + 1;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
} else {
|
2019-09-08 22:29:00 +03:00
|
|
|
/*
|
|
|
|
* No colon prefix, so just use all the subclasses.
|
|
|
|
*/
|
|
|
|
*start = 0;
|
|
|
|
*end = lenof(unifont_types);
|
|
|
|
return name;
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03: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 22:23:19 +03:00
|
|
|
unifont *unifont_create(GtkWidget *widget, const char *name, bool wide,
|
2019-09-08 22:29:00 +03:00
|
|
|
bool bold, int shadowoffset, bool shadowalways)
|
2008-03-26 00:49:14 +03:00
|
|
|
{
|
|
|
|
int i, start, end;
|
|
|
|
|
|
|
|
name = unifont_do_prefix(name, &start, &end);
|
|
|
|
|
|
|
|
for (i = start; i < end; i++) {
|
2019-09-08 22:29:00 +03:00
|
|
|
unifont *ret = unifont_types[i]->create(widget, name, wide, bold,
|
|
|
|
shadowoffset, shadowalways);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
2019-09-08 22:29:00 +03:00
|
|
|
return NULL; /* font not found in any scheme */
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
void unifont_destroy(unifont *font)
|
|
|
|
{
|
|
|
|
font->vt->destroy(font);
|
|
|
|
}
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
void unifont_draw_text(unifont_drawctx *ctx, unifont *font,
|
2019-09-08 22:29:00 +03:00
|
|
|
int x, int y, const wchar_t *string, int len,
|
|
|
|
bool wide, bool bold, int cellwidth)
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
{
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
font->vt->draw_text(ctx, font, x, y, string, len, wide, bold, cellwidth);
|
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2015-09-26 12:18:53 +03:00
|
|
|
void unifont_draw_combining(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string, int len,
|
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 22:23:19 +03:00
|
|
|
bool wide, bool bold, int cellwidth)
|
2015-09-26 12:18:53 +03:00
|
|
|
{
|
|
|
|
font->vt->draw_combining(ctx, font, x, y, string, len, wide, bold,
|
|
|
|
cellwidth);
|
|
|
|
}
|
|
|
|
|
2016-11-13 16:53:42 +03:00
|
|
|
char *unifont_size_increment(unifont *font, int increment)
|
|
|
|
{
|
|
|
|
return font->vt->size_increment(font, increment);
|
|
|
|
}
|
|
|
|
|
2011-09-16 23:18:54 +04:00
|
|
|
/* ----------------------------------------------------------------------
|
|
|
|
* Multiple-font wrapper. This is a type of unifont which encapsulates
|
|
|
|
* up to two other unifonts, permitting missing glyphs in the main
|
|
|
|
* font to be filled in by a fallback font.
|
|
|
|
*
|
|
|
|
* This is a type of unifont just like the previous two, but it has a
|
|
|
|
* separate constructor which is manually called by the client, so it
|
|
|
|
* doesn't appear in the list of available font types enumerated by
|
|
|
|
* unifont_create. This means it's not used by unifontsel either, so
|
|
|
|
* it doesn't need to support any methods except draw_text and
|
|
|
|
* destroy.
|
|
|
|
*/
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static void multifont_draw_text(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string, int len,
|
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 22:23:19 +03:00
|
|
|
bool wide, bool bold, int cellwidth);
|
2015-09-26 12:18:53 +03:00
|
|
|
static void multifont_draw_combining(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string,
|
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 22:23:19 +03:00
|
|
|
int len, bool wide, bool bold,
|
2015-09-26 12:18:53 +03:00
|
|
|
int cellwidth);
|
2011-09-16 23:18:54 +04:00
|
|
|
static void multifont_destroy(unifont *font);
|
2016-11-13 16:53:42 +03:00
|
|
|
static char *multifont_size_increment(unifont *font, int increment);
|
2011-09-16 23:18:54 +04:00
|
|
|
|
|
|
|
struct multifont {
|
|
|
|
unifont *main;
|
|
|
|
unifont *fallback;
|
2018-10-05 09:02:19 +03:00
|
|
|
|
|
|
|
struct unifont u;
|
2011-09-16 23:18:54 +04:00
|
|
|
};
|
|
|
|
|
Change vtable defs to use C99 designated initialisers.
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.
2020-03-11 00:06:29 +03:00
|
|
|
static const UnifontVtable multifont_vtable = {
|
|
|
|
.create = NULL, /* creation is done specially */
|
|
|
|
.create_fallback = NULL,
|
|
|
|
.destroy = multifont_destroy,
|
|
|
|
.has_glyph = NULL,
|
|
|
|
.draw_text = multifont_draw_text,
|
|
|
|
.draw_combining = multifont_draw_combining,
|
|
|
|
.enum_fonts = NULL,
|
|
|
|
.canonify_fontname = NULL,
|
|
|
|
.scale_fontname = NULL,
|
|
|
|
.size_increment = multifont_size_increment,
|
|
|
|
.prefix = "client",
|
2011-09-16 23:18:54 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
unifont *multifont_create(GtkWidget *widget, const char *name,
|
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 22:23:19 +03:00
|
|
|
bool wide, bool bold,
|
|
|
|
int shadowoffset, bool shadowalways)
|
2011-09-16 23:18:54 +04:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
unifont *font, *fallback;
|
|
|
|
struct multifont *mfont;
|
|
|
|
|
|
|
|
font = unifont_create(widget, name, wide, bold,
|
|
|
|
shadowoffset, shadowalways);
|
|
|
|
if (!font)
|
|
|
|
return NULL;
|
|
|
|
|
2011-09-19 20:21:25 +04:00
|
|
|
fallback = NULL;
|
2011-09-16 23:18:54 +04:00
|
|
|
if (font->want_fallback) {
|
2019-09-08 22:29:00 +03:00
|
|
|
for (i = 0; i < lenof(unifont_types); i++) {
|
2011-09-16 23:18:54 +04:00
|
|
|
if (unifont_types[i]->create_fallback) {
|
|
|
|
fallback = unifont_types[i]->create_fallback
|
|
|
|
(widget, font->height, wide, bold,
|
|
|
|
shadowoffset, shadowalways);
|
|
|
|
if (fallback)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Construct our multifont. Public members are all copied from the
|
|
|
|
* primary font we're wrapping.
|
|
|
|
*/
|
|
|
|
mfont = snew(struct multifont);
|
|
|
|
mfont->u.vt = &multifont_vtable;
|
|
|
|
mfont->u.width = font->width;
|
|
|
|
mfont->u.ascent = font->ascent;
|
|
|
|
mfont->u.descent = font->descent;
|
|
|
|
mfont->u.height = font->height;
|
2020-08-13 23:08:53 +03:00
|
|
|
mfont->u.strikethrough_y = font->strikethrough_y;
|
2011-09-16 23:18:54 +04:00
|
|
|
mfont->u.public_charset = font->public_charset;
|
2018-10-29 22:50:29 +03:00
|
|
|
mfont->u.want_fallback = false; /* shouldn't be needed, but just in case */
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
mfont->u.preferred_drawtype = font->preferred_drawtype;
|
2011-09-16 23:18:54 +04:00
|
|
|
mfont->main = font;
|
|
|
|
mfont->fallback = fallback;
|
|
|
|
|
2018-10-05 09:02:19 +03:00
|
|
|
return &mfont->u;
|
2011-09-16 23:18:54 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static void multifont_destroy(unifont *font)
|
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
struct multifont *mfont = container_of(font, struct multifont, u);
|
2011-09-16 23:18:54 +04:00
|
|
|
unifont_destroy(mfont->main);
|
|
|
|
if (mfont->fallback)
|
|
|
|
unifont_destroy(mfont->fallback);
|
2018-10-05 09:02:19 +03:00
|
|
|
sfree(mfont);
|
2011-09-16 23:18:54 +04:00
|
|
|
}
|
|
|
|
|
2015-09-26 12:18:53 +03:00
|
|
|
typedef void (*unifont_draw_func_t)(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string,
|
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 22:23:19 +03:00
|
|
|
int len, bool wide, bool bold,
|
2015-09-26 12:18:53 +03:00
|
|
|
int cellwidth);
|
|
|
|
|
|
|
|
static void multifont_draw_main(unifont_drawctx *ctx, unifont *font, int x,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
int y, const wchar_t *string, int len,
|
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 22:23:19 +03:00
|
|
|
bool wide, bool bold, int cellwidth,
|
2015-09-26 12:18:53 +03:00
|
|
|
int cellinc, unifont_draw_func_t draw)
|
2011-09-16 23:18:54 +04:00
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
struct multifont *mfont = container_of(font, struct multifont, u);
|
2015-08-15 22:26:07 +03:00
|
|
|
unifont *f;
|
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 22:23:19 +03:00
|
|
|
bool ok;
|
|
|
|
int i;
|
2011-09-16 23:18:54 +04:00
|
|
|
|
|
|
|
while (len > 0) {
|
|
|
|
/*
|
|
|
|
* Find a maximal sequence of characters which are, or are
|
|
|
|
* not, supported by our main font.
|
|
|
|
*/
|
|
|
|
ok = mfont->main->vt->has_glyph(mfont->main, string[0]);
|
|
|
|
for (i = 1;
|
|
|
|
i < len &&
|
|
|
|
!mfont->main->vt->has_glyph(mfont->main, string[i]) == !ok;
|
|
|
|
i++);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now display it.
|
|
|
|
*/
|
2015-08-15 22:26:07 +03:00
|
|
|
f = ok ? mfont->main : mfont->fallback;
|
|
|
|
if (f)
|
2015-09-26 12:18:53 +03:00
|
|
|
draw(ctx, f, x, y, string, i, wide, bold, cellwidth);
|
2011-09-16 23:18:54 +04:00
|
|
|
string += i;
|
|
|
|
len -= i;
|
2015-09-26 12:18:53 +03:00
|
|
|
x += i * cellinc;
|
2011-09-16 23:18:54 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-26 12:18:53 +03:00
|
|
|
static void multifont_draw_text(unifont_drawctx *ctx, unifont *font, int x,
|
|
|
|
int y, const wchar_t *string, int len,
|
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 22:23:19 +03:00
|
|
|
bool wide, bool bold, int cellwidth)
|
2015-09-26 12:18:53 +03:00
|
|
|
{
|
|
|
|
multifont_draw_main(ctx, font, x, y, string, len, wide, bold,
|
|
|
|
cellwidth, cellwidth, unifont_draw_text);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void multifont_draw_combining(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string,
|
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 22:23:19 +03:00
|
|
|
int len, bool wide, bool bold,
|
2015-09-26 12:18:53 +03:00
|
|
|
int cellwidth)
|
|
|
|
{
|
|
|
|
multifont_draw_main(ctx, font, x, y, string, len, wide, bold,
|
|
|
|
cellwidth, 0, unifont_draw_combining);
|
|
|
|
}
|
|
|
|
|
2016-11-13 16:53:42 +03:00
|
|
|
static char *multifont_size_increment(unifont *font, int increment)
|
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
struct multifont *mfont = container_of(font, struct multifont, u);
|
2016-11-13 16:53:42 +03:00
|
|
|
return unifont_size_increment(mfont->main, increment);
|
|
|
|
}
|
|
|
|
|
2008-04-04 14:56:26 +04:00
|
|
|
#if GTK_CHECK_VERSION(2,0,0)
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
/* ----------------------------------------------------------------------
|
2008-04-04 14:56:26 +04:00
|
|
|
* Implementation of a unified font selector. Used on GTK 2 only;
|
|
|
|
* for GTK 1 we still use the standard font selector.
|
2008-03-26 00:49:14 +03:00
|
|
|
*/
|
|
|
|
|
|
|
|
typedef struct fontinfo fontinfo;
|
|
|
|
|
|
|
|
typedef struct unifontsel_internal {
|
|
|
|
GtkListStore *family_model, *style_model, *size_model;
|
|
|
|
GtkWidget *family_list, *style_list, *size_entry, *size_list;
|
|
|
|
GtkWidget *filter_buttons[4];
|
2015-08-08 18:35:19 +03:00
|
|
|
int n_filter_buttons;
|
2008-03-27 22:41:08 +03:00
|
|
|
GtkWidget *preview_area;
|
2015-08-16 11:02:31 +03:00
|
|
|
#ifndef NO_BACKING_PIXMAPS
|
2008-03-27 22:41:08 +03:00
|
|
|
GdkPixmap *preview_pixmap;
|
2015-08-16 11:02:31 +03:00
|
|
|
#endif
|
2008-03-27 22:41:08 +03:00
|
|
|
int preview_width, preview_height;
|
|
|
|
GdkColor preview_fg, preview_bg;
|
2008-03-26 00:49:14 +03:00
|
|
|
int filter_flags;
|
|
|
|
tree234 *fonts_by_realname, *fonts_by_selorder;
|
|
|
|
fontinfo *selected;
|
2008-03-29 13:16:48 +03:00
|
|
|
int selsize, intendedsize;
|
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 22:23:19 +03:00
|
|
|
bool inhibit_response; /* inhibit callbacks when we change GUI controls */
|
2018-10-05 09:02:19 +03:00
|
|
|
|
|
|
|
unifontsel u;
|
2008-03-26 00:49:14 +03:00
|
|
|
} unifontsel_internal;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The structure held in the tree234s. All the string members are
|
|
|
|
* part of the same allocated area, so don't need freeing
|
|
|
|
* separately.
|
|
|
|
*/
|
|
|
|
struct fontinfo {
|
|
|
|
char *realname;
|
2008-03-26 23:20:25 +03:00
|
|
|
char *family, *charset, *style, *stylekey;
|
2008-03-26 00:49:14 +03:00
|
|
|
int size, flags;
|
|
|
|
/*
|
|
|
|
* Fallback sorting key, to permit multiple identical entries
|
|
|
|
* to exist in the selorder tree.
|
|
|
|
*/
|
|
|
|
int index;
|
|
|
|
/*
|
|
|
|
* Indices mapping fontinfo structures to indices in the list
|
|
|
|
* boxes. sizeindex is irrelevant if the font is scalable
|
|
|
|
* (size==0).
|
|
|
|
*/
|
|
|
|
int familyindex, styleindex, sizeindex;
|
|
|
|
/*
|
|
|
|
* The class of font.
|
|
|
|
*/
|
2018-10-05 09:03:46 +03:00
|
|
|
const struct UnifontVtable *fontclass;
|
2008-03-26 00:49:14 +03:00
|
|
|
};
|
|
|
|
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
struct fontinfo_realname_find {
|
|
|
|
const char *realname;
|
|
|
|
int flags;
|
|
|
|
};
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
static int strnullcasecmp(const char *a, const char *b)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If exactly one of the inputs is NULL, it compares before
|
|
|
|
* the other one.
|
|
|
|
*/
|
|
|
|
if ((i = (!b) - (!a)) != 0)
|
2019-09-08 22:29:00 +03:00
|
|
|
return i;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* NULL compares equal.
|
|
|
|
*/
|
|
|
|
if (!a)
|
2019-09-08 22:29:00 +03:00
|
|
|
return 0;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Otherwise, ordinary strcasecmp.
|
|
|
|
*/
|
2012-01-03 23:43:19 +04:00
|
|
|
return g_ascii_strcasecmp(a, b);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
static int fontinfo_realname_compare(void *av, void *bv)
|
|
|
|
{
|
|
|
|
fontinfo *a = (fontinfo *)av;
|
|
|
|
fontinfo *b = (fontinfo *)bv;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if ((i = strnullcasecmp(a->realname, b->realname)) != 0)
|
2019-09-08 22:29:00 +03:00
|
|
|
return i;
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
if ((a->flags & FONTFLAG_SORT_MASK) != (b->flags & FONTFLAG_SORT_MASK))
|
2019-09-08 22:29:00 +03:00
|
|
|
return ((a->flags & FONTFLAG_SORT_MASK) <
|
|
|
|
(b->flags & FONTFLAG_SORT_MASK) ? -1 : +1);
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int fontinfo_realname_find(void *av, void *bv)
|
|
|
|
{
|
|
|
|
struct fontinfo_realname_find *a = (struct fontinfo_realname_find *)av;
|
|
|
|
fontinfo *b = (fontinfo *)bv;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if ((i = strnullcasecmp(a->realname, b->realname)) != 0)
|
2019-09-08 22:29:00 +03:00
|
|
|
return i;
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
if ((a->flags & FONTFLAG_SORT_MASK) != (b->flags & FONTFLAG_SORT_MASK))
|
2019-09-08 22:29:00 +03:00
|
|
|
return ((a->flags & FONTFLAG_SORT_MASK) <
|
|
|
|
(b->flags & FONTFLAG_SORT_MASK) ? -1 : +1);
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
static int fontinfo_selorder_compare(void *av, void *bv)
|
|
|
|
{
|
|
|
|
fontinfo *a = (fontinfo *)av;
|
|
|
|
fontinfo *b = (fontinfo *)bv;
|
|
|
|
int i;
|
|
|
|
if ((i = strnullcasecmp(a->family, b->family)) != 0)
|
2019-09-08 22:29:00 +03:00
|
|
|
return i;
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
/*
|
|
|
|
* Font class comes immediately after family, so that fonts
|
|
|
|
* from different classes with the same family
|
|
|
|
*/
|
|
|
|
if ((a->flags & FONTFLAG_SORT_MASK) != (b->flags & FONTFLAG_SORT_MASK))
|
2019-09-08 22:29:00 +03:00
|
|
|
return ((a->flags & FONTFLAG_SORT_MASK) <
|
|
|
|
(b->flags & FONTFLAG_SORT_MASK) ? -1 : +1);
|
2008-03-26 00:49:14 +03:00
|
|
|
if ((i = strnullcasecmp(a->charset, b->charset)) != 0)
|
2019-09-08 22:29:00 +03:00
|
|
|
return i;
|
2008-03-26 23:20:25 +03:00
|
|
|
if ((i = strnullcasecmp(a->stylekey, b->stylekey)) != 0)
|
2019-09-08 22:29:00 +03:00
|
|
|
return i;
|
2008-03-26 00:49:14 +03:00
|
|
|
if ((i = strnullcasecmp(a->style, b->style)) != 0)
|
2019-09-08 22:29:00 +03:00
|
|
|
return i;
|
2008-03-26 00:49:14 +03:00
|
|
|
if (a->size != b->size)
|
2019-09-08 22:29:00 +03:00
|
|
|
return (a->size < b->size ? -1 : +1);
|
2008-03-26 00:49:14 +03:00
|
|
|
if (a->index != b->index)
|
2019-09-08 22:29:00 +03:00
|
|
|
return (a->index < b->index ? -1 : +1);
|
2008-03-26 00:49:14 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-08-22 15:41:15 +03:00
|
|
|
static void unifontsel_draw_preview_text(unifontsel_internal *fs);
|
|
|
|
|
2008-04-14 21:57:45 +04:00
|
|
|
static void unifontsel_deselect(unifontsel_internal *fs)
|
|
|
|
{
|
|
|
|
fs->selected = NULL;
|
|
|
|
gtk_list_store_clear(fs->style_model);
|
|
|
|
gtk_list_store_clear(fs->size_model);
|
2018-10-29 22:50:29 +03:00
|
|
|
gtk_widget_set_sensitive(fs->u.ok_button, false);
|
|
|
|
gtk_widget_set_sensitive(fs->size_entry, false);
|
2015-08-22 15:41:15 +03:00
|
|
|
unifontsel_draw_preview_text(fs);
|
2008-04-14 21:57:45 +04:00
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
static void unifontsel_setup_familylist(unifontsel_internal *fs)
|
|
|
|
{
|
|
|
|
GtkTreeIter iter;
|
|
|
|
int i, listindex, minpos = -1, maxpos = -1;
|
|
|
|
char *currfamily = NULL;
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
int currflags = -1;
|
2008-03-26 00:49:14 +03:00
|
|
|
fontinfo *info;
|
|
|
|
|
2018-10-29 22:50:29 +03:00
|
|
|
fs->inhibit_response = true;
|
2015-08-22 15:41:11 +03:00
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_list_store_clear(fs->family_model);
|
|
|
|
listindex = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Search through the font tree for anything matching our
|
|
|
|
* current filter criteria. When we find one, add its font
|
|
|
|
* name to the list box.
|
|
|
|
*/
|
|
|
|
for (i = 0 ;; i++) {
|
2019-09-08 22:29:00 +03:00
|
|
|
info = (fontinfo *)index234(fs->fonts_by_selorder, i);
|
|
|
|
/*
|
|
|
|
* info may be NULL if we've just run off the end of the
|
|
|
|
* tree. We must still do a processing pass in that
|
|
|
|
* situation, in case we had an unfinished font record in
|
|
|
|
* progress.
|
|
|
|
*/
|
|
|
|
if (info && (info->flags &~ fs->filter_flags)) {
|
|
|
|
info->familyindex = -1;
|
|
|
|
continue; /* we're filtering out this font */
|
|
|
|
}
|
|
|
|
if (!info || strnullcasecmp(currfamily, info->family) ||
|
|
|
|
currflags != (info->flags & FONTFLAG_SORT_MASK)) {
|
|
|
|
/*
|
|
|
|
* We've either finished a family, or started a new
|
|
|
|
* one, or both.
|
|
|
|
*/
|
|
|
|
if (currfamily) {
|
|
|
|
gtk_list_store_append(fs->family_model, &iter);
|
|
|
|
gtk_list_store_set(fs->family_model, &iter,
|
|
|
|
0, currfamily, 1, minpos, 2, maxpos+1, -1);
|
|
|
|
listindex++;
|
|
|
|
}
|
|
|
|
if (info) {
|
|
|
|
minpos = i;
|
|
|
|
currfamily = info->family;
|
|
|
|
currflags = info->flags & FONTFLAG_SORT_MASK;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!info)
|
|
|
|
break; /* now we're done */
|
|
|
|
info->familyindex = listindex;
|
|
|
|
maxpos = i;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
2008-04-14 21:57:45 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we've just filtered out the previously selected font,
|
|
|
|
* deselect it thoroughly.
|
|
|
|
*/
|
|
|
|
if (fs->selected && fs->selected->familyindex < 0)
|
2019-09-08 22:29:00 +03:00
|
|
|
unifontsel_deselect(fs);
|
2015-08-22 15:41:11 +03:00
|
|
|
|
2018-10-29 22:50:29 +03:00
|
|
|
fs->inhibit_response = false;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void unifontsel_setup_stylelist(unifontsel_internal *fs,
|
2019-09-08 22:29:00 +03:00
|
|
|
int start, int end)
|
2008-03-26 00:49:14 +03:00
|
|
|
{
|
|
|
|
GtkTreeIter iter;
|
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 22:23:19 +03:00
|
|
|
int i, listindex, minpos = -1, maxpos = -1;
|
|
|
|
bool started = false;
|
2008-03-26 00:49:14 +03:00
|
|
|
char *currcs = NULL, *currstyle = NULL;
|
|
|
|
fontinfo *info;
|
|
|
|
|
|
|
|
gtk_list_store_clear(fs->style_model);
|
|
|
|
listindex = 0;
|
2018-10-29 22:50:29 +03:00
|
|
|
started = false;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Search through the font tree for anything matching our
|
|
|
|
* current filter criteria. When we find one, add its charset
|
|
|
|
* and/or style name to the list box.
|
|
|
|
*/
|
|
|
|
for (i = start; i <= end; i++) {
|
2019-09-08 22:29:00 +03:00
|
|
|
if (i == end)
|
|
|
|
info = NULL;
|
|
|
|
else
|
|
|
|
info = (fontinfo *)index234(fs->fonts_by_selorder, i);
|
|
|
|
/*
|
|
|
|
* info may be NULL if we've just run off the end of the
|
|
|
|
* relevant data. We must still do a processing pass in
|
|
|
|
* that situation, in case we had an unfinished font
|
|
|
|
* record in progress.
|
|
|
|
*/
|
|
|
|
if (info && (info->flags &~ fs->filter_flags)) {
|
|
|
|
info->styleindex = -1;
|
|
|
|
continue; /* we're filtering out this font */
|
|
|
|
}
|
|
|
|
if (!info || !started || strnullcasecmp(currcs, info->charset) ||
|
|
|
|
strnullcasecmp(currstyle, info->style)) {
|
|
|
|
/*
|
|
|
|
* We've either finished a style/charset, or started a
|
|
|
|
* new one, or both.
|
|
|
|
*/
|
|
|
|
started = true;
|
|
|
|
if (currstyle) {
|
|
|
|
gtk_list_store_append(fs->style_model, &iter);
|
|
|
|
gtk_list_store_set(fs->style_model, &iter,
|
|
|
|
0, currstyle, 1, minpos, 2, maxpos+1,
|
|
|
|
3, true, 4, PANGO_WEIGHT_NORMAL, -1);
|
|
|
|
listindex++;
|
|
|
|
}
|
|
|
|
if (info) {
|
|
|
|
minpos = i;
|
|
|
|
if (info->charset && strnullcasecmp(currcs, info->charset)) {
|
|
|
|
gtk_list_store_append(fs->style_model, &iter);
|
|
|
|
gtk_list_store_set(fs->style_model, &iter,
|
|
|
|
0, info->charset, 1, -1, 2, -1,
|
|
|
|
3, false, 4, PANGO_WEIGHT_BOLD, -1);
|
|
|
|
listindex++;
|
|
|
|
}
|
|
|
|
currcs = info->charset;
|
|
|
|
currstyle = info->style;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!info)
|
|
|
|
break; /* now we're done */
|
|
|
|
info->styleindex = listindex;
|
|
|
|
maxpos = i;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static const int unifontsel_default_sizes[] = { 10, 12, 14, 16, 20, 24, 32 };
|
|
|
|
|
|
|
|
static void unifontsel_setup_sizelist(unifontsel_internal *fs,
|
2019-09-08 22:29:00 +03:00
|
|
|
int start, int end)
|
2008-03-26 00:49:14 +03:00
|
|
|
{
|
|
|
|
GtkTreeIter iter;
|
|
|
|
int i, listindex;
|
|
|
|
char sizetext[40];
|
|
|
|
fontinfo *info;
|
|
|
|
|
|
|
|
gtk_list_store_clear(fs->size_model);
|
|
|
|
listindex = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Search through the font tree for anything matching our
|
|
|
|
* current filter criteria. When we find one, add its font
|
|
|
|
* name to the list box.
|
|
|
|
*/
|
|
|
|
for (i = start; i < end; i++) {
|
2019-09-08 22:29:00 +03:00
|
|
|
info = (fontinfo *)index234(fs->fonts_by_selorder, i);
|
|
|
|
if (info->flags &~ fs->filter_flags) {
|
|
|
|
info->sizeindex = -1;
|
|
|
|
continue; /* we're filtering out this font */
|
|
|
|
}
|
|
|
|
if (info->size) {
|
|
|
|
sprintf(sizetext, "%d", info->size);
|
|
|
|
info->sizeindex = listindex;
|
|
|
|
gtk_list_store_append(fs->size_model, &iter);
|
|
|
|
gtk_list_store_set(fs->size_model, &iter,
|
|
|
|
0, sizetext, 1, i, 2, info->size, -1);
|
|
|
|
listindex++;
|
|
|
|
} else {
|
|
|
|
int j;
|
|
|
|
|
|
|
|
assert(i == start);
|
|
|
|
assert(i+1 == end);
|
|
|
|
|
|
|
|
for (j = 0; j < lenof(unifontsel_default_sizes); j++) {
|
|
|
|
sprintf(sizetext, "%d", unifontsel_default_sizes[j]);
|
|
|
|
gtk_list_store_append(fs->size_model, &iter);
|
|
|
|
gtk_list_store_set(fs->size_model, &iter, 0, sizetext, 1, i,
|
|
|
|
2, unifontsel_default_sizes[j], -1);
|
|
|
|
listindex++;
|
|
|
|
}
|
|
|
|
}
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void unifontsel_set_filter_buttons(unifontsel_internal *fs)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2015-08-08 18:35:19 +03:00
|
|
|
for (i = 0; i < fs->n_filter_buttons; i++) {
|
2015-08-08 19:29:02 +03:00
|
|
|
int flagbit = GPOINTER_TO_INT(g_object_get_data
|
|
|
|
(G_OBJECT(fs->filter_buttons[i]),
|
2019-09-08 22:29:00 +03:00
|
|
|
"user-data"));
|
|
|
|
gtk_toggle_button_set_active(GTK_TOGGLE_BUTTON(fs->filter_buttons[i]),
|
|
|
|
!!(fs->filter_flags & flagbit));
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-16 12:32:24 +03:00
|
|
|
static void unifontsel_draw_preview_text_inner(unifont_drawctx *dctx,
|
|
|
|
unifontsel_internal *fs)
|
2008-03-27 22:53:28 +03:00
|
|
|
{
|
|
|
|
unifont *font;
|
2008-03-29 16:59:31 +03:00
|
|
|
char *sizename = NULL;
|
2008-03-27 22:53:28 +03:00
|
|
|
fontinfo *info = fs->selected;
|
|
|
|
|
2008-03-29 16:59:31 +03:00
|
|
|
if (info) {
|
2019-09-08 22:29:00 +03:00
|
|
|
sizename = info->fontclass->scale_fontname
|
|
|
|
(GTK_WIDGET(fs->u.window), info->realname, fs->selsize);
|
|
|
|
font = info->fontclass->create(GTK_WIDGET(fs->u.window),
|
|
|
|
sizename ? sizename : info->realname,
|
|
|
|
false, false, 0, 0);
|
2008-03-29 16:59:31 +03:00
|
|
|
} else
|
2019-09-08 22:29:00 +03:00
|
|
|
font = NULL;
|
2008-03-27 22:53:28 +03:00
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#ifdef DRAW_TEXT_GDK
|
2015-08-22 15:41:15 +03:00
|
|
|
if (dctx->type == DRAWTYPE_GDK) {
|
|
|
|
gdk_gc_set_foreground(dctx->u.gdk.gc, &fs->preview_bg);
|
|
|
|
gdk_draw_rectangle(dctx->u.gdk.target, dctx->u.gdk.gc, 1, 0, 0,
|
|
|
|
fs->preview_width, fs->preview_height);
|
|
|
|
gdk_gc_set_foreground(dctx->u.gdk.gc, &fs->preview_fg);
|
|
|
|
}
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#endif
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
2015-08-22 15:41:15 +03:00
|
|
|
if (dctx->type == DRAWTYPE_CAIRO) {
|
|
|
|
cairo_set_source_rgb(dctx->u.cairo.cr,
|
|
|
|
fs->preview_bg.red / 65535.0,
|
|
|
|
fs->preview_bg.green / 65535.0,
|
|
|
|
fs->preview_bg.blue / 65535.0);
|
|
|
|
cairo_paint(dctx->u.cairo.cr);
|
|
|
|
cairo_set_source_rgb(dctx->u.cairo.cr,
|
|
|
|
fs->preview_fg.red / 65535.0,
|
|
|
|
fs->preview_fg.green / 65535.0,
|
|
|
|
fs->preview_fg.blue / 65535.0);
|
|
|
|
}
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#endif
|
|
|
|
|
2015-08-22 15:41:15 +03:00
|
|
|
if (font) {
|
2015-08-16 12:32:24 +03:00
|
|
|
/*
|
|
|
|
* The pangram used here is rather carefully
|
|
|
|
* constructed: it contains a sequence of very narrow
|
|
|
|
* letters (`jil') and a pair of adjacent very wide
|
|
|
|
* letters (`wm').
|
|
|
|
*
|
|
|
|
* If the user selects a proportional font, it will be
|
|
|
|
* coerced into fixed-width character cells when used
|
|
|
|
* in the actual terminal window. We therefore display
|
|
|
|
* it the same way in the preview pane, so as to show
|
|
|
|
* it the way it will actually be displayed - and we
|
|
|
|
* deliberately pick a pangram which will show the
|
|
|
|
* resulting miskerning at its worst.
|
|
|
|
*
|
|
|
|
* We aren't trying to sell people these fonts; we're
|
|
|
|
* trying to let them make an informed choice. Better
|
|
|
|
* that they find out the problems with using
|
|
|
|
* proportional fonts in terminal windows here than
|
|
|
|
* that they go to the effort of selecting their font
|
|
|
|
* and _then_ realise it was a mistake.
|
|
|
|
*/
|
|
|
|
info->fontclass->draw_text(dctx, font,
|
|
|
|
0, font->ascent,
|
|
|
|
L"bankrupt jilted showmen quiz convex fogey",
|
2018-10-29 22:50:29 +03:00
|
|
|
41, false, false, font->width);
|
2015-08-16 12:32:24 +03:00
|
|
|
info->fontclass->draw_text(dctx, font,
|
|
|
|
0, font->ascent + font->height,
|
|
|
|
L"BANKRUPT JILTED SHOWMEN QUIZ CONVEX FOGEY",
|
2018-10-29 22:50:29 +03:00
|
|
|
41, false, false, font->width);
|
2015-08-16 12:32:24 +03:00
|
|
|
/*
|
|
|
|
* The ordering of punctuation here is also selected
|
|
|
|
* with some specific aims in mind. I put ` and '
|
|
|
|
* together because some software (and people) still
|
|
|
|
* use them as matched quotes no matter what Unicode
|
|
|
|
* might say on the matter, so people can quickly
|
|
|
|
* check whether they look silly in a candidate font.
|
|
|
|
* The sequence #_@ is there to let people judge the
|
|
|
|
* suitability of the underscore as an effectively
|
|
|
|
* alphabetic character (since that's how it's often
|
|
|
|
* used in practice, at least by programmers).
|
|
|
|
*/
|
|
|
|
info->fontclass->draw_text(dctx, font,
|
|
|
|
0, font->ascent + font->height * 2,
|
|
|
|
L"0123456789!?,.:;<>()[]{}\\/`'\"+*-=~#_@|%&^$",
|
2018-10-29 22:50:29 +03:00
|
|
|
42, false, false, font->width);
|
2015-08-16 12:32:24 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
info->fontclass->destroy(font);
|
2015-08-16 12:32:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
sfree(sizename);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void unifontsel_draw_preview_text(unifontsel_internal *fs)
|
|
|
|
{
|
|
|
|
unifont_drawctx dctx;
|
2015-08-16 11:02:31 +03:00
|
|
|
GdkWindow *target;
|
2015-08-16 12:32:24 +03:00
|
|
|
|
2015-08-16 11:02:31 +03:00
|
|
|
#ifndef NO_BACKING_PIXMAPS
|
|
|
|
target = fs->preview_pixmap;
|
|
|
|
#else
|
|
|
|
target = gtk_widget_get_window(fs->preview_area);
|
|
|
|
#endif
|
|
|
|
if (!target) /* we may be called when we haven't created everything yet */
|
2015-08-16 12:32:24 +03:00
|
|
|
return;
|
|
|
|
|
|
|
|
dctx.type = DRAWTYPE_DEFAULT;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#ifdef DRAW_TEXT_GDK
|
2015-08-16 12:32:24 +03:00
|
|
|
if (dctx.type == DRAWTYPE_GDK) {
|
2015-08-16 11:02:31 +03:00
|
|
|
dctx.u.gdk.target = target;
|
|
|
|
dctx.u.gdk.gc = gdk_gc_new(target);
|
2015-08-16 12:32:24 +03:00
|
|
|
}
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#endif
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
2015-08-16 12:32:24 +03:00
|
|
|
if (dctx.type == DRAWTYPE_CAIRO) {
|
2017-02-27 22:58:39 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,22,0)
|
|
|
|
cairo_region_t *region;
|
|
|
|
#endif
|
|
|
|
|
2015-08-16 12:32:24 +03:00
|
|
|
dctx.u.cairo.widget = GTK_WIDGET(fs->preview_area);
|
2017-02-27 22:58:39 +03:00
|
|
|
|
|
|
|
#if GTK_CHECK_VERSION(3,22,0)
|
|
|
|
dctx.u.cairo.gdkwin = gtk_widget_get_window(dctx.u.cairo.widget);
|
|
|
|
region = gdk_window_get_clip_region(dctx.u.cairo.gdkwin);
|
|
|
|
dctx.u.cairo.drawctx = gdk_window_begin_draw_frame(
|
|
|
|
dctx.u.cairo.gdkwin, region);
|
|
|
|
dctx.u.cairo.cr = gdk_drawing_context_get_cairo_context(
|
|
|
|
dctx.u.cairo.drawctx);
|
|
|
|
cairo_region_destroy(region);
|
|
|
|
#else
|
2015-08-16 11:02:31 +03:00
|
|
|
dctx.u.cairo.cr = gdk_cairo_create(target);
|
2017-02-27 22:58:39 +03:00
|
|
|
#endif
|
2015-08-16 12:32:24 +03:00
|
|
|
}
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#endif
|
|
|
|
|
2015-08-16 12:32:24 +03:00
|
|
|
unifontsel_draw_preview_text_inner(&dctx, fs);
|
|
|
|
|
|
|
|
#ifdef DRAW_TEXT_GDK
|
|
|
|
if (dctx.type == DRAWTYPE_GDK) {
|
|
|
|
gdk_gc_unref(dctx.u.gdk.gc);
|
2008-03-27 22:53:28 +03:00
|
|
|
}
|
2015-08-16 12:32:24 +03:00
|
|
|
#endif
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
if (dctx.type == DRAWTYPE_CAIRO) {
|
2017-02-27 22:58:39 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,22,0)
|
|
|
|
gdk_window_end_draw_frame(dctx.u.cairo.gdkwin, dctx.u.cairo.drawctx);
|
|
|
|
#else
|
2015-08-16 12:32:24 +03:00
|
|
|
cairo_destroy(dctx.u.cairo.cr);
|
2017-02-27 22:58:39 +03:00
|
|
|
#endif
|
2015-08-16 12:32:24 +03:00
|
|
|
}
|
|
|
|
#endif
|
2008-03-27 22:53:28 +03:00
|
|
|
|
2015-08-16 12:32:24 +03:00
|
|
|
gdk_window_invalidate_rect(gtk_widget_get_window(fs->preview_area),
|
2018-10-29 22:50:29 +03:00
|
|
|
NULL, false);
|
2008-03-27 22:53:28 +03:00
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
static void unifontsel_select_font(unifontsel_internal *fs,
|
2019-09-08 22:29:00 +03:00
|
|
|
fontinfo *info, int size, int leftlist,
|
|
|
|
bool size_is_explicit)
|
2008-03-26 00:49:14 +03:00
|
|
|
{
|
|
|
|
int index;
|
|
|
|
int minval, maxval;
|
2015-08-22 15:41:11 +03:00
|
|
|
gboolean success;
|
2008-03-26 00:49:14 +03:00
|
|
|
GtkTreePath *treepath;
|
|
|
|
GtkTreeIter iter;
|
|
|
|
|
2018-10-29 22:50:29 +03:00
|
|
|
fs->inhibit_response = true;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
fs->selected = info;
|
|
|
|
fs->selsize = size;
|
2008-03-29 13:16:48 +03:00
|
|
|
if (size_is_explicit)
|
2019-09-08 22:29:00 +03:00
|
|
|
fs->intendedsize = size;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2018-10-29 22:50:29 +03:00
|
|
|
gtk_widget_set_sensitive(fs->u.ok_button, true);
|
2008-03-29 17:21:25 +03:00
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
/*
|
2019-09-08 22:29:00 +03:00
|
|
|
* Find the index of this fontinfo in the selorder list.
|
2008-03-26 00:49:14 +03:00
|
|
|
*/
|
|
|
|
index = -1;
|
|
|
|
findpos234(fs->fonts_by_selorder, info, NULL, &index);
|
|
|
|
assert(index >= 0);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Adjust the font selector flags and redo the font family
|
|
|
|
* list box, if necessary.
|
|
|
|
*/
|
|
|
|
if (leftlist <= 0 &&
|
2019-09-08 22:29:00 +03:00
|
|
|
(fs->filter_flags | info->flags) != fs->filter_flags) {
|
|
|
|
fs->filter_flags |= info->flags;
|
|
|
|
unifontsel_set_filter_buttons(fs);
|
|
|
|
unifontsel_setup_familylist(fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the appropriate family name and select it in the list.
|
|
|
|
*/
|
|
|
|
assert(info->familyindex >= 0);
|
|
|
|
treepath = gtk_tree_path_new_from_indices(info->familyindex, -1);
|
|
|
|
gtk_tree_selection_select_path
|
2019-09-08 22:29:00 +03:00
|
|
|
(gtk_tree_view_get_selection(GTK_TREE_VIEW(fs->family_list)),
|
|
|
|
treepath);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_tree_view_scroll_to_cell(GTK_TREE_VIEW(fs->family_list),
|
2019-09-08 22:29:00 +03:00
|
|
|
treepath, NULL, false, 0.0, 0.0);
|
2015-08-22 15:41:11 +03:00
|
|
|
success = gtk_tree_model_get_iter(GTK_TREE_MODEL(fs->family_model),
|
|
|
|
&iter, treepath);
|
|
|
|
assert(success);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_tree_path_free(treepath);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now set up the font style list.
|
|
|
|
*/
|
|
|
|
gtk_tree_model_get(GTK_TREE_MODEL(fs->family_model), &iter,
|
2019-09-08 22:29:00 +03:00
|
|
|
1, &minval, 2, &maxval, -1);
|
2008-03-26 00:49:14 +03:00
|
|
|
if (leftlist <= 1)
|
2019-09-08 22:29:00 +03:00
|
|
|
unifontsel_setup_stylelist(fs, minval, maxval);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the appropriate style name and select it in the list.
|
|
|
|
*/
|
|
|
|
if (info->style) {
|
2019-09-08 22:29:00 +03:00
|
|
|
assert(info->styleindex >= 0);
|
|
|
|
treepath = gtk_tree_path_new_from_indices(info->styleindex, -1);
|
|
|
|
gtk_tree_selection_select_path
|
|
|
|
(gtk_tree_view_get_selection(GTK_TREE_VIEW(fs->style_list)),
|
|
|
|
treepath);
|
|
|
|
gtk_tree_view_scroll_to_cell(GTK_TREE_VIEW(fs->style_list),
|
|
|
|
treepath, NULL, false, 0.0, 0.0);
|
|
|
|
gtk_tree_model_get_iter(GTK_TREE_MODEL(fs->style_model),
|
|
|
|
&iter, treepath);
|
|
|
|
gtk_tree_path_free(treepath);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* And set up the size list.
|
|
|
|
*/
|
|
|
|
gtk_tree_model_get(GTK_TREE_MODEL(fs->style_model), &iter,
|
|
|
|
1, &minval, 2, &maxval, -1);
|
|
|
|
if (leftlist <= 2)
|
|
|
|
unifontsel_setup_sizelist(fs, minval, maxval);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the appropriate size, and select it in the list.
|
|
|
|
*/
|
|
|
|
if (info->size) {
|
|
|
|
assert(info->sizeindex >= 0);
|
|
|
|
treepath = gtk_tree_path_new_from_indices(info->sizeindex, -1);
|
|
|
|
gtk_tree_selection_select_path
|
|
|
|
(gtk_tree_view_get_selection(GTK_TREE_VIEW(fs->size_list)),
|
|
|
|
treepath);
|
|
|
|
gtk_tree_view_scroll_to_cell(GTK_TREE_VIEW(fs->size_list),
|
|
|
|
treepath, NULL, false, 0.0, 0.0);
|
|
|
|
gtk_tree_path_free(treepath);
|
|
|
|
size = info->size;
|
|
|
|
} else {
|
|
|
|
int j;
|
|
|
|
for (j = 0; j < lenof(unifontsel_default_sizes); j++)
|
|
|
|
if (unifontsel_default_sizes[j] == size) {
|
|
|
|
treepath = gtk_tree_path_new_from_indices(j, -1);
|
|
|
|
gtk_tree_view_set_cursor(GTK_TREE_VIEW(fs->size_list),
|
|
|
|
treepath, NULL, false);
|
|
|
|
gtk_tree_view_scroll_to_cell(GTK_TREE_VIEW(fs->size_list),
|
|
|
|
treepath, NULL, false, 0.0,
|
|
|
|
0.0);
|
|
|
|
gtk_tree_path_free(treepath);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* And set up the font size text entry box.
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
char sizetext[40];
|
|
|
|
sprintf(sizetext, "%d", size);
|
|
|
|
gtk_entry_set_text(GTK_ENTRY(fs->size_entry), sizetext);
|
|
|
|
}
|
2008-03-26 00:49:14 +03:00
|
|
|
} else {
|
2019-09-08 22:29:00 +03:00
|
|
|
if (leftlist <= 2)
|
|
|
|
unifontsel_setup_sizelist(fs, 0, 0);
|
|
|
|
gtk_entry_set_text(GTK_ENTRY(fs->size_entry), "");
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Grey out the font size edit box if we're not using a
|
|
|
|
* scalable font.
|
|
|
|
*/
|
2015-08-08 20:02:01 +03:00
|
|
|
gtk_editable_set_editable(GTK_EDITABLE(fs->size_entry),
|
|
|
|
fs->selected->size == 0);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_set_sensitive(fs->size_entry, fs->selected->size == 0);
|
|
|
|
|
2008-03-27 22:53:28 +03:00
|
|
|
unifontsel_draw_preview_text(fs);
|
2008-03-27 22:41:08 +03:00
|
|
|
|
2018-10-29 22:50:29 +03:00
|
|
|
fs->inhibit_response = false;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void unifontsel_button_toggled(GtkToggleButton *tb, gpointer data)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
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 22:23:19 +03:00
|
|
|
bool newstate = gtk_toggle_button_get_active(tb);
|
2008-03-26 00:49:14 +03:00
|
|
|
int newflags;
|
2015-08-08 19:29:02 +03:00
|
|
|
int flagbit = GPOINTER_TO_INT(g_object_get_data(G_OBJECT(tb),
|
|
|
|
"user-data"));
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
if (newstate)
|
2019-09-08 22:29:00 +03:00
|
|
|
newflags = fs->filter_flags | flagbit;
|
2008-03-26 00:49:14 +03:00
|
|
|
else
|
2019-09-08 22:29:00 +03:00
|
|
|
newflags = fs->filter_flags & ~flagbit;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
if (fs->filter_flags != newflags) {
|
2019-09-08 22:29:00 +03:00
|
|
|
fs->filter_flags = newflags;
|
|
|
|
unifontsel_setup_familylist(fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void unifontsel_add_entry(void *ctx, const char *realfontname,
|
2019-09-08 22:29:00 +03:00
|
|
|
const char *family, const char *charset,
|
|
|
|
const char *style, const char *stylekey,
|
|
|
|
int size, int flags,
|
|
|
|
const struct UnifontVtable *fontclass)
|
2008-03-26 00:49:14 +03:00
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)ctx;
|
|
|
|
fontinfo *info;
|
|
|
|
int totalsize;
|
|
|
|
char *p;
|
|
|
|
|
|
|
|
totalsize = sizeof(fontinfo) + strlen(realfontname) +
|
2019-09-08 22:29:00 +03:00
|
|
|
(family ? strlen(family) : 0) + (charset ? strlen(charset) : 0) +
|
|
|
|
(style ? strlen(style) : 0) + (stylekey ? strlen(stylekey) : 0) + 10;
|
2008-03-26 00:49:14 +03:00
|
|
|
info = (fontinfo *)smalloc(totalsize);
|
|
|
|
info->fontclass = fontclass;
|
|
|
|
p = (char *)info + sizeof(fontinfo);
|
|
|
|
info->realname = p;
|
|
|
|
strcpy(p, realfontname);
|
|
|
|
p += 1+strlen(p);
|
|
|
|
if (family) {
|
2019-09-08 22:29:00 +03:00
|
|
|
info->family = p;
|
|
|
|
strcpy(p, family);
|
|
|
|
p += 1+strlen(p);
|
2008-03-26 00:49:14 +03:00
|
|
|
} else
|
2019-09-08 22:29:00 +03:00
|
|
|
info->family = NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
if (charset) {
|
2019-09-08 22:29:00 +03:00
|
|
|
info->charset = p;
|
|
|
|
strcpy(p, charset);
|
|
|
|
p += 1+strlen(p);
|
2008-03-26 00:49:14 +03:00
|
|
|
} else
|
2019-09-08 22:29:00 +03:00
|
|
|
info->charset = NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
if (style) {
|
2019-09-08 22:29:00 +03:00
|
|
|
info->style = p;
|
|
|
|
strcpy(p, style);
|
|
|
|
p += 1+strlen(p);
|
2008-03-26 00:49:14 +03:00
|
|
|
} else
|
2019-09-08 22:29:00 +03:00
|
|
|
info->style = NULL;
|
2008-03-26 23:20:25 +03:00
|
|
|
if (stylekey) {
|
2019-09-08 22:29:00 +03:00
|
|
|
info->stylekey = p;
|
|
|
|
strcpy(p, stylekey);
|
|
|
|
p += 1+strlen(p);
|
2008-03-26 23:20:25 +03:00
|
|
|
} else
|
2019-09-08 22:29:00 +03:00
|
|
|
info->stylekey = NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
assert(p - (char *)info <= totalsize);
|
|
|
|
info->size = size;
|
|
|
|
info->flags = flags;
|
|
|
|
info->index = count234(fs->fonts_by_selorder);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It's just conceivable that a misbehaving font enumerator
|
|
|
|
* might tell us about the same font real name more than once,
|
|
|
|
* in which case we should silently drop the new one.
|
|
|
|
*/
|
|
|
|
if (add234(fs->fonts_by_realname, info) != info) {
|
2019-09-08 22:29:00 +03:00
|
|
|
sfree(info);
|
|
|
|
return;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
/*
|
|
|
|
* However, we should never get a duplicate key in the
|
|
|
|
* selorder tree, because the index field carefully
|
|
|
|
* disambiguates otherwise identical records.
|
|
|
|
*/
|
|
|
|
add234(fs->fonts_by_selorder, info);
|
|
|
|
}
|
|
|
|
|
2008-03-29 13:16:48 +03:00
|
|
|
static fontinfo *update_for_intended_size(unifontsel_internal *fs,
|
2019-09-08 22:29:00 +03:00
|
|
|
fontinfo *info)
|
2008-03-29 13:16:48 +03:00
|
|
|
{
|
|
|
|
fontinfo info2, *below, *above;
|
|
|
|
int pos;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Copy the info structure. This doesn't copy its dynamic
|
|
|
|
* string fields, but that's unimportant because all we're
|
|
|
|
* going to do is to adjust the size field and use it in one
|
|
|
|
* tree search.
|
|
|
|
*/
|
|
|
|
info2 = *info;
|
|
|
|
info2.size = fs->intendedsize;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Search in the tree to find the fontinfo structure which
|
|
|
|
* best approximates the size the user last requested.
|
|
|
|
*/
|
|
|
|
below = findrelpos234(fs->fonts_by_selorder, &info2, NULL,
|
2019-09-08 22:29:00 +03:00
|
|
|
REL234_LE, &pos);
|
2013-07-11 21:24:28 +04:00
|
|
|
if (!below)
|
|
|
|
pos = -1;
|
2008-03-29 13:16:48 +03:00
|
|
|
above = index234(fs->fonts_by_selorder, pos+1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* See if we've found it exactly, which is an easy special
|
|
|
|
* case. If we have, it'll be in `below' and not `above',
|
|
|
|
* because we did a REL234_LE rather than REL234_LT search.
|
|
|
|
*/
|
2013-07-11 21:24:28 +04:00
|
|
|
if (below && !fontinfo_selorder_compare(&info2, below))
|
2019-09-08 22:29:00 +03:00
|
|
|
return below;
|
2008-03-29 13:16:48 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now we've either found two suitable fonts, one smaller and
|
|
|
|
* one larger, or we're at one or other extreme end of the
|
|
|
|
* scale. Find out which, by NULLing out either of below and
|
|
|
|
* above if it differs from this one in any respect but size
|
|
|
|
* (and the disambiguating index field). Bear in mind, also,
|
|
|
|
* that either one might _already_ be NULL if we're at the
|
|
|
|
* extreme ends of the font list.
|
|
|
|
*/
|
|
|
|
if (below) {
|
2019-09-08 22:29:00 +03:00
|
|
|
info2.size = below->size;
|
|
|
|
info2.index = below->index;
|
|
|
|
if (fontinfo_selorder_compare(&info2, below))
|
|
|
|
below = NULL;
|
2008-03-29 13:16:48 +03:00
|
|
|
}
|
|
|
|
if (above) {
|
2019-09-08 22:29:00 +03:00
|
|
|
info2.size = above->size;
|
|
|
|
info2.index = above->index;
|
|
|
|
if (fontinfo_selorder_compare(&info2, above))
|
|
|
|
above = NULL;
|
2008-03-29 13:16:48 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now return whichever of above and below is non-NULL, if
|
|
|
|
* that's unambiguous.
|
|
|
|
*/
|
|
|
|
if (!above)
|
2019-09-08 22:29:00 +03:00
|
|
|
return below;
|
2008-03-29 13:16:48 +03:00
|
|
|
if (!below)
|
2019-09-08 22:29:00 +03:00
|
|
|
return above;
|
2008-03-29 13:16:48 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* And now we really do have to make a choice about whether to
|
|
|
|
* round up or down. We'll do it by rounding to nearest,
|
|
|
|
* breaking ties by rounding up.
|
|
|
|
*/
|
|
|
|
if (above->size - fs->intendedsize <= fs->intendedsize - below->size)
|
2019-09-08 22:29:00 +03:00
|
|
|
return above;
|
2008-03-29 13:16:48 +03:00
|
|
|
else
|
2019-09-08 22:29:00 +03:00
|
|
|
return below;
|
2008-03-29 13:16:48 +03:00
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
static void family_changed(GtkTreeSelection *treeselection, gpointer data)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
GtkTreeModel *treemodel;
|
|
|
|
GtkTreeIter treeiter;
|
|
|
|
int minval;
|
|
|
|
fontinfo *info;
|
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
if (fs->inhibit_response) /* we made this change ourselves */
|
|
|
|
return;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
if (!gtk_tree_selection_get_selected(treeselection, &treemodel, &treeiter))
|
2019-09-08 22:29:00 +03:00
|
|
|
return;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
gtk_tree_model_get(treemodel, &treeiter, 1, &minval, -1);
|
|
|
|
info = (fontinfo *)index234(fs->fonts_by_selorder, minval);
|
2008-03-29 13:16:48 +03:00
|
|
|
info = update_for_intended_size(fs, info);
|
|
|
|
if (!info)
|
2019-09-08 22:29:00 +03:00
|
|
|
return; /* _shouldn't_ happen unless font list is completely funted */
|
2008-03-29 13:16:48 +03:00
|
|
|
if (!info->size)
|
2019-09-08 22:29:00 +03:00
|
|
|
fs->selsize = fs->intendedsize; /* font is scalable */
|
2008-03-29 13:16:48 +03:00
|
|
|
unifontsel_select_font(fs, info, info->size ? info->size : fs->selsize,
|
2019-09-08 22:29:00 +03:00
|
|
|
1, false);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void style_changed(GtkTreeSelection *treeselection, gpointer data)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
GtkTreeModel *treemodel;
|
|
|
|
GtkTreeIter treeiter;
|
|
|
|
int minval;
|
|
|
|
fontinfo *info;
|
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
if (fs->inhibit_response) /* we made this change ourselves */
|
|
|
|
return;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
if (!gtk_tree_selection_get_selected(treeselection, &treemodel, &treeiter))
|
2019-09-08 22:29:00 +03:00
|
|
|
return;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
gtk_tree_model_get(treemodel, &treeiter, 1, &minval, -1);
|
2008-03-26 21:30:20 +03:00
|
|
|
if (minval < 0)
|
|
|
|
return; /* somehow a charset heading got clicked */
|
2008-03-26 00:49:14 +03:00
|
|
|
info = (fontinfo *)index234(fs->fonts_by_selorder, minval);
|
2008-03-29 13:16:48 +03:00
|
|
|
info = update_for_intended_size(fs, info);
|
|
|
|
if (!info)
|
2019-09-08 22:29:00 +03:00
|
|
|
return; /* _shouldn't_ happen unless font list is completely funted */
|
2008-03-29 13:16:48 +03:00
|
|
|
if (!info->size)
|
2019-09-08 22:29:00 +03:00
|
|
|
fs->selsize = fs->intendedsize; /* font is scalable */
|
2008-03-29 13:16:48 +03:00
|
|
|
unifontsel_select_font(fs, info, info->size ? info->size : fs->selsize,
|
2019-09-08 22:29:00 +03:00
|
|
|
2, false);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void size_changed(GtkTreeSelection *treeselection, gpointer data)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
GtkTreeModel *treemodel;
|
|
|
|
GtkTreeIter treeiter;
|
|
|
|
int minval, size;
|
|
|
|
fontinfo *info;
|
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
if (fs->inhibit_response) /* we made this change ourselves */
|
|
|
|
return;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
if (!gtk_tree_selection_get_selected(treeselection, &treemodel, &treeiter))
|
2019-09-08 22:29:00 +03:00
|
|
|
return;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
gtk_tree_model_get(treemodel, &treeiter, 1, &minval, 2, &size, -1);
|
|
|
|
info = (fontinfo *)index234(fs->fonts_by_selorder, minval);
|
2018-10-29 22:50:29 +03:00
|
|
|
unifontsel_select_font(fs, info, info->size ? info->size : size, 3, true);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void size_entry_changed(GtkEditable *ed, gpointer data)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
const char *text;
|
|
|
|
int size;
|
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
if (fs->inhibit_response) /* we made this change ourselves */
|
|
|
|
return;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
text = gtk_entry_get_text(GTK_ENTRY(ed));
|
|
|
|
size = atoi(text);
|
|
|
|
|
|
|
|
if (size > 0) {
|
2019-09-08 22:29:00 +03:00
|
|
|
assert(fs->selected->size == 0);
|
|
|
|
unifontsel_select_font(fs, fs->selected, size, 3, true);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-03-27 22:41:08 +03:00
|
|
|
static void alias_resolve(GtkTreeView *treeview, GtkTreePath *path,
|
2019-09-08 22:29:00 +03:00
|
|
|
GtkTreeViewColumn *column, gpointer data)
|
2008-03-27 22:41:08 +03:00
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
GtkTreeIter iter;
|
|
|
|
int minval, newsize;
|
|
|
|
fontinfo *info, *newinfo;
|
|
|
|
char *newname;
|
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
if (fs->inhibit_response) /* we made this change ourselves */
|
|
|
|
return;
|
2008-03-27 22:41:08 +03:00
|
|
|
|
|
|
|
gtk_tree_model_get_iter(GTK_TREE_MODEL(fs->family_model), &iter, path);
|
|
|
|
gtk_tree_model_get(GTK_TREE_MODEL(fs->family_model), &iter, 1,&minval, -1);
|
|
|
|
info = (fontinfo *)index234(fs->fonts_by_selorder, minval);
|
|
|
|
if (info) {
|
2019-09-08 22:29:00 +03:00
|
|
|
int flags;
|
|
|
|
struct fontinfo_realname_find f;
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
newname = info->fontclass->canonify_fontname
|
|
|
|
(GTK_WIDGET(fs->u.window), info->realname, &newsize, &flags, true);
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
f.realname = newname;
|
|
|
|
f.flags = flags;
|
|
|
|
newinfo = find234(fs->fonts_by_realname, &f, fontinfo_realname_find);
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
sfree(newname);
|
|
|
|
if (!newinfo)
|
|
|
|
return; /* font name not in our index */
|
|
|
|
if (newinfo == info)
|
|
|
|
return; /* didn't change under canonification => not an alias */
|
|
|
|
unifontsel_select_font(fs, newinfo,
|
|
|
|
newinfo->size ? newinfo->size : newsize,
|
|
|
|
1, true);
|
2008-03-27 22:41:08 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-16 16:34:19 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
static gint unifontsel_draw_area(GtkWidget *widget, cairo_t *cr, gpointer data)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
unifont_drawctx dctx;
|
|
|
|
|
|
|
|
dctx.type = DRAWTYPE_CAIRO;
|
|
|
|
dctx.u.cairo.widget = widget;
|
|
|
|
dctx.u.cairo.cr = cr;
|
|
|
|
unifontsel_draw_preview_text_inner(&dctx, fs);
|
|
|
|
|
2018-10-29 22:50:29 +03:00
|
|
|
return true;
|
2015-08-16 16:34:19 +03:00
|
|
|
}
|
|
|
|
#else
|
2008-03-27 22:41:08 +03:00
|
|
|
static gint unifontsel_expose_area(GtkWidget *widget, GdkEventExpose *event,
|
2019-09-08 22:29:00 +03:00
|
|
|
gpointer data)
|
2008-03-27 22:41:08 +03:00
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
|
2015-08-16 11:02:31 +03:00
|
|
|
#ifndef NO_BACKING_PIXMAPS
|
2008-03-27 22:41:08 +03:00
|
|
|
if (fs->preview_pixmap) {
|
2015-08-08 17:53:43 +03:00
|
|
|
gdk_draw_pixmap(gtk_widget_get_window(widget),
|
2019-09-08 22:29:00 +03:00
|
|
|
(gtk_widget_get_style(widget)->fg_gc
|
2015-08-08 17:53:43 +03:00
|
|
|
[gtk_widget_get_state(widget)]),
|
2019-09-08 22:29:00 +03:00
|
|
|
fs->preview_pixmap,
|
|
|
|
event->area.x, event->area.y,
|
|
|
|
event->area.x, event->area.y,
|
|
|
|
event->area.width, event->area.height);
|
2008-03-27 22:41:08 +03:00
|
|
|
}
|
2015-08-16 11:02:31 +03:00
|
|
|
#else
|
|
|
|
unifontsel_draw_preview_text(fs);
|
|
|
|
#endif
|
|
|
|
|
2018-10-29 22:50:29 +03:00
|
|
|
return true;
|
2008-03-27 22:41:08 +03:00
|
|
|
}
|
2015-08-16 16:34:19 +03:00
|
|
|
#endif
|
2008-03-27 22:41:08 +03:00
|
|
|
|
|
|
|
static gint unifontsel_configure_area(GtkWidget *widget,
|
2019-09-08 22:29:00 +03:00
|
|
|
GdkEventConfigure *event, gpointer data)
|
2008-03-27 22:41:08 +03:00
|
|
|
{
|
2015-08-16 11:02:31 +03:00
|
|
|
#ifndef NO_BACKING_PIXMAPS
|
2008-03-27 22:41:08 +03:00
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
int ox, oy, nx, ny, x, y;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Enlarge the pixmap, but never shrink it.
|
|
|
|
*/
|
|
|
|
ox = fs->preview_width;
|
|
|
|
oy = fs->preview_height;
|
|
|
|
x = event->width;
|
|
|
|
y = event->height;
|
|
|
|
if (x > ox || y > oy) {
|
2019-09-08 22:29:00 +03:00
|
|
|
if (fs->preview_pixmap)
|
|
|
|
gdk_pixmap_unref(fs->preview_pixmap);
|
|
|
|
|
|
|
|
nx = (x > ox ? x : ox);
|
|
|
|
ny = (y > oy ? y : oy);
|
|
|
|
fs->preview_pixmap = gdk_pixmap_new(gtk_widget_get_window(widget),
|
2015-08-08 17:53:43 +03:00
|
|
|
nx, ny, -1);
|
2019-09-08 22:29:00 +03:00
|
|
|
fs->preview_width = nx;
|
|
|
|
fs->preview_height = ny;
|
2008-03-27 22:53:28 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
unifontsel_draw_preview_text(fs);
|
2008-03-27 22:41:08 +03:00
|
|
|
}
|
2015-08-16 11:02:31 +03:00
|
|
|
#endif
|
2008-03-27 22:41:08 +03:00
|
|
|
|
2018-10-29 22:50:29 +03:00
|
|
|
gdk_window_invalidate_rect(gtk_widget_get_window(widget), NULL, false);
|
2008-03-27 22:41:08 +03:00
|
|
|
|
2018-10-29 22:50:29 +03:00
|
|
|
return true;
|
2008-03-27 22:41:08 +03:00
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
unifontsel *unifontsel_new(const char *wintitle)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = snew(unifontsel_internal);
|
2008-03-29 16:55:40 +03:00
|
|
|
GtkWidget *table, *label, *w, *ww, *scroll;
|
2008-03-26 00:49:14 +03:00
|
|
|
GtkListStore *model;
|
|
|
|
GtkTreeViewColumn *column;
|
2008-03-27 22:41:08 +03:00
|
|
|
int lists_height, preview_height, font_width, style_width, size_width;
|
2008-03-26 00:49:14 +03:00
|
|
|
int i;
|
|
|
|
|
2018-10-29 22:50:29 +03:00
|
|
|
fs->inhibit_response = false;
|
2008-04-14 22:00:57 +04:00
|
|
|
fs->selected = NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
{
|
2015-08-22 13:46:05 +03:00
|
|
|
int width, height;
|
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
/*
|
|
|
|
* Invent some magic size constants.
|
|
|
|
*/
|
|
|
|
get_label_text_dimensions("Quite Long Font Name (Foundry)",
|
2015-08-22 13:46:05 +03:00
|
|
|
&width, &height);
|
2019-09-08 22:29:00 +03:00
|
|
|
font_width = width;
|
|
|
|
lists_height = 14 * height;
|
|
|
|
preview_height = 5 * height;
|
2015-08-22 13:46:05 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
get_label_text_dimensions("Italic Extra Condensed", &width, &height);
|
|
|
|
style_width = width;
|
2015-08-22 13:46:05 +03:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
get_label_text_dimensions("48000", &width, &height);
|
|
|
|
size_width = width;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create the dialog box and initialise the user-visible
|
|
|
|
* fields in the returned structure.
|
|
|
|
*/
|
|
|
|
fs->u.user_data = NULL;
|
|
|
|
fs->u.window = GTK_WINDOW(gtk_dialog_new());
|
|
|
|
gtk_window_set_title(fs->u.window, wintitle);
|
|
|
|
fs->u.cancel_button = gtk_dialog_add_button
|
2019-09-08 22:29:00 +03:00
|
|
|
(GTK_DIALOG(fs->u.window), STANDARD_CANCEL_LABEL, GTK_RESPONSE_CANCEL);
|
2008-03-26 00:49:14 +03:00
|
|
|
fs->u.ok_button = gtk_dialog_add_button
|
2019-09-08 22:29:00 +03:00
|
|
|
(GTK_DIALOG(fs->u.window), STANDARD_OK_LABEL, GTK_RESPONSE_OK);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_grab_default(fs->u.ok_button);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now set up the internal fields, including in particular all
|
|
|
|
* the controls that actually allow the user to select fonts.
|
|
|
|
*/
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
table = gtk_grid_new();
|
|
|
|
gtk_grid_set_column_spacing(GTK_GRID(table), 8);
|
|
|
|
#else
|
2018-10-29 22:50:29 +03:00
|
|
|
table = gtk_table_new(8, 3, false);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_set_col_spacings(GTK_TABLE(table), 8);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
|
|
|
gtk_widget_show(table);
|
2015-08-31 16:05:51 +03:00
|
|
|
|
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
/* GtkAlignment has become deprecated and we use the "margin"
|
|
|
|
* property */
|
|
|
|
w = table;
|
|
|
|
g_object_set(G_OBJECT(w), "margin", 8, (const char *)NULL);
|
|
|
|
#elif GTK_CHECK_VERSION(2,4,0)
|
2008-03-29 17:54:55 +03:00
|
|
|
/* GtkAlignment seems to be the simplest way to put padding round things */
|
|
|
|
w = gtk_alignment_new(0, 0, 1, 1);
|
|
|
|
gtk_alignment_set_padding(GTK_ALIGNMENT(w), 8, 8, 8, 8);
|
|
|
|
gtk_container_add(GTK_CONTAINER(w), table);
|
|
|
|
gtk_widget_show(w);
|
2008-05-31 23:23:45 +04:00
|
|
|
#else
|
2015-08-31 16:05:51 +03:00
|
|
|
/* In GTK < 2.4, even that isn't available */
|
2008-05-31 23:23:45 +04:00
|
|
|
w = table;
|
|
|
|
#endif
|
2015-08-31 16:05:51 +03:00
|
|
|
|
2015-08-08 17:53:43 +03:00
|
|
|
gtk_box_pack_start(GTK_BOX(gtk_dialog_get_content_area
|
|
|
|
(GTK_DIALOG(fs->u.window))),
|
2019-09-08 22:29:00 +03:00
|
|
|
w, true, true, 0);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
label = gtk_label_new_with_mnemonic("_Font:");
|
|
|
|
gtk_widget_show(label);
|
2015-08-31 15:57:34 +03:00
|
|
|
align_label_left(GTK_LABEL(label));
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), label, 0, 0, 1, 1);
|
2018-10-29 22:50:29 +03:00
|
|
|
g_object_set(G_OBJECT(label), "hexpand", true, (const char *)NULL);
|
2015-08-22 16:28:04 +03:00
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), label, 0, 1, 0, 1, GTK_FILL, 0, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The Font list box displays only a string, but additionally
|
|
|
|
* stores two integers which give the limits within the
|
|
|
|
* tree234 of the font entries covered by this list entry.
|
|
|
|
*/
|
|
|
|
model = gtk_list_store_new(3, G_TYPE_STRING, G_TYPE_INT, G_TYPE_INT);
|
|
|
|
w = gtk_tree_view_new_with_model(GTK_TREE_MODEL(model));
|
2018-10-29 22:50:29 +03:00
|
|
|
gtk_tree_view_set_headers_visible(GTK_TREE_VIEW(w), false);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_label_set_mnemonic_widget(GTK_LABEL(label), w);
|
|
|
|
gtk_widget_show(w);
|
|
|
|
column = gtk_tree_view_column_new_with_attributes
|
2019-09-08 22:29:00 +03:00
|
|
|
("Font", gtk_cell_renderer_text_new(),
|
|
|
|
"text", 0, (char *)NULL);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_tree_view_column_set_sizing(column, GTK_TREE_VIEW_COLUMN_AUTOSIZE);
|
|
|
|
gtk_tree_view_append_column(GTK_TREE_VIEW(w), column);
|
|
|
|
g_signal_connect(G_OBJECT(gtk_tree_view_get_selection(GTK_TREE_VIEW(w))),
|
2019-09-08 22:29:00 +03:00
|
|
|
"changed", G_CALLBACK(family_changed), fs);
|
2008-03-27 22:41:08 +03:00
|
|
|
g_signal_connect(G_OBJECT(w), "row-activated",
|
2019-09-08 22:29:00 +03:00
|
|
|
G_CALLBACK(alias_resolve), fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
scroll = gtk_scrolled_window_new(NULL, NULL);
|
2008-03-29 16:55:40 +03:00
|
|
|
gtk_scrolled_window_set_shadow_type(GTK_SCROLLED_WINDOW(scroll),
|
2019-09-08 22:29:00 +03:00
|
|
|
GTK_SHADOW_IN);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_container_add(GTK_CONTAINER(scroll), w);
|
|
|
|
gtk_widget_show(scroll);
|
|
|
|
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(scroll),
|
2019-09-08 22:29:00 +03:00
|
|
|
GTK_POLICY_AUTOMATIC, GTK_POLICY_ALWAYS);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_set_size_request(scroll, font_width, lists_height);
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), scroll, 0, 1, 1, 2);
|
2018-10-29 22:50:29 +03:00
|
|
|
g_object_set(G_OBJECT(scroll), "expand", true, (const char *)NULL);
|
2015-08-22 16:28:04 +03:00
|
|
|
#else
|
2008-03-29 16:55:40 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), scroll, 0, 1, 1, 3, GTK_FILL,
|
2019-09-08 22:29:00 +03:00
|
|
|
GTK_EXPAND | GTK_FILL, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
fs->family_model = model;
|
|
|
|
fs->family_list = w;
|
|
|
|
|
|
|
|
label = gtk_label_new_with_mnemonic("_Style:");
|
|
|
|
gtk_widget_show(label);
|
2015-08-31 15:57:34 +03:00
|
|
|
align_label_left(GTK_LABEL(label));
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), label, 1, 0, 1, 1);
|
2018-10-29 22:50:29 +03:00
|
|
|
g_object_set(G_OBJECT(label), "hexpand", true, (const char *)NULL);
|
2015-08-22 16:28:04 +03:00
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), label, 1, 2, 0, 1, GTK_FILL, 0, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
2015-09-26 12:42:02 +03:00
|
|
|
* The Style list box can contain insensitive elements (character
|
|
|
|
* set headings for server-side fonts), so we add an extra column
|
|
|
|
* to the list store to hold that information. Also, since GTK3 at
|
|
|
|
* least doesn't seem to display insensitive elements differently
|
|
|
|
* by default, we add a further column to change their style.
|
2008-03-26 00:49:14 +03:00
|
|
|
*/
|
2015-09-26 12:42:02 +03:00
|
|
|
model = gtk_list_store_new(5, G_TYPE_STRING, G_TYPE_INT, G_TYPE_INT,
|
2019-09-08 22:29:00 +03:00
|
|
|
G_TYPE_BOOLEAN, G_TYPE_INT);
|
2008-03-26 00:49:14 +03:00
|
|
|
w = gtk_tree_view_new_with_model(GTK_TREE_MODEL(model));
|
2018-10-29 22:50:29 +03:00
|
|
|
gtk_tree_view_set_headers_visible(GTK_TREE_VIEW(w), false);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_label_set_mnemonic_widget(GTK_LABEL(label), w);
|
|
|
|
gtk_widget_show(w);
|
|
|
|
column = gtk_tree_view_column_new_with_attributes
|
2019-09-08 22:29:00 +03:00
|
|
|
("Style", gtk_cell_renderer_text_new(),
|
|
|
|
"text", 0, "sensitive", 3, "weight", 4, (char *)NULL);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_tree_view_column_set_sizing(column, GTK_TREE_VIEW_COLUMN_AUTOSIZE);
|
|
|
|
gtk_tree_view_append_column(GTK_TREE_VIEW(w), column);
|
|
|
|
g_signal_connect(G_OBJECT(gtk_tree_view_get_selection(GTK_TREE_VIEW(w))),
|
2019-09-08 22:29:00 +03:00
|
|
|
"changed", G_CALLBACK(style_changed), fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
scroll = gtk_scrolled_window_new(NULL, NULL);
|
2008-03-29 16:55:40 +03:00
|
|
|
gtk_scrolled_window_set_shadow_type(GTK_SCROLLED_WINDOW(scroll),
|
2019-09-08 22:29:00 +03:00
|
|
|
GTK_SHADOW_IN);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_container_add(GTK_CONTAINER(scroll), w);
|
|
|
|
gtk_widget_show(scroll);
|
|
|
|
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(scroll),
|
2019-09-08 22:29:00 +03:00
|
|
|
GTK_POLICY_AUTOMATIC, GTK_POLICY_ALWAYS);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_set_size_request(scroll, style_width, lists_height);
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), scroll, 1, 1, 1, 2);
|
2018-10-29 22:50:29 +03:00
|
|
|
g_object_set(G_OBJECT(scroll), "expand", true, (const char *)NULL);
|
2015-08-22 16:28:04 +03:00
|
|
|
#else
|
2008-03-29 16:55:40 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), scroll, 1, 2, 1, 3, GTK_FILL,
|
2019-09-08 22:29:00 +03:00
|
|
|
GTK_EXPAND | GTK_FILL, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
fs->style_model = model;
|
|
|
|
fs->style_list = w;
|
|
|
|
|
|
|
|
label = gtk_label_new_with_mnemonic("Si_ze:");
|
|
|
|
gtk_widget_show(label);
|
2015-08-31 15:57:34 +03:00
|
|
|
align_label_left(GTK_LABEL(label));
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), label, 2, 0, 1, 1);
|
2018-10-29 22:50:29 +03:00
|
|
|
g_object_set(G_OBJECT(label), "hexpand", true, (const char *)NULL);
|
2015-08-22 16:28:04 +03:00
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), label, 2, 3, 0, 1, GTK_FILL, 0, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The Size label attaches primarily to a text input box so
|
|
|
|
* that the user can select a size of their choice. The list
|
|
|
|
* of available sizes is secondary.
|
|
|
|
*/
|
|
|
|
fs->size_entry = w = gtk_entry_new();
|
|
|
|
gtk_label_set_mnemonic_widget(GTK_LABEL(label), w);
|
|
|
|
gtk_widget_set_size_request(w, size_width, -1);
|
|
|
|
gtk_widget_show(w);
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), w, 2, 1, 1, 1);
|
2018-10-29 22:50:29 +03:00
|
|
|
g_object_set(G_OBJECT(w), "hexpand", true, (const char *)NULL);
|
2015-08-22 16:28:04 +03:00
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), w, 2, 3, 1, 2, GTK_FILL, 0, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
g_signal_connect(G_OBJECT(w), "changed", G_CALLBACK(size_entry_changed),
|
2019-09-08 22:29:00 +03:00
|
|
|
fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
model = gtk_list_store_new(3, G_TYPE_STRING, G_TYPE_INT, G_TYPE_INT);
|
|
|
|
w = gtk_tree_view_new_with_model(GTK_TREE_MODEL(model));
|
2018-10-29 22:50:29 +03:00
|
|
|
gtk_tree_view_set_headers_visible(GTK_TREE_VIEW(w), false);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_show(w);
|
|
|
|
column = gtk_tree_view_column_new_with_attributes
|
2019-09-08 22:29:00 +03:00
|
|
|
("Size", gtk_cell_renderer_text_new(),
|
|
|
|
"text", 0, (char *)NULL);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_tree_view_column_set_sizing(column, GTK_TREE_VIEW_COLUMN_AUTOSIZE);
|
|
|
|
gtk_tree_view_append_column(GTK_TREE_VIEW(w), column);
|
|
|
|
g_signal_connect(G_OBJECT(gtk_tree_view_get_selection(GTK_TREE_VIEW(w))),
|
2019-09-08 22:29:00 +03:00
|
|
|
"changed", G_CALLBACK(size_changed), fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
scroll = gtk_scrolled_window_new(NULL, NULL);
|
2008-03-29 16:55:40 +03:00
|
|
|
gtk_scrolled_window_set_shadow_type(GTK_SCROLLED_WINDOW(scroll),
|
2019-09-08 22:29:00 +03:00
|
|
|
GTK_SHADOW_IN);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_container_add(GTK_CONTAINER(scroll), w);
|
|
|
|
gtk_widget_show(scroll);
|
|
|
|
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(scroll),
|
2019-09-08 22:29:00 +03:00
|
|
|
GTK_POLICY_AUTOMATIC, GTK_POLICY_ALWAYS);
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), scroll, 2, 2, 1, 1);
|
2018-10-29 22:50:29 +03:00
|
|
|
g_object_set(G_OBJECT(scroll), "expand", true, (const char *)NULL);
|
2015-08-22 16:28:04 +03:00
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), scroll, 2, 3, 2, 3, GTK_FILL,
|
2019-09-08 22:29:00 +03:00
|
|
|
GTK_EXPAND | GTK_FILL, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
fs->size_model = model;
|
|
|
|
fs->size_list = w;
|
|
|
|
|
2008-03-29 17:54:55 +03:00
|
|
|
/*
|
|
|
|
* Preview widget.
|
|
|
|
*/
|
2008-03-27 22:41:08 +03:00
|
|
|
fs->preview_area = gtk_drawing_area_new();
|
2015-08-16 11:02:31 +03:00
|
|
|
#ifndef NO_BACKING_PIXMAPS
|
2008-03-27 22:41:08 +03:00
|
|
|
fs->preview_pixmap = NULL;
|
2015-08-16 11:02:31 +03:00
|
|
|
#endif
|
2008-03-27 22:41:08 +03:00
|
|
|
fs->preview_width = 0;
|
|
|
|
fs->preview_height = 0;
|
|
|
|
fs->preview_fg.pixel = fs->preview_bg.pixel = 0;
|
|
|
|
fs->preview_fg.red = fs->preview_fg.green = fs->preview_fg.blue = 0x0000;
|
|
|
|
fs->preview_bg.red = fs->preview_bg.green = fs->preview_bg.blue = 0xFFFF;
|
2015-08-16 16:22:14 +03:00
|
|
|
#if !GTK_CHECK_VERSION(3,0,0)
|
2008-03-27 22:41:08 +03:00
|
|
|
gdk_colormap_alloc_color(gdk_colormap_get_system(), &fs->preview_fg,
|
2019-09-08 22:29:00 +03:00
|
|
|
false, false);
|
2008-03-27 22:41:08 +03:00
|
|
|
gdk_colormap_alloc_color(gdk_colormap_get_system(), &fs->preview_bg,
|
2019-09-08 22:29:00 +03:00
|
|
|
false, false);
|
2015-08-16 16:22:14 +03:00
|
|
|
#endif
|
2015-08-16 16:34:19 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
g_signal_connect(G_OBJECT(fs->preview_area), "draw",
|
|
|
|
G_CALLBACK(unifontsel_draw_area), fs);
|
|
|
|
#else
|
2015-08-08 19:29:02 +03:00
|
|
|
g_signal_connect(G_OBJECT(fs->preview_area), "expose_event",
|
|
|
|
G_CALLBACK(unifontsel_expose_area), fs);
|
2015-08-16 16:34:19 +03:00
|
|
|
#endif
|
2015-08-08 19:29:02 +03:00
|
|
|
g_signal_connect(G_OBJECT(fs->preview_area), "configure_event",
|
|
|
|
G_CALLBACK(unifontsel_configure_area), fs);
|
2008-03-27 22:41:08 +03:00
|
|
|
gtk_widget_set_size_request(fs->preview_area, 1, preview_height);
|
|
|
|
gtk_widget_show(fs->preview_area);
|
2008-03-29 16:55:40 +03:00
|
|
|
ww = fs->preview_area;
|
|
|
|
w = gtk_frame_new(NULL);
|
|
|
|
gtk_container_add(GTK_CONTAINER(w), ww);
|
|
|
|
gtk_widget_show(w);
|
2015-08-31 16:05:51 +03:00
|
|
|
|
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
/* GtkAlignment has become deprecated and we use the "margin"
|
|
|
|
* property */
|
|
|
|
g_object_set(G_OBJECT(w), "margin", 8, (const char *)NULL);
|
|
|
|
#elif GTK_CHECK_VERSION(2,4,0)
|
2008-03-29 16:55:40 +03:00
|
|
|
ww = w;
|
|
|
|
/* GtkAlignment seems to be the simplest way to put padding round things */
|
|
|
|
w = gtk_alignment_new(0, 0, 1, 1);
|
|
|
|
gtk_alignment_set_padding(GTK_ALIGNMENT(w), 8, 8, 8, 8);
|
|
|
|
gtk_container_add(GTK_CONTAINER(w), ww);
|
|
|
|
gtk_widget_show(w);
|
2008-05-31 23:23:45 +04:00
|
|
|
#endif
|
2015-08-31 16:05:51 +03:00
|
|
|
|
2008-03-29 16:55:40 +03:00
|
|
|
ww = w;
|
|
|
|
w = gtk_frame_new("Preview of font");
|
|
|
|
gtk_container_add(GTK_CONTAINER(w), ww);
|
|
|
|
gtk_widget_show(w);
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), w, 0, 3, 3, 1);
|
2018-10-29 22:50:29 +03:00
|
|
|
g_object_set(G_OBJECT(w), "expand", true, (const char *)NULL);
|
2015-08-22 16:28:04 +03:00
|
|
|
#else
|
2008-03-29 16:55:40 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), w, 0, 3, 3, 4,
|
2019-09-08 22:29:00 +03:00
|
|
|
GTK_EXPAND | GTK_FILL, GTK_EXPAND | GTK_FILL, 0, 8);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-27 22:41:08 +03:00
|
|
|
|
2015-08-08 18:35:19 +03:00
|
|
|
/*
|
|
|
|
* We only provide the checkboxes for client- and server-side
|
|
|
|
* fonts if we have the X11 back end available, because that's the
|
|
|
|
* only situation in which more than one class of font is
|
|
|
|
* available anyway.
|
|
|
|
*/
|
|
|
|
fs->n_filter_buttons = 0;
|
|
|
|
#ifndef NOT_X_WINDOWS
|
2008-03-26 00:49:14 +03:00
|
|
|
w = gtk_check_button_new_with_label("Show client-side fonts");
|
2015-08-08 19:29:02 +03:00
|
|
|
g_object_set_data(G_OBJECT(w), "user-data",
|
|
|
|
GINT_TO_POINTER(FONTFLAG_CLIENTSIDE));
|
|
|
|
g_signal_connect(G_OBJECT(w), "toggled",
|
|
|
|
G_CALLBACK(unifontsel_button_toggled), fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_show(w);
|
2015-08-08 18:35:19 +03:00
|
|
|
fs->filter_buttons[fs->n_filter_buttons++] = w;
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), w, 0, 4, 3, 1);
|
2018-10-29 22:50:29 +03:00
|
|
|
g_object_set(G_OBJECT(w), "hexpand", true, (const char *)NULL);
|
2015-08-22 16:28:04 +03:00
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), w, 0, 3, 4, 5, GTK_FILL, 0, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
w = gtk_check_button_new_with_label("Show server-side fonts");
|
2015-08-08 19:29:02 +03:00
|
|
|
g_object_set_data(G_OBJECT(w), "user-data",
|
|
|
|
GINT_TO_POINTER(FONTFLAG_SERVERSIDE));
|
|
|
|
g_signal_connect(G_OBJECT(w), "toggled",
|
|
|
|
G_CALLBACK(unifontsel_button_toggled), fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_show(w);
|
2015-08-08 18:35:19 +03:00
|
|
|
fs->filter_buttons[fs->n_filter_buttons++] = w;
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), w, 0, 5, 3, 1);
|
2018-10-29 22:50:29 +03:00
|
|
|
g_object_set(G_OBJECT(w), "hexpand", true, (const char *)NULL);
|
2015-08-22 16:28:04 +03:00
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), w, 0, 3, 5, 6, GTK_FILL, 0, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
w = gtk_check_button_new_with_label("Show server-side font aliases");
|
2015-08-08 19:29:02 +03:00
|
|
|
g_object_set_data(G_OBJECT(w), "user-data",
|
|
|
|
GINT_TO_POINTER(FONTFLAG_SERVERALIAS));
|
|
|
|
g_signal_connect(G_OBJECT(w), "toggled",
|
|
|
|
G_CALLBACK(unifontsel_button_toggled), fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_show(w);
|
2015-08-08 18:35:19 +03:00
|
|
|
fs->filter_buttons[fs->n_filter_buttons++] = w;
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), w, 0, 6, 3, 1);
|
2018-10-29 22:50:29 +03:00
|
|
|
g_object_set(G_OBJECT(w), "hexpand", true, (const char *)NULL);
|
2015-08-22 16:28:04 +03:00
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), w, 0, 3, 6, 7, GTK_FILL, 0, 0, 0);
|
2015-08-08 18:35:19 +03:00
|
|
|
#endif
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif /* NOT_X_WINDOWS */
|
2008-03-26 00:49:14 +03:00
|
|
|
w = gtk_check_button_new_with_label("Show non-monospaced fonts");
|
2015-08-08 19:29:02 +03:00
|
|
|
g_object_set_data(G_OBJECT(w), "user-data",
|
|
|
|
GINT_TO_POINTER(FONTFLAG_NONMONOSPACED));
|
|
|
|
g_signal_connect(G_OBJECT(w), "toggled",
|
|
|
|
G_CALLBACK(unifontsel_button_toggled), fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_show(w);
|
2015-08-08 18:35:19 +03:00
|
|
|
fs->filter_buttons[fs->n_filter_buttons++] = w;
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), w, 0, 7, 3, 1);
|
2018-10-29 22:50:29 +03:00
|
|
|
g_object_set(G_OBJECT(w), "hexpand", true, (const char *)NULL);
|
2015-08-22 16:28:04 +03:00
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), w, 0, 3, 7, 8, GTK_FILL, 0, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2015-08-08 18:35:19 +03:00
|
|
|
assert(fs->n_filter_buttons <= lenof(fs->filter_buttons));
|
2008-04-02 18:50:47 +04:00
|
|
|
fs->filter_flags = FONTFLAG_CLIENTSIDE | FONTFLAG_SERVERSIDE |
|
2019-09-08 22:29:00 +03:00
|
|
|
FONTFLAG_SERVERALIAS;
|
2008-03-26 00:49:14 +03:00
|
|
|
unifontsel_set_filter_buttons(fs);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Go and find all the font names, and set up our master font
|
|
|
|
* list.
|
|
|
|
*/
|
|
|
|
fs->fonts_by_realname = newtree234(fontinfo_realname_compare);
|
|
|
|
fs->fonts_by_selorder = newtree234(fontinfo_selorder_compare);
|
|
|
|
for (i = 0; i < lenof(unifont_types); i++)
|
2019-09-08 22:29:00 +03:00
|
|
|
unifont_types[i]->enum_fonts(GTK_WIDGET(fs->u.window),
|
|
|
|
unifontsel_add_entry, fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* And set up the initial font names list.
|
|
|
|
*/
|
|
|
|
unifontsel_setup_familylist(fs);
|
|
|
|
|
2008-03-29 17:21:25 +03:00
|
|
|
fs->selsize = fs->intendedsize = 13; /* random default */
|
2018-10-29 22:50:29 +03:00
|
|
|
gtk_widget_set_sensitive(fs->u.ok_button, false);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2018-10-05 09:02:19 +03:00
|
|
|
return &fs->u;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void unifontsel_destroy(unifontsel *fontsel)
|
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
unifontsel_internal *fs = container_of(fontsel, unifontsel_internal, u);
|
2008-03-26 00:49:14 +03:00
|
|
|
fontinfo *info;
|
|
|
|
|
2015-08-16 11:02:31 +03:00
|
|
|
#ifndef NO_BACKING_PIXMAPS
|
2008-03-27 22:41:08 +03:00
|
|
|
if (fs->preview_pixmap)
|
2019-09-08 22:29:00 +03:00
|
|
|
gdk_pixmap_unref(fs->preview_pixmap);
|
2015-08-16 11:02:31 +03:00
|
|
|
#endif
|
2008-03-27 22:41:08 +03:00
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
freetree234(fs->fonts_by_selorder);
|
|
|
|
while ((info = delpos234(fs->fonts_by_realname, 0)) != NULL)
|
2019-09-08 22:29:00 +03:00
|
|
|
sfree(info);
|
2008-03-26 00:49:14 +03:00
|
|
|
freetree234(fs->fonts_by_realname);
|
|
|
|
|
|
|
|
gtk_widget_destroy(GTK_WIDGET(fs->u.window));
|
|
|
|
sfree(fs);
|
|
|
|
}
|
|
|
|
|
|
|
|
void unifontsel_set_name(unifontsel *fontsel, const char *fontname)
|
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
unifontsel_internal *fs = container_of(fontsel, unifontsel_internal, u);
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
int i, start, end, size, flags;
|
2008-03-26 21:16:52 +03:00
|
|
|
const char *fontname2 = NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
fontinfo *info;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Provide a default if given an empty or null font name.
|
|
|
|
*/
|
|
|
|
if (!fontname || !*fontname)
|
2019-09-08 22:29:00 +03:00
|
|
|
fontname = DEFAULT_GTK_FONT;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Call the canonify_fontname function.
|
|
|
|
*/
|
|
|
|
fontname = unifont_do_prefix(fontname, &start, &end);
|
|
|
|
for (i = start; i < end; i++) {
|
2019-09-08 22:29:00 +03:00
|
|
|
fontname2 = unifont_types[i]->canonify_fontname
|
|
|
|
(GTK_WIDGET(fs->u.window), fontname, &size, &flags, false);
|
|
|
|
if (fontname2)
|
|
|
|
break;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
if (i == end)
|
2019-09-08 22:29:00 +03:00
|
|
|
return; /* font name not recognised */
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now look up the canonified font name in our index.
|
|
|
|
*/
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
{
|
2019-09-08 22:29:00 +03:00
|
|
|
struct fontinfo_realname_find f;
|
|
|
|
f.realname = fontname2;
|
|
|
|
f.flags = flags;
|
|
|
|
info = find234(fs->fonts_by_realname, &f, fontinfo_realname_find);
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
}
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we've found the font, and its size field is either
|
|
|
|
* correct or zero (the latter indicating a scalable font),
|
|
|
|
* then we're done. Otherwise, try looking up the original
|
|
|
|
* font name instead.
|
|
|
|
*/
|
|
|
|
if (!info || (info->size != size && info->size != 0)) {
|
2019-09-08 22:29:00 +03:00
|
|
|
struct fontinfo_realname_find f;
|
|
|
|
f.realname = fontname;
|
|
|
|
f.flags = flags;
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
|
2019-09-08 22:29:00 +03:00
|
|
|
info = find234(fs->fonts_by_realname, &f, fontinfo_realname_find);
|
|
|
|
if (!info || info->size != size)
|
|
|
|
return; /* font name not in our index */
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now we've got a fontinfo structure and a font size, so we
|
|
|
|
* know everything we need to fill in all the fields in the
|
|
|
|
* dialog.
|
|
|
|
*/
|
2018-10-29 22:50:29 +03:00
|
|
|
unifontsel_select_font(fs, info, size, 0, true);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
char *unifontsel_get_name(unifontsel *fontsel)
|
|
|
|
{
|
2018-10-06 01:49:08 +03:00
|
|
|
unifontsel_internal *fs = container_of(fontsel, unifontsel_internal, u);
|
2008-03-26 00:49:14 +03:00
|
|
|
char *name;
|
|
|
|
|
2008-03-29 17:21:25 +03:00
|
|
|
if (!fs->selected)
|
2019-09-08 22:29:00 +03:00
|
|
|
return NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
if (fs->selected->size == 0) {
|
2019-09-08 22:29:00 +03:00
|
|
|
name = fs->selected->fontclass->scale_fontname
|
|
|
|
(GTK_WIDGET(fs->u.window), fs->selected->realname, fs->selsize);
|
|
|
|
if (name) {
|
Make dupcat() into a variadic macro.
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.
2019-10-14 21:42:37 +03:00
|
|
|
char *ret = dupcat(fs->selected->fontclass->prefix, ":", name);
|
2019-09-08 22:29:00 +03:00
|
|
|
sfree(name);
|
|
|
|
return ret;
|
|
|
|
}
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
In the new unified font handling, my strategy so far for combining
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
2008-04-05 17:37:20 +04:00
|
|
|
return dupcat(fs->selected->fontclass->prefix, ":",
|
Make dupcat() into a variadic macro.
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.
2019-10-14 21:42:37 +03:00
|
|
|
fs->selected->realname);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
2008-04-04 14:56:26 +04:00
|
|
|
|
|
|
|
#endif /* GTK_CHECK_VERSION(2,0,0) */
|