Check out my first novel, midnight's simulacra!

Xcurses: Difference between revisions

From dankwiki
(Created page with "A curses variant implemented purely with X.org objects, perhaps even GL objects or something. The result ought be significantly faster than a fullscreen [[...")
 
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
A [[Ncurses|curses]] variant implemented purely with [[X.org]] objects, perhaps even [[GL]] objects or something. The result ought be significantly faster than a fullscreen [[Ncurses]] program atop a terminal emulator -- not to mention worlds more attractive -- all without so much as relinking existing applications. There exists one grim central theme behind Xcurses, and I call it UNTIE: <center>''Unnecessary terminal emulation is everywhere!''</center>
A [[Ncurses|curses]] variant implemented purely with [[X.org]] objects, perhaps even [[OpenGL]] objects or something. The result ought be significantly faster than a fullscreen [[Ncurses]] program atop a terminal emulator -- not to mention worlds more attractive -- all without so much as relinking existing applications. There exists one grim central theme behind Xcurses, and I call it UNTIE:
 
<center>'''Unnecessary terminal emulation is everywhere!'''</center>


Whereas libaa and libcaca (beautifully) attenuate high-resolution graphics, reducing them to input suitable for low-resolution "character cell"-based displays, Xcurses (faithfully) renders programmatic character cell output as virtual vector primitives, applies optional transforms, and renders them to a high-resolution bitmap display. Xcurses will have knowledge of the input forms at the '''character set''' level, which ought allow for interesting effects...
Whereas libaa and libcaca (beautifully) attenuate high-resolution graphics, reducing them to input suitable for low-resolution "character cell"-based displays, Xcurses (faithfully) renders programmatic character cell output as virtual vector primitives, applies optional transforms, and renders them to a high-resolution bitmap display. Xcurses will have knowledge of the input forms at the '''character set''' level, which ought allow for interesting effects...
* Scalable brackets (
* Scalable brackets
* True support of GTK/QT themes
* True support of GTK/QT themes
** Palette initialized with the theme palette as opposed to [http://stackoverflow.com/questions/8686368/how-can-the-original-terminal-palette-be-acquired-preferably-using-ncurses-rout a bunch of useless horseshit]
** Palette initialized with the theme palette as opposed to [http://stackoverflow.com/questions/8686368/how-can-the-original-terminal-palette-be-acquired-preferably-using-ncurses-rout a bunch of useless horseshit]
Line 10: Line 12:
If non-automatic augmentation is considered, we can do fairly tremendous things, all at the level of ncurses complexity.
If non-automatic augmentation is considered, we can do fairly tremendous things, all at the level of ncurses complexity.


==How would it work==
==How might it work?==
===Take over libcurses.so===
Currently...
Currently...
<pre>[skynet](0) $ ls -l /usr/lib/x86_64-linux-gnu/libcurses.*
<pre>[skynet](0) $ ls -l /usr/lib/x86_64-linux-gnu/libcurses.*
lrwxrwxrwx 1 root root 12 Jun 27 12:28 /usr/lib/x86_64-linux-gnu/libcurses.a -> libncurses.a
lrwxrwxrwx 1 root root 12 Jun 27 12:28 /usr/lib/x86_64-linux-gnu/libcurses.a -> libncurses.a
lrwxrwxrwx 1 root root 13 Jun 27 12:28 /usr/lib/x86_64-linux-gnu/libcurses.so -> libncurses.so
lrwxrwxrwx 1 root root 13 Jun 27 12:28 /usr/lib/x86_64-linux-gnu/libcurses.so -> libncurses.so
[skynet](0) $ cat /usr/lib/x86_64-linux-gnu/libncurses.so
INPUT(libncurses.so.5 -ltinfo)
[skynet](0) $ file /usr/lib/x86_64-linux-gnu/libncurses.a
/usr/lib/x86_64-linux-gnu/libncurses.a: current ar archive
[skynet](0) $ </pre>
instead, of course, we'd have...
<pre>[skynet](0) $ ls -l /usr/lib/x86_64-linux-gnu/libcurses.*
lrwxrwxrwx 1 root root 12 Jul 29 04:03 /usr/lib/x86_64-linux-gnu/libcurses.a -> libXcurses.a
lrwxrwxrwx 1 root root 13 Jul 29 04:03 /usr/lib/x86_64-linux-gnu/libcurses.so -> libXcurses.so
[skynet](0) $ cat /usr/lib/x86_64-linux-gnu/libXcurses.so
INPUT(libXcurses.so.1 -ltinfo)
[skynet](0) $ file /usr/lib/x86_64-linux-gnu/libXcurses.a
/usr/lib/x86_64-linux-gnu/libXcurses.a: current ar archive
[skynet](0) $ </pre>
[skynet](0) $ </pre>
====Link in X.org libraries====
* '''Good:'''
** Only one object implementing the curses API exists in the core system
* '''Bad:'''
** Conflicts with [[Ncurses]] etc, requiring packaging work
* '''Nonsense:'''
** ''All binaries linking curses will get bigger.'' No, learn how shared libraries work.
** ''Curses apps won't run without an X session.'' No; Xcurses contains [[Ncurses]] as a subset and fallback.
*** There might be a problem with some lame X library aborting without DISPLAY or something.
*** Need verify this is not the case, or better yet become generally robust to this problem.
====Dynamically open X.org libraries====
* '''Bad:'''
** Bad kind of in the same way burning one's testicles is bad, which is to say unpleasant.
====Hybrid linking====
* Link all the X crap into libXcurses-bigfatbagofshit.so
* Dynamically open it from libXcurses once we've verified it's safe to do so, meaning both that:
** all component objects' _init functions (see [[GCC]] documentation, "[http://gcc.gnu.org/onlinedocs/gccint/Initialization.html How Initialization Functions Are Handled]") may be safely invoked, and
** resource consumption in the event of non-use is negligible
===Take over libcurses.so===
===Take over libcurses.so===
===[[Interpositioning]]===
===[[Working_with_libraries#Interpositioning|Interpositioning]]===
We could link libcurses to libXcurses in a non-canonical directory, allowing LD_LIBRARY_PATH/LD_PRELOAD to cause this libcurses to be loaded at runtime. If desired, this could take place in [[X]] startup scripts.
We could link libcurses to libXcurses in a non-canonical directory, allowing LD_LIBRARY_PATH/LD_PRELOAD to cause this libcurses to be loaded at runtime. If desired, this could take place in [[X]] startup scripts.
* '''Good:'''
* '''Good:'''
** Normal, assumed-working curses is still around, in case we exhibit unworkaroundable bugs
** Normal, assumed-working curses is still around, in case we exhibit unworkaroundable bugs
 
** Signed+verified binary+library chains continue to work (without us, of course)
 
**  
* '''Bad:'''
* '''Bad:'''
** Possible source of confusion
** Possible source of confusion
Line 30: Line 63:
** Regular use of these variables is bad practice
** Regular use of these variables is bad practice
*** Security hole should any containing directory be writable
*** Security hole should any containing directory be writable
** Is ignored by tools which walk linker cache or standard lib directories
*** Adding the new directory is a maintenance hassle


===Relinking===
===Relinking===
==Complications==
==Complications==
* '''Graceful degradation'''  
* '''Graceful degradation'''  
Line 37: Line 73:


==See Also==
==See Also==
[[TAGNE]]
* [[Outcurses]], which actually went somewhere
* [[Notcurses]], which modernizes NCURSES
* [[TANGE]]


[[CATEGORY: Projects]]
[[CATEGORY: Projects]]

Latest revision as of 23:46, 19 February 2020

A curses variant implemented purely with X.org objects, perhaps even OpenGL objects or something. The result ought be significantly faster than a fullscreen Ncurses program atop a terminal emulator -- not to mention worlds more attractive -- all without so much as relinking existing applications. There exists one grim central theme behind Xcurses, and I call it UNTIE:

Unnecessary terminal emulation is everywhere!

Whereas libaa and libcaca (beautifully) attenuate high-resolution graphics, reducing them to input suitable for low-resolution "character cell"-based displays, Xcurses (faithfully) renders programmatic character cell output as virtual vector primitives, applies optional transforms, and renders them to a high-resolution bitmap display. Xcurses will have knowledge of the input forms at the character set level, which ought allow for interesting effects...

  • Scalable brackets
  • True support of GTK/QT themes
    • Palette initialized with the theme palette as opposed to a bunch of useless horseshit
    • Replacement of box characters (when used in ACS_VLINE etc contexts) with beautiful, properly themed vector art
    • Transparency at the

If non-automatic augmentation is considered, we can do fairly tremendous things, all at the level of ncurses complexity.

How might it work?

Take over libcurses.so

Currently... 

[skynet](0) $ ls -l /usr/lib/x86_64-linux-gnu/libcurses.*
lrwxrwxrwx 1 root root 12 Jun 27 12:28 /usr/lib/x86_64-linux-gnu/libcurses.a -> libncurses.a
lrwxrwxrwx 1 root root 13 Jun 27 12:28 /usr/lib/x86_64-linux-gnu/libcurses.so -> libncurses.so
[skynet](0) $ cat /usr/lib/x86_64-linux-gnu/libncurses.so
INPUT(libncurses.so.5 -ltinfo)
[skynet](0) $ file /usr/lib/x86_64-linux-gnu/libncurses.a
/usr/lib/x86_64-linux-gnu/libncurses.a: current ar archive
[skynet](0) $

instead, of course, we'd have... 

[skynet](0) $ ls -l /usr/lib/x86_64-linux-gnu/libcurses.*
lrwxrwxrwx 1 root root 12 Jul 29 04:03 /usr/lib/x86_64-linux-gnu/libcurses.a -> libXcurses.a
lrwxrwxrwx 1 root root 13 Jul 29 04:03 /usr/lib/x86_64-linux-gnu/libcurses.so -> libXcurses.so
[skynet](0) $ cat /usr/lib/x86_64-linux-gnu/libXcurses.so
INPUT(libXcurses.so.1 -ltinfo)
[skynet](0) $ file /usr/lib/x86_64-linux-gnu/libXcurses.a
/usr/lib/x86_64-linux-gnu/libXcurses.a: current ar archive
[skynet](0) $

Link in X.org libraries

  • Good:
    • Only one object implementing the curses API exists in the core system
  • Bad:
    • Conflicts with Ncurses etc, requiring packaging work
  • Nonsense:
    • All binaries linking curses will get bigger. No, learn how shared libraries work.
    • Curses apps won't run without an X session. No; Xcurses contains Ncurses as a subset and fallback.
      • There might be a problem with some lame X library aborting without DISPLAY or something.
      • Need verify this is not the case, or better yet become generally robust to this problem.

Dynamically open X.org libraries

  • Bad:
    • Bad kind of in the same way burning one's testicles is bad, which is to say unpleasant.

Hybrid linking

  • Link all the X crap into libXcurses-bigfatbagofshit.so
  • Dynamically open it from libXcurses once we've verified it's safe to do so, meaning both that:

Take over libcurses.so

Interpositioning

We could link libcurses to libXcurses in a non-canonical directory, allowing LD_LIBRARY_PATH/LD_PRELOAD to cause this libcurses to be loaded at runtime. If desired, this could take place in X startup scripts.

  • Good:
    • Normal, assumed-working curses is still around, in case we exhibit unworkaroundable bugs
    • Signed+verified binary+library chains continue to work (without us, of course)
  • Bad:
    • Possible source of confusion
    • Should the variable be unset or absolutely set by another application, programs linked to libcurses and loaded within that environment will function differently.
      • sudo (without -E) clears the environment by design, as do other apps.
    • Regular use of these variables is bad practice
      • Security hole should any containing directory be writable
    • Is ignored by tools which walk linker cache or standard lib directories
      • Adding the new directory is a maintenance hassle

Relinking

Complications

  • Graceful degradation
  • TERM: In order to support

See Also

Retrieved from "https://nick-black.com/dankwiki/index.php?title=Xcurses&oldid=6747"