Check out my first novel, midnight's simulacra!

Xcurses: Difference between revisions

From dankwiki
Jump to navigation Jump to search
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"