Xcurses

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:
  • all component objects' _init functions (see GCC documentation, "How Initialization Functions Are Handled") may be safely invoked, and
  • resource consumption in the event of non-use is negligible

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

Complications

• Graceful degradation
• TERM: In order to support

See Also

• Outcurses, which actually went somewhere
• Notcurses, which modernizes NCURSES
• TANGE