Check out my first novel, midnight's simulacra!
Xcurses: Difference between revisions
No edit summary |
|||
Line 12: | 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 | ==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:''' | |||
** I'd rather have my balls cut off. | |||
===Take over libcurses.so=== | ===Take over libcurses.so=== | ||
===[[Working_with_libraries#Interpositioning|Interpositioning]]=== | ===[[Working_with_libraries#Interpositioning|Interpositioning]]=== | ||
Line 34: | Line 61: | ||
===Relinking=== | ===Relinking=== | ||
==Complications== | ==Complications== | ||
* '''Graceful degradation''' | * '''Graceful degradation''' |
Revision as of 11:58, 29 July 2012
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:
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:
- I'd rather have my balls cut off.
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