pub struct Capabilities { /* private fields */ }Expand description
What the terminal told us about itself.
This holds the replies themselves, not a summary of them: the
ModeSetting reported for every mode that was asked about, the raw
device-attribute lists, the reported colors, and so on. A reply that says
“I do not recognize that” is recorded too, so None from an accessor
generally means the terminal never answered, which is different from
answering no. termcap is the exception, folding both
into None; use termcap_reports to separate
them.
Everything here is what the terminal reported, never what the facade told
it. The two are easy to confuse where both exist: a
background_color recorded here stays the
terminal’s own default even after
set_background_color overrides
it.
Only replies land here, so questions the environment can also answer are
deliberately absent. Direct-color support is the example: COLORTERM and
TERM establish it as readily as an XTGETTCAP reply does, so the answer is
Screen::color_profile, which
folds in both, and what remains here is the reply itself via
supports_termcap.
The facade records these as reply events flow through
read_event /
try_read_event, whichever way the
question was put: see
query_capabilities, which asks for
only some of this, and takes extra bytes so you can ask for the rest. An
individual request_* method fills a single entry, and a few reports
arrive unprompted once their mode is on, such as a color-scheme change
under DEC mode 2031. Read it back with
Program::capabilities.
Implementations§
Source§impl Capabilities
impl Capabilities
Sourcepub fn mode(&self, mode: Mode) -> Option<ModeSetting>
pub fn mode(&self, mode: Mode) -> Option<ModeSetting>
The ModeSetting the terminal reported for mode, or None if it
never reported on that mode.
Use this when the distinction matters: ModeSetting::Set means the
mode is currently on, ModeSetting::PermanentlySet means it cannot
be turned off, and ModeSetting::NotRecognized is a definite “no”
rather than silence.
Sourcepub fn supports(&self, mode: Mode) -> bool
pub fn supports(&self, mode: Mode) -> bool
Whether the terminal reported mode as available, in any state.
use uncurses::ansi::mode::Mode;
if program.capabilities().supports(Mode::MOUSE_SGR_PIXEL) {
// pixel-accurate mouse reporting is available
}Sourcepub fn modes(&self) -> &BTreeMap<Mode, ModeSetting>
pub fn modes(&self) -> &BTreeMap<Mode, ModeSetting>
Every mode report recorded so far, keyed by mode.
Sourcepub fn primary_device_attributes(&self) -> Option<&[Option<u32>]>
pub fn primary_device_attributes(&self) -> Option<&[Option<u32>]>
The raw Primary DA (CSI c) attribute list, or None if the terminal
never answered. Entries are None where the terminal sent an empty
parameter.
The first parameter is the terminal’s architectural service class, not
a capability: 6 identifies a VT102 and 64 a VT420. Capability
numbers live in the parameters after it, and only for a VT220-class
terminal or later (62, 63, 64, 65); xterm puts it as “the
VT100-style response parameters do not mean anything by themselves”.
So CSI ? 4 ; 6 c is a VT132 identifying itself, even though 4 is
also the capability number for Sixel graphics on a VT220-class reply.
Read the class first and interpret the rest against it, rather than
searching the list for a number.
The capability numbers are assigned by DEC and extended by terminal authors, so they are reported unparsed.
Sourcepub fn secondary_device_attributes(&self) -> Option<&[Option<u32>]>
pub fn secondary_device_attributes(&self) -> Option<&[Option<u32>]>
The raw Secondary DA (CSI > c) attribute list, or None if the
terminal never answered. Conventionally terminal type, firmware
version, and hardware option, but the meaning of each entry varies by
terminal, so it is reported unparsed.
Sourcepub fn tertiary_device_attributes(&self) -> Option<&str>
pub fn tertiary_device_attributes(&self) -> Option<&str>
The Tertiary DA (CSI = c) terminal unit ID, or None if the
terminal never answered.
Sourcepub fn kitty_graphics(&self) -> bool
pub fn kitty_graphics(&self) -> bool
Whether the terminal has answered a Kitty graphics query, which is the protocol’s own support test: a terminal that does not implement it stays silent.
Sourcepub fn kitty_keyboard(&self) -> Option<KittyKeyboardFlags>
pub fn kitty_keyboard(&self) -> Option<KittyKeyboardFlags>
The Kitty keyboard enhancements the terminal reported, or None if it
never answered CSI ? u. An answer of
empty means the protocol is supported
with no enhancements currently active.
Sourcepub fn modify_other_keys(&self) -> Option<ModifyOtherKeysMode>
pub fn modify_other_keys(&self) -> Option<ModifyOtherKeysMode>
The xterm modifyOtherKeys mode the terminal reported, or None if it
never answered CSI ? 4 m.
Sourcepub fn terminal_name(&self) -> Option<&str>
pub fn terminal_name(&self) -> Option<&str>
The terminal’s self-reported name from XTVERSION (for example
"XTerm(380)"), or None if it never answered.
Sourcepub fn termcap(&self, name: &str) -> Option<&str>
pub fn termcap(&self, name: &str) -> Option<&str>
The value the terminal reported for the XTGETTCAP capability name,
or None if it reported the capability as unsupported or was never
asked. Boolean capabilities report an empty string, so use
supports_termcap to test for presence.
Sourcepub fn supports_termcap(&self, name: &str) -> bool
pub fn supports_termcap(&self, name: &str) -> bool
Whether the terminal reported the XTGETTCAP capability name as
supported. false both for a capability reported unsupported and for
one never asked about; tell them apart with
termcap_reports.
Sourcepub fn termcap_reports(&self) -> &BTreeMap<String, Option<String>>
pub fn termcap_reports(&self) -> &BTreeMap<String, Option<String>>
Every XTGETTCAP reply recorded so far, keyed by capability name. A
value of None is the terminal reporting that capability as
unsupported, which is different from the key being absent.
Sourcepub fn foreground_color(&self) -> Option<Color>
pub fn foreground_color(&self) -> Option<Color>
The terminal’s default foreground color (OSC 10), or None if it
never answered.
Sourcepub fn background_color(&self) -> Option<Color>
pub fn background_color(&self) -> Option<Color>
The terminal’s default background color (OSC 11), or None if it
never answered.
Sourcepub fn cursor_color(&self) -> Option<Color>
pub fn cursor_color(&self) -> Option<Color>
The terminal’s cursor color (OSC 12), or None if it never
answered.
Sourcepub fn palette_color(&self, index: u8) -> Option<Color>
pub fn palette_color(&self, index: u8) -> Option<Color>
The color the terminal reported for palette entry index
(OSC 4 ; index ; ?), or None if it never answered for that entry.
Sourcepub fn palette(&self) -> &BTreeMap<u8, Color>
pub fn palette(&self) -> &BTreeMap<u8, Color>
Every palette color reported so far, keyed by index.
Sourcepub fn color_scheme(&self) -> Option<ColorScheme>
pub fn color_scheme(&self) -> Option<ColorScheme>
Whether the terminal is in its dark or light scheme (DEC mode 2031),
or None if it never reported one. Updated as the scheme changes
while enable_color_scheme_updates
is on. This is the terminal’s own preference flag, which a terminal
can report independently of the colors it uses; when it is absent,
background_color is the fallback.
Trait Implementations§
Source§impl Clone for Capabilities
impl Clone for Capabilities
Source§fn clone(&self) -> Capabilities
fn clone(&self) -> Capabilities
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read moreSource§impl Debug for Capabilities
impl Debug for Capabilities
Source§impl Default for Capabilities
impl Default for Capabilities
Source§fn default() -> Capabilities
fn default() -> Capabilities
impl Eq for Capabilities
Source§impl PartialEq for Capabilities
impl PartialEq for Capabilities
Source§fn eq(&self, other: &Capabilities) -> bool
fn eq(&self, other: &Capabilities) -> bool
self and other values to be equal, and is used by ==.