Check out my first novel, midnight's simulacra!

Xcurses: Difference between revisions

From dankwiki
Line 21: Line 21:
* '''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 28:
** 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===

Revision as of 11:43, 29 July 2012

A 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:

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 would it work

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) $ 

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

TANGE