+++ /dev/null
-The MIT License (MIT)
-
-Copyright (c) 2013-2019 Kevin Lamonte
-
-Permission is hereby granted, free of charge, to any person obtaining
-a copy of this software and associated documentation files (the
-"Software"), to deal in the Software without restriction, including
-without limitation the rights to use, copy, modify, merge, publish,
-distribute, sublicense, and/or sell copies of the Software, and to
-permit persons to whom the Software is furnished to do so, subject to
-the following conditions:
-
-The above copyright notice and this permission notice shall be
-included in all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
-MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
-NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
-LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
-OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
-WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+++ /dev/null
-Jexer - Java Text User Interface library
-========================================
-
-This library implements a text-based windowing system loosely
-reminiscent of Borland's [Turbo
-Vision](http://en.wikipedia.org/wiki/Turbo_Vision) system. It looks
-like this:
-
-
-
-Jexer works on both Xterm-like terminals and Swing, and supports
-images in both Xterm and Swing. On Swing, images are true color:
-
-
-
-On Xterm, images are dithered to a common palette:
-
-
-
-
-
-License
--------
-
-Jexer is available to all under the MIT License. See the file LICENSE
-for the full license text.
-
-
-
-Obtaining Jexer
----------------
-
-Jexer is available on Maven Central:
-
-```xml
-<dependency>
- <groupId>com.gitlab.klamonte</groupId>
- <artifactId>jexer</artifactId>
- <version>0.3.2</version>
-</dependency>
-```
-
-Binary releases are available on SourceForge:
-https://sourceforge.net/projects/jexer/files/jexer/
-
-The Jexer source code is hosted at: https://gitlab.com/klamonte/jexer
-
-
-
-Documentation
--------------
-
-* [Java API Docs](https://jexer.sourceforge.io/apidocs/api/index.html)
-
-* [Wiki](https://gitlab.com/klamonte/jexer/wikis/home)
-
-* [Jexer web page](https://jexer.sourceforge.io/)
-
-
-
-Programming Examples
---------------------
-
-The examples/ folder currently contains:
-
- * A [prototype tiling window
- manager](/examples/JexerTilingWindowManager.java) in less than 250
- lines of code.
-
- * A much slicker [prototype tiling window
- manager](/examples/JexerTilingWindowManager2.java) in less than 200
- lines of code.
-
- * A [prototype image thumbnail
- viewer](/examples/JexerImageViewer.java) in less than 350 lines of
- code.
-
-jexer.demos contains official demos showing all of the existing UI
-controls. The demos can be run as follows:
-
- * 'java -jar jexer.jar' . This will use System.in/out with
- Xterm-like sequences on non-Windows non-Mac platforms. On Windows
- and Mac it will use a Swing JFrame.
-
- * 'java -Djexer.Swing=true -jar jexer.jar' . This will always use
- Swing on any platform.
-
- * 'java -cp jexer.jar jexer.demos.Demo2 PORT' (where PORT is a
- number to run the TCP daemon on). This will use the Xterm backend
- on a telnet server that will update with screen size changes.
-
- * 'java -cp jexer.jar jexer.demos.Demo3' . This will use
- System.in/out with Xterm-like sequences. One can see in the code
- how to pass a different InputReader and OutputReader to
- TApplication, permitting a different encoding than UTF-8.
-
- * 'java -cp jexer.jar jexer.demos.Demo4' . This demonstrates hidden
- windows and a custom TDesktop.
-
- * 'java -cp jexer.jar jexer.demos.Demo5' . This demonstrates two
- demo applications using different fonts in the same Swing frame.
-
- * 'java -cp jexer.jar jexer.demos.Demo6' . This demonstrates two
- applications performing I/O across three screens: an Xterm screen
- and Swing screen, monitored from a third Swing screen.
-
- * 'java -cp jexer.jar jexer.demos.Demo7' . This demonstrates the
- BoxLayoutManager, achieving a similar result as the
- javax.swing.BoxLayout apidocs example.
-
-
-
-More Screenshots
-----------------
-
-Jexer can be run inside its own terminal window, with support for all
-of its features including images and mouse, and more terminals:
-
-
-
-Sixel output uses a single palette which works OK for a variety of
-real-world images:
-
-
-
-The color wheel with that palette is shown below:
-
-
-
-
-
-Terminal Support
-----------------
-
-The table below lists terminals tested against Jexer's Xterm backend:
-
-| Terminal | Environment | Mouse Click | Mouse Cursor | Images |
-| -------------- | ------------------ | ----------- | ------------ | ------ |
-| xterm | X11 | yes | yes | yes |
-| jexer | CLI, X11, Windows | yes | yes | yes |
-| mlterm | X11 | yes | yes | yes |
-| RLogin | Windows | yes | yes | yes |
-| alacritty(3) | X11 | yes | yes | no |
-| gnome-terminal | X11 | yes | yes | no |
-| iTerm2 | Mac | yes | yes | no(5) |
-| kitty(3) | X11 | yes | yes | no |
-| lcxterm(3) | CLI, Linux console | yes | yes | no |
-| mintty | Windows | yes | yes | no(5) |
-| rxvt-unicode | X11 | yes | yes | no(2) |
-| xfce4-terminal | X11 | yes | yes | no |
-| aminal(3) | X11 | yes | no | no |
-| konsole | X11 | yes | no | no |
-| yakuake | X11 | yes | no | no |
-| Windows Terminal(6) | Windows | no | no | no(2) |
-| screen | CLI | yes(1) | yes(1) | no(2) |
-| tmux | CLI | yes(1) | yes(1) | no |
-| putty | X11, Windows | yes | no | no(2) |
-| Linux | Linux console | no | no | no(2) |
-| qodem(3) | CLI, Linux console | yes | yes(4) | no |
-| qodem-x11(3) | X11 | yes | no | no |
-| yaft | Linux console (FB) | no | no | yes |
-
-1 - Requires mouse support from host terminal.
-
-2 - Also fails to filter out sixel data, leaving garbage on screen.
-
-3 - Latest in repository.
-
-4 - Requires TERM=xterm-1003 before starting.
-
-5 - Sixel images can crash terminal.
-
-6 - Version 0.4.2382.0, on Windows 10.0.18362.30. Tested against
- WSL-1 Debian instance.
-
-
-
-See Also
---------
-
-* [Tranquil Java IDE](https://tjide.sourceforge.io) is a TUI-based
- integrated development environment for the Java language that was
- built using a very lightly modified GPL version of Jexer. TJ
- provided a real-world use case to shake out numerous bugs and
- limitations of Jexer.
-
-* [LCXterm](https://lcxterm.sourceforge.io) is a curses-based terminal
- emulator that allows one to use Jexer with full support on the raw
- Linux console.
-
-* [ptypipe](https://gitlab.com/klamonte/ptypipe) is a small C utility
- that permits a Jexer TTerminalWindow to resize the running shell
- when its window is resized.
-
-
-
-Acknowledgements
-----------------
-
-Jexer makes use of the Terminus TrueType font [made available
-here](http://files.ax86.net/terminus-ttf/) .
+++ /dev/null
-<!--
-
- Jexer - Java Text User Interface - Ant build
-
- The MIT License (MIT)
-
- Copyright (C) 2019 Kevin Lamonte
-
- Permission is hereby granted, free of charge, to any person
- obtaining a copy of this software and associated documentation
- files (the "Software"), to deal in the Software without
- restriction, including without limitation the rights to use, copy,
- modify, merge, publish, distribute, sublicense, and/or sell copies
- of the Software, and to permit persons to whom the Software is
- furnished to do so, subject to the following conditions:
-
- The above copyright notice and this permission notice shall be
- included in all copies or substantial portions of the Software.
-
- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
- BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
- ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
- CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
- SOFTWARE.
-
--->
-
-<project name="jexer" basedir="." default="jar">
-
- <property name="version" value="0.3.2"/>
- <property name="src.dir" value="src"/>
- <property name="resources.dir" value="resources"/>
- <property name="build.dir" value="build"/>
- <property name="classes.dir" value="${build.dir}/classes"/>
- <property name="jar.dir" value="${build.dir}/jar"/>
- <property name="apidocs.dir" value="docs/api"/>
-
- <target name="clean">
- <delete dir="${build.dir}"/>
- <delete dir="${apidocs.dir}"/>
- </target>
-
- <target name="compile">
- <mkdir dir="${classes.dir}"/>
- <javac srcdir="${src.dir}" destdir="${classes.dir}"
- includeantruntime="false"
- debug="on"
- debuglevel="lines,vars,source"
- target="1.6"
- source="1.6"
- />
- </target>
-
- <target name="jar" depends="compile">
- <mkdir dir="${jar.dir}"/>
- <jar destfile="${jar.dir}/${ant.project.name}.jar"
- basedir="${classes.dir}">
- <fileset dir="${resources.dir}"/>
-
- <!-- Include properties files. -->
- <fileset dir="${src.dir}" includes="**/*.properties"/>
-
- <!-- Include source by default. -->
- <!-- <fileset dir="${src.dir}"/> -->
-
- <manifest>
- <attribute name="Main-Class" value="jexer.demos.Demo1"/>
- <attribute name="Implementation-Version" value="${version}"/>
- </manifest>
- </jar>
- </target>
-
- <target name="run" depends="jar">
- <java jar="${jar.dir}/${ant.project.name}.jar" fork="true">
- <arg value="-Djexer.Swing=true"/>
- </java>
- </target>
-
- <target name="clean-build" depends="clean,jar"/>
-
- <target name="build" depends="jar"/>
-
- <target name="doc" depends="docs"/>
-
- <!--
- For Java 11+, add additionalparam="dash-dash-frames". My
- workflow is back to Java 8, so leaving this comment here for
- myself when Debian stables moves to Java 11.
- -->
-
-<target name="docs" depends="jar">
- <javadoc
- destdir="${apidocs.dir}"
- author="true"
- version="true"
- use="true"
- access="protected"
- windowtitle="Jexer - Java Text User Interface - API docs"
- >
- <fileset dir="${src.dir}" defaultexcludes="yes">
- <include name="jexer/**/*.java"/>
- </fileset>
-
- <doctitle>
- <![CDATA[<h1>Jexer - Java Text User Interface Library</h1>]]>
- </doctitle>
- <bottom>
- <![CDATA[<i>Copyright © 2019 Kevin Lamonte. Licensed MIT.</i>]]>
- </bottom>
- <!--
- <tag name="todo" scope="all" description="To do:"/>
- <group title="Group 1 Packages" packages="com.dummy.test.a*"/>
- <group title="Group 2 Packages" packages="com.dummy.test.b*:com.dummy.test.c*"/>
- <link offline="true"
- href="http://docs.oracle.com/javase/7/docs/api/"
- packagelistLoc="C:\tmp"/>
- <link href="http://docs.oracle.com/javase/7/docs/api/"/>
- -->
- </javadoc>
- </target>
-
-</project>
+++ /dev/null
-Jexer 0.3.2 Release
-===================
-
-I am pleased to announce the release of Jexer 0.3.2. This release
-completes nearly every feature I set out to make, and is the last
-major milestone before 1.0.0.
-
-Jexer is not an application itself, but rather an advanced text
-windowing system framework to help new applications take full
-advantage of the terminal. Its major features are:
-
- * MIT licensed.
-
- * Direct support for xterm-like terminals: mouse, keyboard, 24-bit
- RGB color, UTF-8, fullwidth characters (CJK and emoji), and sixel
- images.
-
- * A Swing-based GUI window that ships with a good-looking Terminus
- font.
-
- * Sixel image support, for both input in its terminal window and
- output to the host terminal. Jexer is (to my knowledge) the first
- and only system capable of managing multiple terminal windows
- displaying properly overlapping images.
-
- * Draggable / resizable windows, menu bar, and system-modal dialogs
- (message/input boxes and filename picker).
-
- * A full complement of widgets: button, text field, checkbox,
- combobox, list, radio button, scrollbars, data table, calendar
- picker, progress bar, text display, and simple text editor. Plus
- layout manager support for resizable widgets and windows.
-
- * A terminal window capable of passing "vttest" (including VT100
- double-width / double-height), and supporting all of Jexer's
- features. Jexer can run inside itself, with full keyboard, mouse,
- and image support.
-
- * Extensively documented in the code (Javadoc), a wiki, and ships
- with a demonstration application showing off all of its available
- widgets.
-
-
-Find out more at the Jexer Sourceforge or GitLab project pages:
-
- * https://jexer.sourceforge.io/
-
- * https://gitlab.com/klamonte/jexer
-
-
-Download
---------
-
-GitLab: git clone https://gitlab.com/klamonte/jexer.git
-
-Binary downloads: http://sourceforge.net/project/showfiles.php?group_id=2829121
-
-On Maven:
-
- group: com.gitlab.klamonte
- artifact: jexer
- version: 0.3.2
-
-
-Ugh, Java Sucks!
-----------------
-
-(Thor squint) But does it though?
-
-More seriously, I initially picked D because it was sexy. But D circa
-2013 brought too many headaches for me, so I switched to Java because
-I wanted a cross-platform standard library that would be stable over
-many years. And Java is OK, it is a solid workhorse that gets the job
-done.
-
-Yet in porting my initial work to Java I stumbled upon an unexpected
-benefit: I found ways to accomplish all of what Jexer does _without
-calling C directly_. No termios, no ncurses, no forkpty(), and thus
-no serious hurdles porting it to anything that can spawn programs and
-read their output. On Linux, BSD, or OSX, all you need is 'stty' and
-'script' to make things work. (And if you want resizable terminal
-windows, add 'ptypipe'.)
-
-So for those who want something like Jexer but in your own favorite
-language, I encourage you to check out the [Porting
-Jexer](https://gitlab.com/klamonte/jexer/wikis/porting) page on the
-wiki: it has pointers to where the key features are, and a potential
-roadmap if you wanted to take part or all of it into your own hands.
-I licensed Jexer as MIT, stuck with simple Java 1.6, and thoroughly
-documented it in the hope that fans of other languages could more
-easily create or enhance their own text user interfaces.
+++ /dev/null
-Terminal Emulator Multimedia Standard - Proposed Design
-=======================================================
-
-Version: 1
-
-
-
-Purpose
--------
-
-Multiple standards exist to incorporate image data in text-based
-terminals and terminal emulators. Few standards have wide adoption
-despite frequent user requests for these features and hardware support
-for several of the standards.
-
-A group including developers of several widely-used terminal emulators
-has been working on defining the needs and limitations for a standard
-that can be implemented in current-gen terminal emulators. The
-discussion has been primarily captured here:
-https://gitlab.freedesktop.org/terminal-wg/specifications/issues/12
-
-This document collects many of the reported desires and practical
-constraints of that discussion into a proposed standard that
-encompasses three independent new features:
-
-1. A method to transfer multimedia data for immediate display within
- the screen cell grid ("Direct Multimedia").
-
-2. A method to transfer multimedia data to a terminal-managed cache,
- and later display that data within the screen cell grid ("Cached
- Multimedia").
-
-3. A method to assign cell data to different layers with options for
- both layer and cell transparency ("Layers").
-
-A terminal may implement any combination of these features
-independently of each other. If all features are supported, then all
-of the design goals outlined in this document can be met.
-
-The same mechanisms that can put raster-based images on the screen are
-also readily generalizable to other media types such as vector-based
-images and animations. This document is thus a "multimedia" proposal
-rather than a "simple images" proposal.
-
-
-
-Acknowledgements
-----------------
-
-This proposal has been informed from the following prior work:
-
-* DEC VT300 series sixel graphics standard:
- https://vt100.net/docs/vt3xx-gp/chapter14.html
-
-* iTerm2 image protocol:
- https://iterm2.com/documentation-images.html
-
-* Kitty image protocol:
- https://sw.kovidgoyal.net/kitty/graphics-protocol.html
-
-* Jexer Terminal User Interface:
- https://gitlab.com/klamonte/jexer
-
-
-
-Design Goals - Core
--------------------
-
-The core ("must-have") design goals are:
-
-* Be easy to implement in existing terminals and applications:
-
- - Sacrifice "10%" of potential function to eliminate "90%" of
- implementation pain. "Less is more."
-
- - Be a strict superset of the existing iTerm2 and DEC sixel image
- solutions. One should be able to take an existing terminal or
- application that emits/consumes iTerm2 or sixel sequences, and
- only change the control sequence introducer/termination to achieve
- the same effect as a terminal/application that conforms with this
- standard.
-
-* Have no ambiguity. If two terminal or application developers can
- read this document and reach different conclusions on what should be
- on the screen, then an error exists in this document that must be
- corrected.
-
- - Every feature must be straightforward to validate via automated
- unit testing.
-
- - Every conformant terminal must produce the same output (pixels on
- screen) given the same input (terminal font, terminal sequences).
-
- - Every option must have a defined default value.
-
- - Erroneous sequences must have defined expected results.
-
- - Every operation must act atomically: either everything worked
- (image is on screen, cursor has moved, terminal state has changed,
- etc.) or nothing did.
-
-* Integrate with existing ECMA-48 / ANSI X3.64 defined sequences:
-
- - Operations on Tiles/Cells containing text will have the same
- effect when applied to Tiles/Cells containing image data.
-
- - Existing sequences are given new parameters to cover needed
- features rather than entirely new sequences introduced.
-
-* Be straightforward to implement in non-"physical" terminals,
- including:
-
- - Future versions of terminal control libraries such as ncurses and
- termbox.
-
- - Terminal multiplexers that support "headless" terminals (no
- physical screen) and "multi-head" terminals (many different
- physical screens).
-
-* Be platform-agnostic, and easy to implement on (at the least):
- POSIX, Windows, and web.
-
- - All features must be available even if the only means of
- communication between the application and terminal is control
- sequences (e.g. no shared disk, no shared memory, no shared DOM,
- etc.).
-
-* Support graceful fallback:
-
- - Terminal emulators and physical terminals that do not support this
- standard should remain usable with no undefined screen artifacts,
- even when the application blindly emits these sequences to those
- terminals.
-
- - This standard must able to be versioned for future enhancements.
-
- - An application must be able to detect that its terminal supports
- this standard, and at what version.
-
-* Support secure programming practices:
-
- - Applications must not be able to obtain unauthorized data from
- terminal memory, such as: images emitted by other applications
- still present in the terminal's scrollback buffer, terminal or
- system memory limits.
-
- - Applications must not be able to compromise the terminal through
- denial-of-service such as: excessive memory usage, unterminated
- control sequences. Similarly, terminals must not be able to
- compromise application through their responses to application
- queries.
-
- - Applications must not be able to manipulate the terminal into
- performing an insecure operation such as: reading arbitrary shared
- memory regions, reading arbitrary files on disk, deleting
- arbitrary files on disk, etc. Similarly, terminals must not be
- able to manipulate applications into performing insecure
- operations.
-
- - This standard must be implementable when the terminal has a fixed
- maximum memory, such as a kernel-level device driver.
-
-
-
-Design Goals - Secondary
-------------------------
-
-The secondary ("nice-to-have") design goals are listed below. These
-might not all be possible, but will kept in mind:
-
-* Minimal redundant network traffic for on-screen data that is
- repeated: either on screen in multiple places, or in the same place
- but refreshed multiple times.
-
-* Asynchronous notification from terminal to application that the
- screen has been changed by outside or user action. Examples: font
- change, session detach/attach, user changed image preferences.
-
-* The ability for a multiplexer to "pass-thru" the image drawing
- sequence to its "outer" terminal, with some support for limited
- clipping.
-
-
-
-Out Of Scope
-------------
-
-The following items are out of scope:
-
-* Bidirectional output. Applications are expected to generate Tiles
- and place them on screen where they need. The cursor response to
- image sequences are defined as left-to-right-top-to-bottom,
- consistent with ECMA-48 / ANSI X3.64 sequences. An independent BIDI
- standard is free to apply whatever solution will work for ECMA-48 /
- ANSI X3.64 sequences to the sequences described in this document.
-
-* Capabilities. This standard defines a limited number of new
- terminal reports and responses. These are not intended to be used
- as a general-purpose capabilities model.
-
-* Terminal Cache Management. This standard defines a means for
- applications and terminals to communicate around cached multimedia
- items, but terminals are free to implement whatever cache management
- strategies they deem fit.
-
-* Reliable Transport. This standard defines a two-way
- command/response protocol that may get out of order on unreliable
- channels such as 3-wire RS232. Applictions that require reliable
- transport on unreliable links may choose to use one of the many
- successful standards available for this purpose.
-
-
-
-Definitions
------------
-
-Terminal - The hardware, or a program that simulates hardware,
- comprising a keyboard, screen, and mouse.
-
-Application - A program that utilizes the terminal for its
- input/output with the user.
-
-Multiplexer - A special case of an application that simulates one or
- more "inner" terminals for other applications to use,
- and composes these inner terminals into a combined
- screen to emit to one or more "outer" terminals that
- obtain input/output from the user. Multiplexers are
- thus both applications and terminals.
-
-X - The column coordinate of a cell. This standard is 1-based (like
- ECMA-48): the left-most column of the screen is numbered 1.
-
-Y - The row coordinate of a cell. This standard is 1-based (like
- ECMA-48): the top-most row of the screen is numbered 1.
-
-Z - The layer that text or multimedia is placed on. This proposal
- uses a right-hand coordinate system with (X, Y, Z) = (1, 1, 1)
- defined as the top-left corner on the default layer; positive Z
- projects "away" from the user and "into" or "behind" the screen.
- Rendering the Cells on the screen must produce the same result as
- painter's algorithm (see "Layers - Rendering" section below).
-
-Cell - A fixed-width-and-height rectangle on the screen. The cells of
- the screen are arranged in a grid of X columns and Y rows. A
- Cell has dimensions of cellWidth and cellHeight pixels. Every
- Cell has a coordinate of (X, Y) (or (X, Y, Z) when the terminal
- supports the layers feature).
-
-Tile - One or more contiguous Cells with data to be displayed. The
- data can be text or image data, but not both. A Tile has width
- of 1, 2, or more, and a coordinate of (X, Y, Z) that is the
- same as its left-most (first) Cell's (X, Y, Z). In practice,
- Tiles are typically one Cell wide for ASCII and Latin language
- glyphs, and two Cells wide for "fullwidth" glyphs as used in
- Asian langauges, emojis, and symbols. This standard does not
- preclude Tiles from encompassing entire grapheme clusters.
- Note that ECMA-48 / ANSI X3.64 operations are performed against
- Tiles, not Cells: if a 2-Cell-wide Tile is deleted via
- backspace, then the cursor will decrement on screen by two
- columns.
-
-Layer - A screen-sized grid of Cells that have the same Z coordinate.
- Layers are drawn to the screen in descending Z order. Layers
- may have optional additional attributes such as transparency.
- Layer support is an orthogonal (independent) option to
- multimedia support. It is acceptable for terminals to support
- multimedia without layers and vice versa.
-
-
-
-All Features - Detection
-------------------------
-
-Applications can detect support for these features using Primary
-Device Attributes (DA) and DECID (ESC Z, or 0x9A).
-
-Terminals that support this standard will repond with additional
-parameter(s): "224" for direct multimedia, "225" for cached
-multimedia, and "226" for layers. A recap of the parameters xterm
-supports is listed below, with these new feature responses included:
-
-| VT220 (and higher) Response | Description |
-|-----------------------------|--------------------------------------------|
-| 1 | 132-columns |
-| 2 | Printer |
-| 3 | ReGIS graphics |
-| 4 | Sixel graphics |
-| 6 | Selective erase |
-| 8 | User-defined keys |
-| 9 | National Replacement Character sets |
-| 1 5 | Technical characters |
-| 1 6 | Locator port |
-| 1 7 | Terminal state interrogation |
-| 1 8 | User windows |
-| 2 1 | Horizontal scrolling |
-| 2 2 | ANSI color, e.g., VT525 |
-| 2 8 | Rectangular editing |
-| 2 9 | ANSI text locator (i.e., DEC Locator mode) |
-| 2 2 4 | Direct Multimedia Version 1 |
-| 2 2 5 | Cached Multimedia Version 1 |
-| 2 2 6 | Layers |
-
-
-
-Direct Multimedia - Summary
----------------------------
-
-Non-text data (multimedia) can be sent to the terminal for immediate
-display in a rectangular (single-layer) region of text Cells.
-Multimedia data is transmitted to the terminal using one of two wire
-formats described later in this document.
-
-Setting a Cell to multimedia is a destructive operation: the Cell's
-original text is lost. Multimedia pixels will not overlap rendered
-text in the same Cell. To achieve pixels overlaid on text, the layers
-feature can be used.
-
-Setting any part of a multi-Cell Tile to multimedia also "breaks up"
-the Tile into a range of single Cells. In other words, multimedia can
-only be carried by a Cell, not a Tile.
-
-The pixels of a multimedia Cell are assigned to the Cell's foreground;
-multimedia Cells have no background. If a terminal supports the
-layers feature, setting a multimedia Cell's foreground transparency to
-true/enabled causes that Cell to not be displayed at all; setting its
-background transparency to either true/enabled or false/disabled has
-no visible effect.
-
-The pixels of multimedia Cells can come from two sources:
-
- 1. The application can generate pixels and send them to the terminal
- for display at the current cursor position.
-
- 2. The application can specify a source for the multimedia and the
- terminal will generate the pixels for display at the current
- cursor position.
-
-
-
-Direct Multimedia - Required Support For Existing Sequences
------------------------------------------------------------
-
-A terminal with direct multimedia feature must support the following
-defined xterm sequences:
-
-| Sequence | Description |
-|----------------|-----------------------------------------------------|
-| CSI 16 t | Responds with CSI 6 ; cellHeight ; cellWidth t |
-| CSI 18 t | Responds with CSI 8 ; rows ; columns t |
-
-
-
-Direct Multimedia - New Sequences
----------------------------------
-
-A terminal with direct multimedia feature must support the following
-new sequences:
-
-| Sequence | Command | Description |
-|--------------------------------------|-------------|-------------------------|
-| OSC 1 3 3 8 ; s i x e l : {data} BEL | SIXEL | Display sixel at (x, y) |
-| OSC 1 3 3 8 ; s i x e l : {data} ST | SIXEL | Display sixel at (x, y) |
-| OSC 1 3 3 8 ; F i l e = {args} : {data} BEL | DMDISPLAY | Display media at (x, y) |
-| OSC 1 3 3 8 ; F i l e = {args} : {data} ST | DMDISPLAY | Display media at (x, y) |
-| CSI ? 3 0 0 0 h | DECSET 3000 | Enable SCRCHANGE notification |
-| CSI ? 3 0 0 0 l | DECRST 3000 | Disable SCRCHANGE notification |
-| OSC 1 3 3 9 ; Pe ; {args} ST | DMRESP | Terminal response to DMDISPLAY |
-| CSI ? 3 0 0 1 h | DECSET 3001 | Enable DMDISPLAY responses |
-| CSI ? 3 0 0 1 l | DECRST 3001 | Disable DMDISPLAY responses |
-
-
-
-If SCRCHANGE is set/enabled, then the terminal will send the "CSI 6 ;
-cellHeight ; cellWidth t" when the font size has changed, and "CSI 8 ;
-rows ; columns t" when the number of rows/columns on the screen has
-changed.
-
-
-
-For the SIXEL command:
-
-* The {data} is a sixel sequence as described in the VT330/340
- Programmer Reference Manual, Chapter 14, available online at:
- http://vt100.net/docs/vt3xx-gp/chapter14.html . The {data} is the
- "P1 ; P2 ; P3 ; q s..s" portion of the Device Control String, i.e. a
- complete sixel sequence minus the leading DCS and trailing ST.
-
-* The sixel image is processed as shown below. Note that this
- behavior is equivalent to Sixel Scrolling mode enabled.
-
- - The sixel active position starts at the upper-left corner of the
- text cursor position.
-
- - The screen is scrolled up if the image overflows into the bottom
- text row.
-
- - Pixels that would be drawn to the right of the visible region on
- screen are discarded.
-
- - The cursor's final position is on the same column as the starting
- cursor position, and on the row immediately below the image.
-
-
-For the DMDISPLAY command:
-
-* The {args} is a set of key-value pairs (each pair separated by
- semicolon (';')), followed by a colon (':'), followed by a base-64
- encoded string ({data}).
-
-* A key can be any alpha-numeric ASCII string ('0' - '9', 'A' - 'Z',
- 'a' - 'z').
-
-* A value is any printable ASCII string not containing whitespace,
- colon, or semicolon ('!' - '9', '<' - '~').
-
-* Any alpha-numeric key may be specified. A key that is not supported
- by the terminal is ignored without error.
-
-* The multimedia pixels are processed as shown below.
-
- - The pixel are drawn starting at the upper-left corner of the text
- cursor position.
-
- - If scroll is specified as 1 (enabled), then:
-
- a. The screen is scrolled up if the image overflows into the
- bottom text row.
-
- b. The cursor's final position is on the same column as the
- starting cursor position, and on the row immediately below the
- image.
-
- - If scroll is omitted or specified as 0 (disabled), then:
-
- a. The screen is never scrolled.
-
- b. Pixels that would be drawn below the visible region on screen
- are discarded.
-
- c. The cursor's final position is at the same column and row as
- the starting cursor position, i.e. the cursor does not move at
- all.
-
- - Pixels that would be drawn to the right of the visible region on
- screen are discarded.
-
-
-
-The keys for the key-value pairs that must be supported by the
-terminal are listed below:
-
-| Key | Default Value | Description |
-|--------------|---------------|----------------------------------------------|
-| type | "image/rgb" | mime-type describing data field |
-| url | "" | If set, a location containing the media data |
-| width | 1 | Number of Cells or pixels wide to display in |
-| height | 1 | Number of Cells or pixels high to display in |
-| scale | "none" | Scale/zoom option, see below |
-| align | "nw" | Align image to edge option, see below |
-| sourceX | 0 | Media source X position to display |
-| sourceY | 0 | Media source Y position to display |
-| sourceWidth | "auto" | Media width in pixels to display |
-| sourceHeight | "auto" | Media height in pixels to display |
-| scroll | 1 | If 1, scroll the display if needed |
-
-A terminal may support additional keys. If a key is specified but not
-supported by the terminal, then it is ignored without error.
-
-
-
-The "type" value is a mime-type string describing the format of the
-base64-encoded binary data. The terminal must support at mimunum these
-mime-types:
-
-| Type String | Description |
-|---------------|--------------------------------------------------------------|
-| "image/rgb" | Big-endian-encoded 24-bit red, green, blue values |
-| "image/rgba" | Big-endian-encoded 32-bit red, green, blue, alpha values |
-| "image/png" | PNG file data as described by (reference to PNG format) |
-
-A terminal may support additional types. An application can detect
-terminal support for a format by: enabling terminal responses (DECSET
-3001), sending a DMDISPLAY command, and examining the terminal's
-response sequence for success or error.
-
-
-
-The "url" value is a RFC-XXXX defined Universal Resource Located,
-encoded in RFC-XXXX form as a printable ASCII string not containing:
-whitespace, colon (':'), semicolon (';'), or equals ('=').
-
-A terminal is not required to support any URLs.
-
-
-
-The "width" and "height" values can take the following forms:
-
-| Value | Meaning |
-|-------------------------------|---------------------------|
-| N (a positive integer) | Number of Cells |
-| Npx (positive integer + "px") | Number of pixels |
-| N% (positive integer + "%") | Percent of screen width or height |
-| "auto" | Number of pixels as defined by the multimedia data |
-
-
-
-The "scale" value can take the following values:
-
-| Value | Meaning |
-|------------|---------------------------------------------------------------|
-| "none" | No scaling along either axis. |
-| "scale" | Stretch image, preserving aspect ratio, to maximum size in the target area without cropping |
-| "stretch" | Stretch along both axes, distorting aspect ratio, to fill the target area |
-| "crop" | Stretch along both axes, preserving aspect ration, to completely fill the target area, cropping pixels that will not fit |
-
-
-
-The "align" value can take the following values:
-
-| Value | Meaning |
-|------------|-----------------------------------------------------------------|
-| "nw" | Media is placed at the top-left corner (northwest) |
-| "n" | Media is placed on the top and centered horizontally (north) |
-| "ne" | Media is placed at the top-right corner (northest) |
-| "w" | Media is placed on the left and centered vertically (west) |
-| "c" | Media is centered in the target area (center) |
-| "e" | Media is placed on the right and centered vertically (east) |
-| "sw" | Media is placed on the bottom-left corner (southwest) |
-| "s" | Media is placed on the bottom and centered horizontally (south) |
-| "se" | Media is placed on the bottom-right corner (southeast) |
-
-
-
-"sourceX", "sourceY", "sourceWidth", and "sourceHeight" define the
-rectangle of pixels from the media that will be displayed on the
-screen. The ranges for these values is shown below:
-
-| Key | Minimum Value | Maximum Value | Default Value |
-|--------------|---------------|-------------------------------|---------------|
-| sourceX | 0 | Media's full width - 1 | 0 |
-| sourceY | 0 | Media's full height - 1 | 0 |
-| sourceWidth | 1 | Media's full width - sourceX | "auto" |
-| sourceHeight | 1 | Media's full height - sourceY | "auto" |
-
-If any of these values are specified and outside the range, no image
-is displayed, and the cursor does not move. "sourceWidth" and
-"sourceHeight" can be "auto", which means use the maximum available
-width/height (given sourceX/sourceY) from the media's inherent
-dimensions.
-
-
-
-Direct Multimedia - Terminal Responses / Error Handling
--------------------------------------------------------
-
-If DMDISPLAY reponses are enabled, then a terminal will respond to the
-DMDISPLAY display with DMRESP. DMRESP responses must be sent in the
-same sequential order as the DMDISPLAY commands they are responses to:
-the terminal may not re-order responses.
-
-No provision is made for reliable delivery. On unreliable links
-(example: 3-wire RS232), the DMDISPLAY and DMRESP command/response
-sequence may get out of order.
-
-
-
-The format of DMRESP is:
-
-* Pe - a non-negative integer error code.
-
-* The {args} is a set of key-value pairs (each pair separated by
- semicolon (';')).
-
-* A key can be any alpha-numeric ASCII string ('0' - '9', 'A' - 'Z',
- 'a' - 'z').
-
-* A value is any printable ASCII string not containing whitespace,
- colon, or semicolon ('!' - '9', '<' - '~').
-
-
-
-The Pe error codes are defined as:
-
-| Value | Meaning | {args} containts |
-|-------|------------------------------------|--------------------------|
-| 0 | No error occurred, i.e. success | nothing |
-| 1 | Unsupported "type" | "type" value that was incorrect |
-| 2 | Invalid value - no media displayed | "key" that was incorrect |
-| 3 | Unsupported key - media displayed | "key" that unsupported |
-| 4 | Insufficient memory | nothing |
-| 5 | Other error - no media displayed | nothing |
-| 6 | Other - media displayed | nothing |
-| 7 | Conflicting keys - no media displayed | nothing |
-| 8 | RESERVED FOR FUTURE USE | RESERVED FOR FUTURE USE |
-
-Additional Pe error codes may be returned; any Pe value except 0, 3,
-and 6 must mean that the media was not displayed, and the cursor was
-not moved.
-
-If both "type" and "url" are set, no media is diaplyed, the cursor is
-not moved, and the DMRESP error code is 7.
-
-
-
-Direct Multimedia - Examples
-----------------------------
-
-
-
-Cached Multimedia - Summary
----------------------------
-
-Non-text data (multimedia) can be sent to the terminal for later
-display in a rectangular (single-layer) region of text Cells.
-Multimedia data is transmitted to the terminal using the CMCACHE
-command described below, and displayed on screen using the CMDISPLAY
-command. A single CMCACHE command can support many CMDISPLAY
-commands.
-
-Upon display, setting a Cell to multimedia is a destructive operation:
-the Cell's original text is lost. Multimedia pixels will not overlap
-rendered text in the same Cell. To achieve pixels overlaid on text,
-the layers feature can be used.
-
-Setting any part of a multi-Cell Tile to multimedia also "breaks up"
-the Tile into a range of single Cells. In other words, multimedia can
-only be carried by a Cell, not a Tile.
-
-The pixels of a multimedia Cell are assigned to the Cell's foreground;
-multimedia Cells have no background. If a terminal supports the
-layers feature, setting a multimedia Cell's foreground transparency to
-true/enabled causes that Cell to not be displayed at all; setting its
-background transparency to either true/enabled or false/disabled has
-no visible effect.
-
-The pixels of multimedia Cells can come from two sources:
-
- 1. The application can generate pixels and send them to the terminal
- for display at the current cursor position.
-
- 2. The application can specify a source for the multimedia and the
- terminal will generate the pixels for display at the current
- cursor position.
-
-
-
-
-Cached Multimedia - Cache/Memory Management
--------------------------------------------
-
-The terminal manages a cache of multimedia data on behalf of one or
-more applications. Applications request media be stored in the cache,
-and if successful the terminal provides an identification number that
-applications must use to request display from the cache to the screen.
-
-The amount of memory and retention/eviction strategy for the cache is
-wholly managed by the terminal, with the following restrictions:
-
-* The terminal may not remove items from the cache that have any
- portion being actively displayed on the primary or alternate
- screens.
-
-* The terminal must respond to every CMCACHE command with a new unique
- ID.
-
-The scrollback buffer is permitted, and recommended, to contain only a
-few (or zero) multimedia images. Terminals should consider retaining
-only the last 2-5 screens' worth of pixel data in the scrollback
-buffer.
-
-
-
-Cached Multimedia - Required Support For Existing Sequences
------------------------------------------------------------
-
-A terminal with cached multimedia feature must support the following
-defined xterm sequences:
-
-| Sequence | Description |
-|----------------|-----------------------------------------------------|
-| CSI 16 t | Responds with CSI 6 ; cellHeight ; cellWidth t |
-| CSI 18 t | Responds with CSI 8 ; rows ; columns t |
-
-
-
-Cached Multimedia - New Sequences
----------------------------------
-
-A terminal with cached multimedia feature must support the following new
-sequences:
-
-| Sequence | Command | Description |
-|--------------------------------------|-----------|-------------------------|
-| CSI ? 3 0 0 0 h | DECSET 3000 | Enable SCRCHANGE notification |
-| CSI ? 3 0 0 0 l | DECRST 3000 | Disable SCRCHANGE notification |
-| OSC 1 3 4 0 ; F i l e = {args} : {data} BEL | CMCACHE | Display media at (x, y) |
-| OSC 1 3 4 1 ; Pi ; {args} ST | CMDISPLAY | Display media at (x, y) |
-| OSC 1 3 4 2 ; Pi ; Pe ; {args} ST | CMCRESP | Terminal response to CMCACHE |
-| OSC 1 3 4 3 ; Pi ; Pe ; {args} ST | CMDRESP | Terminal response to CMDISPLAY |
-
-
-
-If SCRCHANGE is set/enabled, then the terminal will send the "CSI 6 ;
-cellHeight ; cellWidth t" when the font size has changed, and "CSI 8 ;
-rows ; columns t" when the number of rows/columns on the screen
-changes.
-
-
-
-Cached Multimedia - CMCACHE
----------------------------
-
-For the CMCACHE command:
-
-* The {args} is a set of key-value pairs (each pair separated by
- semicolon (';')), followed by a colon (':'), followed by a base-64
- encoded string ({data}).
-
-* A key can be any alpha-numeric ASCII string ('0' - '9', 'A' - 'Z',
- 'a' - 'z').
-
-* A value is any printable ASCII string not containing whitespace,
- colon, or semicolon ('!' - '9', '<' - '~').
-
-
-
-The keys for the key-value pairs that must be supported by the
-terminal are listed below:
-
-| Key | Default Value | Description |
-|--------------|---------------|----------------------------------------------|
-| type | "image/rgb" | mime-type describing data field |
-| url | "" | If set, a location containing the media data |
-
-
-
-The "type" value is a mime-type string describing the format of the
-base64-encoded binary data. The terminal must support at mimunum these
-mime-types:
-
-| Type String | Description |
-|---------------|--------------------------------------------------------------|
-| "image/rgb" | Big-endian-encoded 24-bit red, green, blue values |
-| "image/rgba" | Big-endian-encoded 32-bit red, green, blue, alpha values |
-| "image/png" | PNG file data as described by (reference to PNG format) |
-
-A terminal may support additional types. An application can detect
-terminal support for a format by: sending a CMCACHE command, and
-examining the terminal's CMCRESP sequence for success or error.
-
-
-
-The "url" value is a RFC-XXXX defined Universal Resource Located,
-encoded in RFC-XXXX form as a printable ASCII string not containing:
-whitespace, colon (':'), semicolon (';'), or equals ('=').
-
-A terminal is not required to support any URLs.
-
-
-
-Cached Multimedia - CMDISPLAY
------------------------------
-
-For the CMDISPLAY command:
-
-* Pi - a non-negative integer media ID that was returned by a CMCRESP
- response to a previous CMCACHE command.
-
-* The {args} is a set of key-value pairs (each pair separated by
- semicolon (';')), followed by a colon (':'), followed by a base-64
- encoded string.
-
-* A key can be any alpha-numeric ASCII string ('0' - '9', 'A' - 'Z',
- 'a' - 'z').
-
-* A value is any printable ASCII string not containing whitespace,
- colon, or semicolon ('!' - '9', '<' - '~').
-
-* Any alpha-numeric key may be specified. A key that is not supported
- by the terminal is ignored without error.
-
-* The multimedia pixels are processed as shown below.
-
- - The pixel are drawn starting at the upper-left corner of the text
- cursor position.
-
- - If scroll is specified as 1 (enabled), then:
-
- a. The screen is scrolled up if the image overflows into the
- bottom text row.
-
- b. The cursor's final position is on the same column as the
- starting cursor position, and on the row immediately below the
- image.
-
- - If scroll is omitted or specified as 0 (disabled), then:
-
- a. The screen is never scrolled.
-
- b. Pixels that would be drawn below the visible region on screen
- are discarded.
-
- c. The cursor's final position is at the same column and row as
- the starting cursor position, i.e. the cursor does not move at
- all.
-
- - Pixels that would be drawn to the right of the visible region on
- screen are discarded.
-
-
-
-The keys for the key-value pairs that must be supported by the
-terminal are listed below:
-
-| Key | Default Value | Description |
-|--------------|---------------|----------------------------------------------|
-| width | 1 | Number of Cells or pixels wide to display in |
-| height | 1 | Number of Cells or pixels high to display in |
-| scale | "none" | Scale/zoom option, see below |
-| align | "nw" | Align image to edge option, see below |
-| sourceX | 0 | Media source X position to display |
-| sourceY | 0 | Media source Y position to display |
-| sourceWidth | "auto" | Media width in pixels to display |
-| sourceHeight | "auto" | Media height in pixels to display |
-| scroll | 1 | If 1, scroll the display if needed |
-
-A terminal may support additional keys. If a key is specified but not
-supported by the terminal, then it is ignored without error.
-
-
-
-The "width" and "height" values can take the following forms:
-
-| Value | Meaning |
-|-------------------------------|---------------------------|
-| N (a positive integer) | Number of Cells |
-| Npx (positive integer + "px") | Number of pixels |
-| N% (positive integer + "%") | Percent of screen width or height |
-| "auto" | Number of pixels as defined by the multimedia data |
-
-
-
-The "scale" value can take the following values:
-
-| Value | Meaning |
-|------------|---------------------------------------------------------------|
-| "none" | No scaling along either axis. |
-| "scale" | Stretch image, preserving aspect ratio, to maximum size in the target area without cropping |
-| "stretch" | Stretch along both axes, distorting aspect ratio, to fill the target area |
-| "crop" | Stretch along both axes, preserving aspect ration, to completely fill the target area, cropping pixels that will not fit |
-
-
-
-The "align" value can take the following values:
-
-| Value | Meaning |
-|------------|-----------------------------------------------------------------|
-| "nw" | Media is placed at the top-left corner (northwest) |
-| "n" | Media is placed on the top and centered horizontally (north) |
-| "ne" | Media is placed at the top-right corner (northest) |
-| "w" | Media is placed on the left and centered vertically (west) |
-| "c" | Media is centered in the target area (center) |
-| "e" | Media is placed on the right and centered vertically (east) |
-| "sw" | Media is placed on the bottom-left corner (southwest) |
-| "s" | Media is placed on the bottom and centered horizontally (south) |
-| "se" | Media is placed on the bottom-right corner (southeast) |
-
-
-
-"sourceX", "sourceY", "sourceWidth", and "sourceHeight" define the
-rectangle of pixels from the media that will be displayed on the
-screen. The ranges for these values is shown below:
-
-| Key | Minimum Value | Maximum Value | Default Value |
-|--------------|---------------|-------------------------------|---------------|
-| sourceX | 0 | Media's full width - 1 | 0 |
-| sourceY | 0 | Media's full height - 1 | 0 |
-| sourceWidth | 1 | Media's full width - sourceX | "auto" |
-| sourceHeight | 1 | Media's full height - sourceY | "auto" |
-
-If any of these values are specified and outside the range, no image
-is displayed, and the cursor does not move. "sourceWidth" and
-"sourceHeight" can be "auto", which means use the maximum available
-width/height (given sourceX/sourceY) from the media's inherent
-dimensions.
-
-
-
-Cached Multimedia - Error Handling
-----------------------------------
-
-A terminal will always respond to the CMCACHE command with CMCRESP,
-and to the CMDISPLAY command with CMDRESP. Responses must be sent in
-the same sequential order as the CMCACHE/CMDISPLAY commands they are
-responses to: the terminal may not re-order responses.
-
-No provision is made for reliable delivery. On unreliable links
-(example: 3-wire RS232), the command/response sequence may get out of
-order.
-
-
-
-Cached Multimedia - Error Handling - CMCRESP
---------------------------------------------
-
-The format of CMCRESP is:
-
-* Pi - a non-negative integer media ID. The terminal will generate a
- new ID for every image successfully loaded into the cache. The
- application must use this ID for CMDISPLAY commands.
-
-* Pe - a non-negative integer error code.
-
-* The {args} is a set of key-value pairs (each pair separated by
- semicolon (';')).
-
-* A key can be any alpha-numeric ASCII string ('0' - '9', 'A' - 'Z',
- 'a' - 'z').
-
-* A value is any printable ASCII string not containing whitespace,
- colon, or semicolon ('!' - '9', '<' - '~').
-
-
-
-The Pe error codes are defined as:
-
-| Value | Meaning | {args} containts |
-|-------|----------------------------------------|--------------------------|
-| 0 | No error occurred, i.e. success | nothing |
-| 1 | Unsupported "type" | "type" value that was incorrect |
-| 2 | Invalid value - no media stored | "key" that was incorrect |
-| 3 | Unsupported key - media stored | "key" that unsupported |
-| 4 | Insufficient memory - no media stored | nothing |
-| 5 | Other error - no media stored | nothing |
-| 6 | Other - media stored | nothing |
-| 7 | Conflicting keys - no media stored | nothing |
-| 8 | RESERVED FOR FUTURE USE | RESERVED FOR FUTURE USE |
-
-Additional Pe error codes may be returned; any Pe value except 0, 3,
-and 6 must mean that the media was not stored in the cache.
-
-If both "type" and "url" are set, no media is diaplyed, the cursor is
-not moved, and the CMCRESP error code is 7.
-
-
-
-Cached Multimedia - Error Handling - CMDRESP
---------------------------------------------
-
-The format of CMDRESP is:
-
-* Pi - a non-negative integer media ID.
-
-* Pe - a non-negative integer error code.
-
-* The {args} is a set of key-value pairs (each pair separated by
- semicolon (';')).
-
-* A key can be any alpha-numeric ASCII string ('0' - '9', 'A' - 'Z',
- 'a' - 'z').
-
-* A value is any printable ASCII string not containing whitespace,
- colon, or semicolon ('!' - '9', '<' - '~').
-
-
-
-The Pe error codes are defined as:
-
-| Value | Meaning | {args} containts |
-|-------|----------------------------------------|--------------------------|
-| 0 | No error occurred, i.e. success | nothing |
-| 1 | RESERVED FOR FUTURE USE | RESERVED FOR FUTURE USE |
-| 2 | Invalid value - no media displayed | "key" that was incorrect |
-| 3 | Unsupported key - media displayed | "key" that unsupported |
-| 4 | Insufficient memory - no media displayed | nothing |
-| 5 | Other error - no media displayed | nothing |
-| 6 | Other - media displayed | nothing |
-| 7 | RESERVED FOR FUTURE USE | RESERVED FOR FUTURE USE |
-| 8 | Media was evicted - no media displayed | nothing |
-
-Additional Pe error codes may be returned; any Pe value except 0, 3,
-and 6 must mean that the media was not displayed.
-
-
-
-Cached Multimedia - Examples
-----------------------------
-
-
-
-
-Layers - Summary
-----------------
-
-Layers introduce the concept of a layer "Z" coordinate to the existing
-rows ("Y") by columns ("X") grid. Put another way, the
-two-dimensional grid of columns-by-rows becomes a three-dimensional
-cube of columns-by-rows-by-layers. For this document, the column,
-row, and layer coordinates are referred to as X, Y, and Z. This
-cartesian coordinate system is right-handed, with the Z axis pointing
-"away" from the user "into" the screen.
-
-An application treats the Z coordinate exactly as it does X and Y
-(rows and columns) coordinates:
-
- * If it attemps to set Z to a value less than 1, then Z is set to 1.
-
- * If it attempts to set Z to a value greater than the number of
- layers, then Z is set to the number of layers.
-
-New sequences are provided to set and query Z, Y, X; to set and query
-the screen cube size; and control visibility of Cells in-front-of
-other Cells.
-
-Operations that can act on more than one Cell are defined such to act
-on all layers simultaneously by default; most of these operations can
-also be set to act only on the current layer.
-
-
-
-Layers - Number of Layers
--------------------------
-
-A terminal is required to provide between 1 and a finite number of
-layers.
-
-The number of layers may be different between the primary and
-alternate screens.
-
-An application may request that the terminal allocate additional
-layers. The terminal is free to honor or ignore such requests as it
-sees fit.
-
-The scrollback buffer is permitted, and recommended, to contain only a
-"flattened" single layer.
-
-
-
-Layers - Terminal State
------------------------
-
-The terminal maintains a complex state at all times. This state
-includes variables such as cursor position, foreground/background
-color, attributes to apply to the next displayed character, and so on.
-The layers feature adds more variables to the state, and these
-variables are required to be stored with DECSC (ESC 7) and restored
-with DECRC (ESC 8). The new variables are listed below:
-
-| Mnemonic | Description | Default value |
-|----------|-----------------------------|----------------|
-| Z | Cursor position Z | 1 |
-| MSL | Manipulate single layer | off / disabled |
-| TFT | Text foreground transparent | false |
-| TBT | Text background transparent | false |
-
-
-
-Layers - Required Support For Existing Sequences
-------------------------------------------------
-
-A terminal with layers feature must support the standard VT100/VT102
-sequences defined in their respective manuals.
-
-
-
-Layers - New Sequences
-----------------------
-
-A terminal with layer feature must support the following new
-sequences:
-
-| Sequence | Command | Description |
-|-------------------|-------------|----------------------------------------|
-| CSI ? z ; y ; x H | CUPZ | Move cursor to (x, y, z) |
-| CSI 2 2 5 ; 1 ; Pa t | SLA | Set layer alpha |
-| CSI ? 3 0 0 2 h | DECSET 3002 | Enable Manupulate Single Layer (MSL) |
-| CSI ? 3 0 0 2 l | DECRST 3002 | Disable Manupulate Single Layer (MSL) |
-| CSI ? l ; h ; w t | RSZCUBE | Resize cube to (layers, height, width) |
-
-Default parameters and ranges are listed below:
-
-| Command | Position / Variable | Default Value | Minumum | Maximum |
-|---------|---------------------|---------------|---------|-----------|
-| CUPZ | 1 / z | 1 | 1 | # layers |
-| CUPZ | 2 / y | 1 | 1 | # rows |
-| CUPZ | 3 / x | 1 | 1 | # columns |
-| SLA | 1 / alpha | 255 | 0 | 255 |
-| RSZCUBE | 1 / l | 1 | 1 | varies |
-| RSZCUBE | 2 / h | 24 | 1 | varies |
-| RSZCUBE | 3 / w | 80 | 1 | varies |
-
-The terminal must also support the following new queries:
-
-| Query | Response | Description |
-|-----------------|-----------------------|--------------------------------|
-| CSI ? 1 0 0 n | CSI ? z ; y ; x n | Report cursor Z, Y, X position |
-| CSI ? 1 8 t | CSI ? 8 ; l ; h ; w t | Report the text area cube layers, height, width |
-
-The terminal must support the following new Set Graphics Rendition
-(SGR) character attributes commands:
-
-| SGR Parameter | Description |
-|---------------|---------------------------------------------|
-| 2 3 0 | Set text foreground color to transparent |
-| 2 3 9 | Set text foreground color to solid (opaque) |
-| 2 4 0 | Set text background color to transparent |
-| 2 4 9 | Set text background color to solid (opaque) |
-
-
-
-Layers - Error Handling
------------------------
-
-No additional error reporting is provided for layer feature.
-
-
-
-Layers - Rendering
-------------------
-
-A terminal with layer feature will display its Cells such that the
-screen will appear as if it was rendered in the manner of the
-pseudo-code below:
-
-```
-for each layer Z, in descending order from maxZ to minZ:
-
- for each row Y, in ascending order from minY to maxY:
-
- for each column X, in ascending order from minX to maxX:
-
- if tile at (X, Y, Z) background color is solid:
- draw rectangle of background color with layer alpha
-
- if tile at (X, Y, Z) foreground color is solid:
- if tile at (X, Y, Z) is glyph:
- draw glyph with foreground color with layer alpha
- else
- draw pixel data of tile as red/green/blue/alpha pixels with
- layer alpha
-
- advance X by tile width
- next column
-
- advance Y by 1
- next row
-
- decrease Z by 1
-next layer
-```
-
-A terminal is free to optimize its rendering as it sees fit, so long
-as the final screen output looks equivalent to the above method.
-
-
-
-Layers - Integration With Existing Sequences
---------------------------------------------
-
-Sequences that insert characters/lines, delete characters/lines, or
-modify larger regions are changed to act upon multiple layers as
-defined below. By default, MSL (Manipulate Single Layer) is
-off/unset, and Z is 1, so if the application never changes MSL or Z
-then these sequences will produce the same visible output as a
-terminal without layer support.
-
-A terminal is not required to support all of these sequences; however,
-for those sequences it does support, if it supports the layers feature
-then the sequences must behave as shown below:
-
-| Sequence | Command | Additional behavior |
-|------------|-------------|------------------------------------------|
-| BS (0x08) | Backspace | Only current layer affected if MSL=on |
-| DEL (0x7F) | Delete | Only current layer affected if MSL=on |
-| IND (0x84) | Index | Only current layer affected if MSL=on |
-| RI (0x8D | Reverse Index | Only current layer affected if MSL=on |
-| ESC # 3 | DECDHL | Cells on all layers always affected |
-| ESC # 4 | DECDHL | Cells on all layers always affected |
-| ESC # 5 | DECSWL | Cells on all layers always affected |
-| ESC # 6 | DECDWL | Cells on all layers always affected |
-| ESC # 8 | DECALN | All layers > 1 cleared; Z, MSL, TFT, TBT reset to default |
-| ESC 7 | DECSC | Also store Z, MSL, TFT, TBT |
-| ESC 8 | DECRC | Also restore Z, MSL, TFT, TBT |
-| ESC c | RIS | All layers > 1 cleared; Z, MSL, TFT, TBT reset to default |
-| CSI @ | ICH | Only current layer affected if MSL=on |
-| CSI J | ED | Only current layer affected if MSL=on |
-| CSI K | EL | Only current layer affected if MSL=on |
-| CSI ? K | DECSEL | Only current layer affected if MSL=on |
-| CSI L | IL | Only current layer affected if MSL=on |
-| CSI M | DL | Only current layer affected if MSL=on |
-| CSI X | ECH | Only current layer affected if MSL=on |
-| CSI M | DL | Only current layer affected if MSL=on |
-| CSI P | DCH | Only current layer affected if MSL=on |
-| CSI R | DECSTBM | Cells on all layers always affected |
-| CSI $ t | DECARA | Only current layer affected if MSL=on |
-| CSI $ v | DECCRA | Only current layer affected if MSL=on |
-| CSI x | DECSACE | Cells on all layers always affected |
-| CSI $ x | DECFRA | Only current layer affected if MSL=on |
-| CSI $ z | DECERA | Only current layer affected if MSL=on |
-
-(( TODO: add many more to the above table... ))
-
-The VT52 sub-mode commands:
-
-| Sequence | Command | Additional behavior |
-|------------|-------------|------------------------------------------|
-| ESC J | ED | Only current layer affected if MSL=on |
-| ESC K | EL | Only current layer affected if MSL=on |
-
-
-
-Layers - Use With Multiplexers
-------------------------------
-
-Layers are inteded to provide a means for multiplexers to pass on the
-job of multimedia support to the "outer" or host terminal. The
-proposed mechanics of that is outlined in the pseudo-code below:
-
-```
-for each inner terminal in descending order from maxZ to minZ:
-
- emit CUPZ(inner terminal Z, inner terminal Y, inner terminal X)
-
- draw inner terminal text with standard VT100/VT102/xterm sequences
-
- for each multimedia sequence emitted by the inner terminal:
- emit CUP(inner terminal Y, inner terminal X)
- emit multimedia sequences to outer terminal
- next multimedia sequence
-
- decrease Z by 1
-next inner terminal
-```
-
-The method above may not be effective for complex multi-terminal
-screen layouts, but is hoped to work well for many simple cases.
-
-
-
-Layers - Examples
------------------
-
-
-
-
-References
-----------
-
-* xterm control sequences:
-
-
-* ECMA-48:
+++ /dev/null
-Terminal Emulator Images Standard - Proposed Design - Simplified
-================================================================
-
-Version: 1
-
-
-
-Purpose
--------
-
-See the [original proposal](images.md) for purpose, design goals, and
-definitions.
-
-This document is an updated proposal to address feedback on the first
-proposal, which included: "overengineered", "hopelessly
-overengineered", and "unnecessarily complex." I perceive this
-feedback as a positive: it is far easier to imagine a feature and
-remove it, than to fail to picture it and need to shoehorn it in
-later.
-
-The original proposal was a superset of every image format referenced,
-and generalized beyond to multimedia. This proposal is sharply
-reduced from that to: "put this pixel rectangle from the image, into
-that cell-based rectangle with specific scaling policy". It is mostly
-a subset of the iTerm2 protocol, with:
-
-* Specifications for what happens to the cursor.
-
-* More precise definitions of the "preserveAspectRatio" equivalent
- options.
-
-* Explicit restriction to a Cell-based target region.
-
-* Definition that pixels not covered by image are set to the current
- background color.
-
-
-
-Tradeoffs
----------
-
-Simplifying the original proposal will significantly reduce
-complexity, but also eliminates features. The major tradeoffs offered
-in this revised proposal are:
-
-1. Elimination of the layers feature, and with it the ability to place
- images behind text. In this proposal, a Cell on the screen will
- show either a (part of a) visible image, or a (part of a) text
- glyph, but never both.
-
-2. Elimination of the "url" option, and with it the ability for an
- application to specify a filename or other method for the terminal
- to find the file data on the local machine. Image data must always
- be passed inline with the sequences.
-
-3. Elimination of response codes, and with it:
-
- - The ability for multiplexers to blindly pass on the sequences to
- their host terminal (because unique IDs are not generated by the
- terminal).
-
- - The ability for applications to reliably detect success or
- failure of image display operations.
-
-4. Elimination of pixel-oriented image placement operations, and with
- it the ability of applications to pass on image calculations to the
- terminal. An application which requires pixel-perfect rendering
- must generate the pixels it needs, aligned such to be displayed at
- the top-left corner of the text Cell rectangle.
-
-
-
-Summary
--------
-
-This revised document proposes two independent new features:
-
-1. A method to transfer image data for immediate display within the
- screen Cell grid ("Direct Images").
-
-2. A method to transfer image data to a terminal-managed cache, and
- later display that data within the screen Cell grid ("Cached
- Images").
-
-The only difference between the first and second feature is the
-presence of an ID key. Direct images do not use an ID key, while
-cached images use a store operation with ID key followed by one or
-more display operations with ID key.
-
-Images are applied to text Cells, and once set handled the same way
-text Cells are handled: erasing a line erases the image Cells on that
-line, inserting a character will shift image Cells on that row over,
-scrolling will shift the image up, and so on. Therefore, terminals
-will need to be prepared for the scenario that every Cell on the
-display is a separate image, with a separate display scaling option
-that will need to be re-applied automatically if font metrics change.
-
-
-
-All Features - Detection
-------------------------
-
-Applications can detect support for these features using Primary
-Device Attributes (DA) and DECID (ESC Z, or 0x9A).
-
-Terminals that support this standard will repond with additional
-parameter(s): "224" for direct images and "225" for cached images. A
-recap of the parameters xterm supports is listed below, with these new
-feature responses included:
-
-| VT220 (and higher) Response | Description |
-|-----------------------------|--------------------------------------------|
-| 1 | 132-columns |
-| 2 | Printer |
-| 3 | ReGIS graphics |
-| 4 | Sixel graphics |
-| 6 | Selective erase |
-| 8 | User-defined keys |
-| 9 | National Replacement Character sets |
-| 1 5 | Technical characters |
-| 1 6 | Locator port |
-| 1 7 | Terminal state interrogation |
-| 1 8 | User windows |
-| 2 1 | Horizontal scrolling |
-| 2 2 | ANSI color, e.g., VT525 |
-| 2 8 | Rectangular editing |
-| 2 9 | ANSI text locator (i.e., DEC Locator mode) |
-| 2 2 4 | Direct Images Version 1 |
-| 2 2 5 | Cached Images Version 1 |
-
-
-
-Direct Images - Summary
------------------------
-
-Non-text data (images) can be sent to the terminal for immediate
-display in a rectangular region of text Cells. Image data is
-transmitted to the terminal using a wire format described later in
-this document.
-
-Setting a Cell to image is a destructive operation: the Cell's
-original text is lost. Similarly, setting a Cell (or multiple Cells
-for fullwidth glyphs or grapheme clusters) to text is a destructive
-operation: the image in the Cell(s) is lost.
-
-Setting any part of a multi-Cell Tile to image also "breaks up" the
-Tile into a range of single Cells. In other words, image data can
-only be carried by a Cell, not a Tile.
-
-
-
-Direct Images - New Sequences
------------------------------
-
-A terminal with direct images feature must support the following new
-sequences:
-
-| Sequence | Description |
-|--------------------------------------|-------------------------|
-| OSC 1 3 3 8 ; F i l e = {args} : {data} BEL | Display image at (x, y) |
-| OSC 1 3 3 8 ; F i l e = {args} : {data} ST | Display image at (x, y) |
-
-
-
-For the OSC 1 3 3 8 sequence:
-
-* The {args} is a set of key-value pairs (each pair separated by
- semicolon (';')), followed by a colon (':'), followed by a base-64
- encoded string ({data}).
-
-* A key can be any alpha-numeric ASCII string ('0' - '9', 'A' - 'Z',
- 'a' - 'z').
-
-* A value is any printable ASCII string not containing whitespace,
- colon, or semicolon ('!' - '9', '<' - '~').
-
-* Any alpha-numeric key may be specified. A key that is not supported
- by the terminal is ignored without error.
-
-* The image is processed as shown below:
-
- - The pixels are drawn starting at the upper-left corner of the text
- cursor position.
-
- - All pixels in the target Cell rectangle that are not covered by
- the image itself are set the current background color (like
- sixel raster attributes).
-
- - If scroll is specified as 1 (enabled), then:
-
- a. The screen is scrolled up if the image overflows into the
- bottom text row.
-
- b. The cursor's final position is on the same column as the
- starting cursor position, and on the row immediately below the
- image.
-
- - If scroll is omitted or specified as 0 (disabled), then:
-
- a. The screen is never scrolled.
-
- b. Pixels that would be drawn below the visible region on screen
- are discarded.
-
- c. The cursor's final position is at the same column and row as
- the starting cursor position, i.e. the cursor does not move at
- all.
-
- - Pixels that would be drawn to the right of the visible region on
- screen are discarded.
-
- - If scale is "none", then pixels that would be drawn outside the
- target Cell rectangle are discarded.
-
-
-
-The keys for the key-value pairs that must be supported by the
-terminal are listed below:
-
-| Key | Default Value | Description |
-|--------------|---------------|---------------------------------------|
-| type | "image/rgb" | mime-type describing data field |
-| width | 1 | Number of Cell columns to display in |
-| height | 1 | Number of Cells rows to display in |
-| scale | "none" | Scale/zoom option, see below |
-| sourceX | 0 | Media source X position to display |
-| sourceY | 0 | Media source Y position to display |
-| sourceWidth | "auto" | Media width in pixels to display |
-| sourceHeight | "auto" | Media height in pixels to display |
-| scroll | 0 | If 0, scroll the display if needed |
-
-A terminal may support additional keys. If a key is specified but not
-supported by the terminal, then it is ignored without error.
-
-
-
-The "type" value is a mime-type string describing the format of the
-base64-encoded binary data. The terminal must support at minimum these
-mime-types:
-
-| Type String | Description |
-|---------------|--------------------------------------------------------------|
-| "image/rgb" | Big-endian-encoded 24-bit red, green, blue values |
-| "image/rgba" | Big-endian-encoded 32-bit red, green, blue, alpha values |
-| "image/png" | PNG file data as described by (reference to PNG format) |
-
-A terminal may support additional types. An application can detect
-terminal support for a format by:
-
- 1. Attempt to draw image, with "scroll" set to 1.
-
- 2. Check cursor position DSR 6.
-
- 3. If cursor has moved, then the terminal supports this image type.
-
-
-
-The "width" and "height" values are positive integers describing the
-number of Cells the image will be placed in.
-
-
-
-The "scale" value can take the following values:
-
-| Value | Meaning |
-|------------|---------------------------------------------------------------|
-| "none" | No scaling along either axis. |
-| "scale" | Stretch image, preserving aspect ratio, to maximum size in the target area without cropping |
-| "stretch" | Stretch along both axes, distorting aspect ratio, to fill the target area |
-| "crop" | Stretch along both axes, preserving aspect ration, to completely fill the target area, cropping pixels that will not fit |
-
-
-
-"sourceX", "sourceY", "sourceWidth", and "sourceHeight" define the
-rectangle of pixels from the media that will be displayed on the
-screen. The ranges for these values is shown below:
-
-| Key | Minimum Value | Maximum Value | Default Value |
-|--------------|---------------|-------------------------------|---------------|
-| sourceX | 0 | Media's full width - 1 | 0 |
-| sourceY | 0 | Media's full height - 1 | 0 |
-| sourceWidth | 1 | Media's full width - sourceX | "auto" |
-| sourceHeight | 1 | Media's full height - sourceY | "auto" |
-
-If any of these values are specified and outside the range, no image
-is displayed, and the cursor does not move. "sourceWidth" and
-"sourceHeight" can be "auto", which means use the maximum available
-width/height (given sourceX/sourceY) from the media's inherent
-dimensions.
-
-
-
-Cached Images - Summary
------------------------
-
-Non-text data (image) can be sent to the terminal for later display in
-a rectangular region of text Cells. Image data is transmitted to the
-terminal using the CSTORE command described below, and displayed on
-screen using the CDISPLAY command. A single CSTORE command can
-support many CDISPLAY commands.
-
-Upon display, setting a Cell to image is a destructive operation: the
-Cell's original text is lost. Similarly, setting a Cell (or multiple
-Cells for fullwidth glyphs or grapheme clusters) to text is a
-destructive operation: the image in the Cell(s) is lost.
-
-Setting any part of a multi-Cell Tile to image also "breaks up" the
-Tile into a range of single Cells. In other words, image data can
-only be carried by a Cell, not a Tile.
-
-
-
-Cached Images - Cache/Memory Management
----------------------------------------
-
-The terminal manages a cache of multimedia data on behalf of the
-application. The application requests media be stored in the cache
-and provides an ID. This ID is later used to request display on the
-screen.
-
-The amount of memory and retention/eviction strategy for the cache is
-wholly managed by the terminal, with the following restrictions:
-
-* The terminal may not remove items from the cache that have any
- portion being actively displayed on the primary or alternate
- screens.
-
-The scrollback buffer is permitted, and recommended, to contain only a
-few (or zero) multimedia images. Terminals should consider retaining
-only the last 2-5 screens' worth of pixel data in the scrollback
-buffer.
-
-Applications have no control over when images are removed from the
-cache, and no provision is made to generate/ensure unique IDs.
-
-A terminal multiplexer that passes all CSTORE/CDISPLAY commands to the
-host terminal will need to parse the CSTORE and CDISPLAY sequences for
-the "id" field and rewrite it to be unique for all of its inner
-terminals.
-
-
-
-Cached Images - New Sequences
------------------------------
-
-A terminal with cached images feature must support the following new
-sequences:
-
-| Sequence | Command | Description |
-|--------------------------------------|-----------|--------------------------|
-| OSC 1 3 4 0 ; F i l e = {args} : {data} BEL | CSTORE | Store image in cache |
-| OSC 1 3 4 0 ; F i l e = {args} : {data} ST | CSTORE | Store image in cache |
-| OSC 1 3 4 1 ; Pi ; {args} BEL | CDISPLAY | Display image at (x, y) |
-| OSC 1 3 4 1 ; Pi ; {args} ST | CDISPLAY | Display image at (x, y) |
-
-
-
-Cached Images - CSTORE
-----------------------
-
-For the CSTORE command:
-
-* The {args} is a set of key-value pairs (each pair separated by
- semicolon (';')), followed by a colon (':'), followed by a base-64
- encoded string ({data}).
-
-* A key can be any alpha-numeric ASCII string ('0' - '9', 'A' - 'Z',
- 'a' - 'z').
-
-* A value is any printable ASCII string not containing whitespace,
- colon, or semicolon ('!' - '9', '<' - '~').
-
-
-
-The keys for the key-value pairs that must be supported by the
-terminal are listed below:
-
-| Key | Default Value | Description |
-|--------------|---------------|----------------------------------------------|
-| id | 0 | ID to refer to the image |
-| type | "image/rgb" | mime-type describing data field |
-
-
-
-The "id" value is a non-negative integer between 0 and 999999.
-
-
-
-The "type" value is a mime-type string describing the format of the
-base64-encoded binary data. The terminal must support at mimunum these
-mime-types:
-
-| Type String | Description |
-|---------------|--------------------------------------------------------------|
-| "image/rgb" | Big-endian-encoded 24-bit red, green, blue values |
-| "image/rgba" | Big-endian-encoded 32-bit red, green, blue, alpha values |
-| "image/png" | PNG file data as described by (reference to PNG format) |
-
-A terminal may support additional types. An application can detect
-terminal support for a format by:
-
- 1. Store image in cache.
-
- 2. Attempt to draw image, with "scroll" set to 1.
-
- 3. Check cursor position DSR 6.
-
- 4. If cursor has moved, then the terminal supports this image type.
-
-
-
-Cached Images - CDISPLAY
-------------------------
-
-For the CDISPLAY command:
-
-* Pi - a non-negative integer ID that was used in a previous CSTORE
- command.
-
-* The {args} is a set of key-value pairs (each pair separated by
- semicolon (';')), followed by a colon (':'), followed by a base-64
- encoded string.
-
-* A key can be any alpha-numeric ASCII string ('0' - '9', 'A' - 'Z',
- 'a' - 'z').
-
-* A value is any printable ASCII string not containing whitespace,
- colon, or semicolon ('!' - '9', '<' - '~').
-
-* Any alpha-numeric key may be specified. A key that is not supported
- by the terminal is ignored without error.
-
-* The image pixels are processed as shown below.
-
- - The pixel are drawn starting at the upper-left corner of the text
- cursor position.
-
- - If scroll is specified as 1 (enabled), then:
-
- a. The screen is scrolled up if the image overflows into the
- bottom text row.
-
- b. The cursor's final position is on the same column as the
- starting cursor position, and on the row immediately below the
- image.
-
- - If scroll is omitted or specified as 0 (disabled), then:
-
- a. The screen is never scrolled.
-
- b. Pixels that would be drawn below the visible region on screen
- are discarded.
-
- c. The cursor's final position is at the same column and row as
- the starting cursor position, i.e. the cursor does not move at
- all.
-
- - Pixels that would be drawn to the right of the visible region on
- screen are discarded.
-
-
-
-The keys for the key-value pairs that must be supported by the
-terminal are listed below:
-
-| Key | Default Value | Description |
-|--------------|---------------|---------------------------------------|
-| id | 0 | ID to refer to the image |
-| width | 1 | Number of Cell columns to display in |
-| height | 1 | Number of Cells rows to display in |
-| scale | "none" | Scale/zoom option, see below |
-| sourceX | 0 | Media source X position to display |
-| sourceY | 0 | Media source Y position to display |
-| sourceWidth | "auto" | Media width in pixels to display |
-| sourceHeight | "auto" | Media height in pixels to display |
-| scroll | 0 | If 1, scroll the display if needed |
-
-A terminal may support additional keys. If a key is specified but not
-supported by the terminal, then it is ignored without error.
-
-
-
-The "width" and "height" values are positive integers describing the
-number of Cells the image will be placed in.
-
-
-
-The "scale" value can take the following values:
-
-| Value | Meaning |
-|------------|---------------------------------------------------------------|
-| "none" | No scaling along either axis. |
-| "scale" | Stretch image, preserving aspect ratio, to maximum size in the target area without cropping |
-| "stretch" | Stretch along both axes, distorting aspect ratio, to fill the target area |
-| "crop" | Stretch along both axes, preserving aspect ration, to completely fill the target area, cropping pixels that will not fit |
-
-
-
-"sourceX", "sourceY", "sourceWidth", and "sourceHeight" define the
-rectangle of pixels from the media that will be displayed on the
-screen. The ranges for these values is shown below:
-
-| Key | Minimum Value | Maximum Value | Default Value |
-|--------------|---------------|-------------------------------|---------------|
-| sourceX | 0 | Media's full width - 1 | 0 |
-| sourceY | 0 | Media's full height - 1 | 0 |
-| sourceWidth | 1 | Media's full width - sourceX | "auto" |
-| sourceHeight | 1 | Media's full height - sourceY | "auto" |
-
-If any of these values are specified and outside the range, no image
-is displayed, and the cursor does not move. "sourceWidth" and
-"sourceHeight" can be "auto", which means use the maximum available
-width/height (given sourceX/sourceY) from the media's inherent
-dimensions.
-
-
-
-Miscellaneous Items
--------------------
-
-"image/rgb" and "image/rgba" also need width/height fields. Propose
-to specify them as 16-bit unsigned ints, followed by 24-bit or 32-bit
-data. If data is short, then the rest of the image is assumed to be
-current background color (like sixel raster attributes).
+++ /dev/null
-import jexer.TApplication;
-
-public class HelloWorld {
-
- public static void main(String [] args) throws Exception {
- TApplication app = new TApplication(TApplication.BackendType.XTERM);
- app.addToolMenu();
- app.addFileMenu();
- app.addWindowMenu();
- app.run();
- }
-}
+++ /dev/null
-import java.awt.image.BufferedImage;
-import java.io.File;
-import java.io.IOException;
-import java.util.ArrayList;
-import java.util.List;
-import javax.imageio.ImageIO;
-
-import jexer.TAction;
-import jexer.TApplication;
-import jexer.TDesktop;
-import jexer.TDirectoryList;
-import jexer.TImage;
-import jexer.backend.SwingTerminal;
-import jexer.bits.CellAttributes;
-import jexer.bits.GraphicsChars;
-import jexer.event.TKeypressEvent;
-import jexer.event.TResizeEvent;
-import jexer.menu.TMenu;
-import jexer.ttree.TDirectoryTreeItem;
-import jexer.ttree.TTreeItem;
-import jexer.ttree.TTreeViewWidget;
-import static jexer.TKeypress.*;
-
-/**
- * Implements a simple image thumbnail file viewer. Much of this code was
- * stripped down from TFileOpenBox.
- */
-public class JexerImageViewer extends TApplication {
-
- /**
- * Main entry point.
- */
- public static void main(String [] args) throws Exception {
- JexerImageViewer app = new JexerImageViewer();
- (new Thread(app)).start();
- }
-
- /**
- * Public constructor chooses the ECMA-48 / Xterm backend.
- */
- public JexerImageViewer() throws Exception {
- super(BackendType.XTERM);
-
- // The stock tool menu has items for redrawing the screen, opening
- // images, and (when using the Swing backend) setting the font.
- addToolMenu();
-
- // We will have one menu containing a mix of new and stock commands
- TMenu fileMenu = addMenu("&File");
-
- // Stock commands: a new shell, exit program.
- fileMenu.addDefaultItem(TMenu.MID_SHELL);
- fileMenu.addSeparator();
- fileMenu.addDefaultItem(TMenu.MID_EXIT);
-
- // Filter the files list to support image suffixes only.
- List<String> filters = new ArrayList<String>();
- filters.add("^.*\\.[Jj][Pp][Gg]$");
- filters.add("^.*\\.[Jj][Pp][Ee][Gg]$");
- filters.add("^.*\\.[Pp][Nn][Gg]$");
- filters.add("^.*\\.[Gg][Ii][Ff]$");
- filters.add("^.*\\.[Bb][Mm][Pp]$");
- setDesktop(new ImageViewerDesktop(this, ".", filters));
- }
-
-}
-
-/**
- * The desktop contains a tree view on the left, list of files on the top
- * right, and image view on the bottom right.
- */
-class ImageViewerDesktop extends TDesktop {
-
- /**
- * The left-side tree view pane.
- */
- private TTreeViewWidget treeView;
-
- /**
- * The data behind treeView.
- */
- private TDirectoryTreeItem treeViewRoot;
-
- /**
- * The top-right-side directory list pane.
- */
- private TDirectoryList directoryList;
-
- /**
- * The bottom-right-side image pane.
- */
- private TImage imageWidget;
-
- /**
- * Public constructor.
- *
- * @param application the TApplication that manages this window
- * @param path path of selected file
- * @param filters a list of strings that files must match to be displayed
- * @throws IOException of a java.io operation throws
- */
- public ImageViewerDesktop(final TApplication application, final String path,
- final List<String> filters) throws IOException {
-
- super(application);
- setActive(true);
-
- // Add directory treeView
- treeView = addTreeViewWidget(0, 0, getWidth() / 2, getHeight(),
- new TAction() {
- public void DO() {
- TTreeItem item = treeView.getSelected();
- File selectedDir = ((TDirectoryTreeItem) item).getFile();
- try {
- directoryList.setPath(selectedDir.getCanonicalPath());
- if (directoryList.getList().size() > 0) {
- setThumbnail(directoryList.getPath());
- } else {
- if (imageWidget != null) {
- getChildren().remove(imageWidget);
- }
- imageWidget = null;
- }
- activate(treeView);
- } catch (IOException e) {
- // If the backend is Swing, we can emit the stack
- // trace to stderr. Otherwise, just squash it.
- if (getScreen() instanceof SwingTerminal) {
- e.printStackTrace();
- }
- }
- }
- }
- );
- treeViewRoot = new TDirectoryTreeItem(treeView, path, true);
-
- // Add directory files list
- directoryList = addDirectoryList(path, getWidth() / 2 + 1, 0,
- getWidth() / 2 - 1, getHeight() / 2,
-
- new TAction() {
- public void DO() {
- setThumbnail(directoryList.getPath());
- }
- },
- new TAction() {
-
- public void DO() {
- setThumbnail(directoryList.getPath());
- }
- },
- filters);
-
- if (directoryList.getList().size() > 0) {
- activate(directoryList);
- setThumbnail(directoryList.getPath());
- } else {
- activate(treeView);
- }
- }
-
- /**
- * Handle window/screen resize events.
- *
- * @param event resize event
- */
- @Override
- public void onResize(final TResizeEvent event) {
-
- // Resize the tree and list
- treeView.setY(1);
- treeView.setWidth(getWidth() / 2);
- treeView.setHeight(getHeight() - 1);
- treeView.onResize(new TResizeEvent(TResizeEvent.Type.WIDGET,
- treeView.getWidth(),
- treeView.getHeight()));
- treeView.getTreeView().onResize(new TResizeEvent(TResizeEvent.Type.WIDGET,
- treeView.getWidth() - 1,
- treeView.getHeight() - 1));
- directoryList.setX(getWidth() / 2 + 1);
- directoryList.setY(1);
- directoryList.setWidth(getWidth() / 2 - 1);
- directoryList.setHeight(getHeight() / 2 - 1);
- directoryList.onResize(new TResizeEvent(TResizeEvent.Type.WIDGET,
- directoryList.getWidth(),
- directoryList.getHeight()));
-
- // Recreate the image
- if (imageWidget != null) {
- getChildren().remove(imageWidget);
- }
- imageWidget = null;
- if (directoryList.getList().size() > 0) {
- activate(directoryList);
- setThumbnail(directoryList.getPath());
- } else {
- activate(treeView);
- }
- }
-
- /**
- * Handle keystrokes.
- *
- * @param keypress keystroke event
- */
- @Override
- public void onKeypress(final TKeypressEvent keypress) {
-
- if (treeView.isActive() || directoryList.isActive()) {
- if ((keypress.equals(kbEnter))
- || (keypress.equals(kbUp))
- || (keypress.equals(kbDown))
- || (keypress.equals(kbPgUp))
- || (keypress.equals(kbPgDn))
- || (keypress.equals(kbHome))
- || (keypress.equals(kbEnd))
- ) {
- // Tree view will be changing, update the directory list.
- super.onKeypress(keypress);
-
- // This is the same action as treeView's enter.
- TTreeItem item = treeView.getSelected();
- File selectedDir = ((TDirectoryTreeItem) item).getFile();
- try {
- if (treeView.isActive()) {
- directoryList.setPath(selectedDir.getCanonicalPath());
- }
- if (directoryList.getList().size() > 0) {
- activate(directoryList);
- setThumbnail(directoryList.getPath());
- } else {
- if (imageWidget != null) {
- getChildren().remove(imageWidget);
- }
- imageWidget = null;
- activate(treeView);
- }
- } catch (IOException e) {
- // If the backend is Swing, we can emit the stack trace
- // to stderr. Otherwise, just squash it.
- if (getScreen() instanceof SwingTerminal) {
- e.printStackTrace();
- }
- }
- return;
- }
- }
-
- // Pass to my parent
- super.onKeypress(keypress);
- }
-
- /**
- * Draw me on screen.
- */
- @Override
- public void draw() {
- CellAttributes background = getTheme().getColor("tdesktop.background");
- putAll(' ', background);
-
- vLineXY(getWidth() / 2, 0, getHeight(),
- GraphicsChars.WINDOW_SIDE, getBackground());
-
- hLineXY(getWidth() / 2, getHeight() / 2, (getWidth() + 1) / 2,
- GraphicsChars.WINDOW_TOP, getBackground());
-
- putCharXY(getWidth() / 2, getHeight() / 2,
- GraphicsChars.WINDOW_LEFT_TEE, getBackground());
- }
-
- /**
- * Set the image thumbnail.
- *
- * @param file the image file
- */
- private void setThumbnail(final File file) {
- if (file == null) {
- return;
- }
- if (!file.exists() || !file.isFile()) {
- return;
- }
-
- BufferedImage image = null;
- try {
- image = ImageIO.read(file);
- } catch (IOException e) {
- // If the backend is Swing, we can emit the stack trace to
- // stderr. Otherwise, just squash it.
- if (getScreen() instanceof SwingTerminal) {
- e.printStackTrace();
- }
- return;
- }
-
- if (imageWidget != null) {
- getChildren().remove(imageWidget);
- }
- int width = getWidth() / 2 - 1;
- int height = getHeight() / 2 - 1;
-
- imageWidget = new TImage(this, getWidth() - width,
- getHeight() - height, width, height, image, 0, 0, null);
-
- // Resize the image to fit within the pane.
- imageWidget.setScaleType(TImage.Scale.SCALE);
-
- imageWidget.setActive(false);
- activate(directoryList);
- }
-
-}
+++ /dev/null
-import jexer.TApplication;
-import jexer.TTerminalWindow;
-import jexer.TWindow;
-import jexer.event.TKeypressEvent;
-import jexer.event.TMenuEvent;
-import jexer.event.TMouseEvent;
-import jexer.event.TResizeEvent;
-import jexer.menu.TMenu;
-
-/**
- * Implements a simple tiling window manager. A root non-moveable
- * non-resizable terminal window is created first, which can be split
- * horizontally or vertically. Each new window retains a reference to its
- * "parent", and upon closing resizes that parent back to its original size.
- *
- * This example shows what can be done with minimal changes to stock Jexer
- * widgets. You will quickly see that closing a "parent" tile does not cause
- * the "child" tile to resize. You could make a real subclass of
- * TTerminalWindow that has extra fields and/or communicates more with
- * JexerTilingWindowManager to get full coverage of tile creation,
- * destruction, placement, movement, and so on.
- */
-public class JexerTilingWindowManager extends TApplication {
-
- /**
- * Menu item: split the terminal vertically.
- */
- private static final int MENU_SPLIT_VERTICAL = 2000;
-
- /**
- * Menu item: split the terminal horizontally.
- */
- private static final int MENU_SPLIT_HORIZONTAL = 2001;
-
- /**
- * Main entry point.
- */
- public static void main(String [] args) throws Exception {
- // For this application, we must use ptypipe so that the tile shells
- // can be aware of their size.
- System.setProperty("jexer.TTerminal.ptypipe", "true");
-
- JexerTilingWindowManager jtwm = new JexerTilingWindowManager();
- (new Thread(jtwm)).start();
- }
-
- /**
- * Public constructor chooses the ECMA-48 / Xterm backend.
- */
- public JexerTilingWindowManager() throws Exception {
- super(BackendType.XTERM);
-
- // The stock tool menu has items for redrawing the screen, opening
- // images, and (when using the Swing backend) setting the font.
- addToolMenu();
-
- // We will have one menu containing a mix of new and stock commands
- TMenu tileMenu = addMenu("&Tile");
-
- // New commands for this example: split vertical and horizontal.
- tileMenu.addItem(MENU_SPLIT_VERTICAL, "&Vertical Split");
- tileMenu.addItem(MENU_SPLIT_HORIZONTAL, "&Horizontal Split");
-
- // Stock commands: a new shell with resizable window, previous, next,
- // close, and exit program.
- tileMenu.addItem(TMenu.MID_SHELL, "&Floating");
- tileMenu.addSeparator();
- tileMenu.addDefaultItem(TMenu.MID_WINDOW_PREVIOUS);
- tileMenu.addDefaultItem(TMenu.MID_WINDOW_NEXT);
- tileMenu.addDefaultItem(TMenu.MID_WINDOW_CLOSE);
- tileMenu.addSeparator();
- tileMenu.addDefaultItem(TMenu.MID_EXIT);
-
- // Spin up the root tile
- TTerminalWindow rootTile = makeTile(0, 0, getScreen().getWidth(),
- getDesktopBottom() - 1, null);
-
- // Let's add some bling! Enable focus-follows-mouse.
- setFocusFollowsMouse(true);
- }
-
- /**
- * Process menu events.
- */
- @Override
- protected boolean onMenu(TMenuEvent event) {
- if (event.getId() == MENU_SPLIT_VERTICAL) {
- splitVertical();
- return true;
- }
- if (event.getId() == MENU_SPLIT_HORIZONTAL) {
- splitHorizontal();
- return true;
- }
-
- return super.onMenu(event);
- }
-
- /**
- * Perform the vertical split.
- */
- private void splitVertical() {
- TWindow window = getActiveWindow();
- if (!(window instanceof TTerminalWindow)) {
- return;
- }
-
- TTerminalWindow tile = (TTerminalWindow) window;
- // Give the extra column to the new tile.
- int newWidth = (tile.getWidth() + 1) / 2;
- int newY = tile.getY() - 1;
- int newX = tile.getX() + tile.getWidth() - newWidth;
- makeTile(newX, newY, newWidth, tile.getHeight(), tile);
- tile.setWidth(tile.getWidth() - newWidth);
- tile.onResize(new TResizeEvent(TResizeEvent.Type.WIDGET,
- tile.getWidth(), tile.getHeight()));
- }
-
- /**
- * Perform the horizontal split.
- */
- private void splitHorizontal() {
- TWindow window = getActiveWindow();
- if (!(window instanceof TTerminalWindow)) {
- return;
- }
-
- TTerminalWindow tile = (TTerminalWindow) window;
- // Give the extra row to the new tile.
- int newHeight = (tile.getHeight() + 1) / 2;
- int newY = tile.getY() - 1 + tile.getHeight() - newHeight;
- int newX = tile.getX();
- makeTile(newX, newY, tile.getWidth(), newHeight, tile);
- tile.setHeight(tile.getHeight() - newHeight);
- tile.onResize(new TResizeEvent(TResizeEvent.Type.WIDGET,
- tile.getWidth(), tile.getHeight()));
- }
-
- /**
- * Create a non-resizable non-movable terminal window.
- *
- * @param x the column number to place the top-left corner at. 0 is the
- * left-most column.
- * @param y the row number to place the top-left corner at. 0 is the
- * top-most column.
- * @param width the width of the window
- * @param height the height of the window
- * @param otherTile the other tile to resize when this window closes
- */
- private TTerminalWindow makeTile(int x, int y, int width, int height,
- final TTerminalWindow otherTile) {
-
- // We pass flags to disable the zoom (maximize) button, disable
- // "smart" window placement, and set the specific location.
- TTerminalWindow tile = new TTerminalWindow(this, x, y,
- TWindow.NOZOOMBOX | TWindow.ABSOLUTEXY,
- new String[] { "/bin/bash", "--login" }, true) {
-
- /**
- * When this terminal closes, if otherTile is defined then resize
- * it to overcover me.
- */
- @Override
- public void onClose() {
- super.onClose();
-
- if (otherTile != null) {
- if (otherTile.getX() != getX()) {
- // Undo the vertical split
- otherTile.setX(Math.min(otherTile.getX(), getX()));
- otherTile.setWidth(otherTile.getWidth() + getWidth());
- }
- if (otherTile.getY() != getY()) {
- otherTile.setY(Math.min(otherTile.getY(), getY()));
- otherTile.setHeight(otherTile.getHeight() + getHeight());
- }
- otherTile.onResize(new TResizeEvent(TResizeEvent.Type.WIDGET,
- otherTile.getWidth(), otherTile.getHeight()));
- }
- }
-
- /**
- * Prevent the user from resizing or moving this window.
- */
- @Override
- public void onMouseDown(final TMouseEvent mouse) {
- super.onMouseDown(mouse);
- stopMovements();
- }
-
- /**
- * Prevent the user from resizing or moving this window.
- */
- @Override
- public void onKeypress(final TKeypressEvent keypress) {
- super.onKeypress(keypress);
- stopMovements();
- }
-
- /**
- * Permit the user to use all of the menu items.
- */
- @Override
- public void onIdle() {
- super.onIdle();
- removeShortcutKeypress(jexer.TKeypress.kbAltT);
- removeShortcutKeypress(jexer.TKeypress.kbF6);
- }
-
- };
-
- // The initial window size was stock VT100 80x24. Change that now,
- // and then call onResize() to notify ptypipe to set the shell's
- // window size.
- tile.setWidth(width);
- tile.setHeight(height);
- tile.onResize(new TResizeEvent(TResizeEvent.Type.WIDGET,
- tile.getWidth(), tile.getHeight()));
-
- return tile;
- }
-
-}
+++ /dev/null
-import jexer.TAction;
-import jexer.TApplication;
-import jexer.TDesktop;
-import jexer.TTerminalWidget;
-import jexer.TSplitPane;
-import jexer.TWidget;
-import jexer.event.TMenuEvent;
-import jexer.menu.TMenu;
-
-/**
- * Implements a simple tiling window manager. A terminal widget is added to
- * the desktop, which can be split horizontally or vertically. A close
- * action is provided to each window to remove the split when its shell
- * exits.
- *
- * This example shows what can be done with minimal changes to stock Jexer
- * widgets.
- */
-public class JexerTilingWindowManager2 extends TApplication {
-
- /**
- * Menu item: split the terminal vertically.
- */
- private static final int MENU_SPLIT_VERTICAL = 2000;
-
- /**
- * Menu item: split the terminal horizontally.
- */
- private static final int MENU_SPLIT_HORIZONTAL = 2001;
- /**
- * Menu item: recreate the root terminal.
- */
- private static final int MENU_RESPAWN_ROOT = 2002;
-
- /**
- * Handle to the root widget.
- */
- private TWidget root = null;
-
- /**
- * Main entry point.
- */
- public static void main(String [] args) throws Exception {
- // For this application, we must use ptypipe so that the terminal
- // shells can be aware of their size.
- System.setProperty("jexer.TTerminal.ptypipe", "true");
-
- // Let's also suppress the status line.
- System.setProperty("jexer.hideStatusBar", "true");
-
- JexerTilingWindowManager2 jtwm = new JexerTilingWindowManager2();
- (new Thread(jtwm)).start();
- }
-
- /**
- * Public constructor chooses the ECMA-48 / Xterm backend.
- */
- public JexerTilingWindowManager2() throws Exception {
- super(BackendType.XTERM);
-
- // The stock tool menu has items for redrawing the screen, opening
- // images, and (when using the Swing backend) setting the font.
- addToolMenu();
-
- // We will have one menu containing a mix of new and stock commands
- TMenu tileMenu = addMenu("&Tile");
-
- // New commands for this example: split vertical and horizontal.
- tileMenu.addItem(MENU_SPLIT_VERTICAL, "&Vertical Split");
- tileMenu.addItem(MENU_SPLIT_HORIZONTAL, "&Horizontal Split");
- tileMenu.addItem(MENU_RESPAWN_ROOT, "&Respawn Root Terminal");
-
- // Stock commands: a new shell with resizable window, and exit
- // program.
- tileMenu.addSeparator();
- tileMenu.addItem(TMenu.MID_SHELL, "&New Windowed Terminal");
- tileMenu.addSeparator();
- tileMenu.addDefaultItem(TMenu.MID_EXIT);
-
- // TTerminalWidget can request the text-block mouse pointer be
- // suppressed, but the default TDesktop will ignore it. Let's set a
- // new TDesktop to pass that mouse pointer visibility option to
- // TApplication.
- setDesktop(new TDesktop(this) {
- @Override
- public boolean hasHiddenMouse() {
- TWidget active = getActiveChild();
- if (active instanceof TTerminalWidget) {
- return ((TTerminalWidget) active).hasHiddenMouse();
- }
- return false;
- }
- });
-
- // Spin up the root terminal
- createRootTerminal();
- }
-
- /**
- * Process menu events.
- */
- @Override
- protected boolean onMenu(TMenuEvent event) {
- TWidget active = getDesktop().getActiveChild();
- TSplitPane split = null;
-
- switch (event.getId()) {
- case MENU_RESPAWN_ROOT:
- assert (root == null);
- createRootTerminal();
- return true;
-
- case MENU_SPLIT_VERTICAL:
- if (root == null) {
- assert (getDesktop().getActiveChild() == null);
- createRootTerminal();
- return true;
- }
- split = active.splitVertical(false, createTerminal());
- if (active == root) {
- root = split;
- }
- return true;
-
- case MENU_SPLIT_HORIZONTAL:
- if (root == null) {
- assert (getDesktop().getActiveChild() == null);
- createRootTerminal();
- return true;
- }
- split = active.splitHorizontal(false, createTerminal());
- if (active == root) {
- root = split;
- }
- return true;
-
- default:
- return super.onMenu(event);
- }
-
- }
-
- /**
- * Create the root terminal.
- */
- private void createRootTerminal() {
- assert (root == null);
- disableMenuItem(MENU_RESPAWN_ROOT);
- root = createTerminal();
- }
-
- /**
- * Create a new terminal.
- *
- * @return the new terminal
- */
- private TWidget createTerminal() {
- return new TTerminalWidget(getDesktop(), 0, 0,
- getDesktop().getWidth(), getDesktop().getHeight(),
- new TAction() {
- public void DO() {
- if (source.getParent() instanceof TSplitPane) {
- ((TSplitPane) source.getParent()).removeSplit(source,
- true);
- } else {
- source.getApplication().enableMenuItem(
- MENU_RESPAWN_ROOT);
- source.remove();
- root = null;
- }
- }
- });
- }
-
-}
+++ /dev/null
-import jexer.TApplication;
-
-public class MyApplication extends TApplication {
-
- public MyApplication() throws Exception {
- super(BackendType.XTERM);
-
- // Create standard menus for Tool, File, and Window.
- addToolMenu();
- addFileMenu();
- addWindowMenu();
- }
-
- public static void main(String [] args) throws Exception {
- MyApplication app = new MyApplication();
- app.run();
- }
-}
+++ /dev/null
-<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
- <modelVersion>4.0.0</modelVersion>
- <groupId>com.gitlab.klamonte</groupId>
- <artifactId>jexer</artifactId>
- <packaging>jar</packaging>
- <name>Jexer</name>
- <description>Java Text User Interface library that resembles Turbo Vision</description>
- <version>1.0.0-SNAPSHOT</version>
- <url>https://gitlab.com/klamonte/jexer</url>
-
- <licenses>
- <license>
- <name>MIT License</name>
- <url>http://www.opensource.org/licenses/mit-license.php</url>
- <distribution>repo</distribution>
- </license>
- </licenses>
-
- <properties>
- <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
- <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
- </properties>
-
- <scm>
- <connection>scm:git:https://gitlab.com/klamonte/jexer.git</connection>
- <developerConnection>scm:git:https://gitlab.com/klamonte/jexer.git</developerConnection>
- <url>https://gitlab.com/klamonte/jexer</url>
- <tag>HEAD</tag>
- </scm>
-
- <issueManagement>
- <system>gitlab</system>
- <url>https://gitlab.com/klamonte/jexer/issues</url>
- </issueManagement>
-
- <distributionManagement>
- <snapshotRepository>
- <id>ossrh</id>
- <url>https://oss.sonatype.org/content/repositories/snapshots</url>
- </snapshotRepository>
- <repository>
- <id>ossrh</id>
- <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
- </repository>
- </distributionManagement>
-
- <build>
- <sourceDirectory>${project.basedir}/src</sourceDirectory>
- <resources>
- <resource>
- <directory>${project.basedir}/resources</directory>
- <filtering>false</filtering>
- <includes>
- <include>**/*</include>
- </includes>
- </resource>
- <resource>
- <directory>src</directory>
- <excludes>
- <exclude>**/*.java</exclude>
- </excludes>
- </resource>
- </resources>
-
- <plugins>
-
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-compiler-plugin</artifactId>
- <version>3.1</version>
- <configuration>
- <source>1.6</source>
- <target>1.6</target>
- </configuration>
- </plugin>
-
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-jar-plugin</artifactId>
- <version>3.0.2</version>
- <configuration>
- <archive>
- <manifest>
- <mainClass>
- jexer.demos.Demo1
- </mainClass>
-
- </manifest>
- <manifestEntries>
- <Implementation-Version>${project.version}</Implementation-Version>
- </manifestEntries>
- </archive>
- </configuration>
- </plugin>
-
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-source-plugin</artifactId>
- <version>2.2.1</version>
- <executions>
- <execution>
- <id>attach-sources</id>
- <phase>verify</phase>
- <goals>
- <goal>jar-no-fork</goal>
- </goals>
- </execution>
- </executions>
- </plugin>
-
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-javadoc-plugin</artifactId>
- <version>2.9.1</version>
- <executions>
- <execution>
- <id>attach-javadocs</id>
- <goals>
- <goal>jar</goal>
- </goals>
- </execution>
- </executions>
- </plugin>
-
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-release-plugin</artifactId>
- <version>2.5.3</version>
- <configuration>
- <localCheckout>true</localCheckout>
- <pushChanges>false</pushChanges>
- <mavenExecutorId>forked-path</mavenExecutorId>
- <!-- <arguments>-Dgpg.passphrase=${gpg.passphrase}</arguments> -->
- </configuration>
-
- <!--
- <dependencies>
- <dependency>
- <groupId>org.apache.maven.scm</groupId>
- <artifactId>maven-scm-provider-gitexe</artifactId>
- <version>1.9.5</version>
- </dependency>
- </dependencies>
- -->
- </plugin>
-
- <plugin>
- <groupId>org.sonatype.plugins</groupId>
- <artifactId>nexus-staging-maven-plugin</artifactId>
- <version>1.6.7</version>
- <extensions>true</extensions>
- <configuration>
- <serverId>ossrh</serverId>
- <nexusUrl>https://oss.sonatype.org/</nexusUrl>
- <autoReleaseAfterClose>true</autoReleaseAfterClose>
- </configuration>
- </plugin>
- </plugins>
- </build>
-
- <profiles>
- <profile>
- <id>release-sign-artifacts</id>
- <activation>
- <property>
- <name>performRelease</name>
- <value>true</value>
- </property>
- </activation>
-
- <build>
- <plugins>
-
- <!--
- <plugin>
- <artifactId>maven-deploy-plugin</artifactId>
- <version>2.8.2</version>
- <executions>
- <execution>
- <id>default-deploy</id>
- <phase>deploy</phase>
- <goals>
- <goal>deploy</goal>
- </goals>
- </execution>
- </executions>
- </plugin>
- -->
-
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-gpg-plugin</artifactId>
- <version>1.5</version>
- <executions>
- <execution>
- <id>sign-artifacts</id>
- <phase>verify</phase>
- <goals>
- <goal>sign</goal>
- </goals>
- </execution>
- </executions>
- </plugin>
- </plugins>
- </build>
- </profile>
- </profiles>
-
- <developers>
- <developer>
- <id>klamonte</id>
- <name>Kevin Lamonte</name>
- <email>kevin.lamonte@gmail.com</email>
- </developer>
- </developers>
-</project>
git://git.nikiroo.be / nikiroo-utils.git / commitdiff
