There's some stuff I'd really like, but would take too much time for me to implement. I've listed a few below. If you need an idea for a project, an extension to software you want to do, or a school project, read on!

• An X11R5 and above window manager (yes, R5 as well) that has the same level of functionality as eesh for Enlightenment except written as a literate program and implemented using libX11 and libXt only. Nevermind the eye candy.

• An extension to the above window manager to allow actions to be taken on startup in a manner similar to using xtoolwait in your ~/.xinitrc, except it is based on the window manager state. The states tracked by the window manager are such things as "Splash displaying", "Initializing", "Ready to accept input", and "About to shut down". The reason I want this feature is so I can have the window manager control the timing of client launches instead of just relying on xtoolwait.

• An extension to the eesh clone that adds an IPC mechanism that says, "Run this program with these arguments on this virtual desktop."

• Modifications to the trn newsreader to allow a display filter to be set for each newsgroup and globally, similar to the killfile, except this only affects the view of the newgroups/threads.

• The ability to bind each view as in the item above to a specific identifier. Thus the command :view/a would bring up all newsgroups in the "a" view set, :view/+ would bring up all newsgroups, and :view/. would only show the current newsgroup, and so on. This feature also applies to the individual articles/threads, so one can selectively remove from view all articles in a thread that has, say, a character encoding that the terminal doesn't understand. One can later go back to it running under a more functional terminal emulator to read those articles.

• An XTest and RECORD-based "mouse control" extension to the window manager using a stack-based PostScript-like language that controls mouse movement, along with a timing parameter. This feature would let one script the movement of the mouse as seen by the clients of the window manager, letting one write automation tools for commercial applications that don't have a proper command-line interface. Or for those where the command-line interface is buggy. Yes, this functionality will help a lot. Even with DSL, cable modems, etc., one still has to deal with the huge overhead of drawing cra... stuff like animation over remote displays across continents.

• A modification of elvis (the vi clone) to change the document stack to a document tree so one can use the following commands:

  :push http://www.example.com

  Add a document to the default branch.

  :push/a ftp://localhost/pub

  Push a document to the "a" branch as seen from the current node.

  :lsstack

  Show the current tree to a configurable depth, defaulting to three levels, with the current node as the root.

  :push/^a/b docs/lart.txt

  Push the document onto the absolute document branch /a/b.

  The document branch names can be thought of as virtual directories, with the documents being the virtual files. In such a manner, one can have a document tree instead of using a simple stack.

  Of course, this feature also means one would need a way of saving and restoring the stack, as well:

  :savestack a

  Save the stack to the file a. Without it, defaults to ~/.elvis/stacks

  :loadstack a

  Figure this one out yourself. :-)

• Modifications to the T_EX program so allow it to parse UTF8 and other character encoding in both multi-byte and wide-char form correctly. The Omega project still isn't far enough along... :-(

• Modification to T_EX to allow it to use a mmap()'d file as backing store and implement an old 6502-style bankswitching memory extension when the hardware addres space just isn't enough to handle lots of input in complex LaT_EX macros. (You think I'm kidding about a document that complex, don't you? :-)

• An extension to Xnest or a new client that will allow emulation of visuals not available under the X server. The primary application would be for the proper execution of programs that rely on PseudoColor visuals to be present on a PC, since most PC video cards do not support more than one visual class. Another use would be running applications that require PseudoColor on a server that supports multiple visuals when in a mode that does not support PseudoColor, such as in 15/16/24/32-bit mode.

  Also handy for writing applications for StaticColor/StaticGray/GrayScale on a TrueColor/DirectColor displays, such as low-cost graphical Point-of-Sale systems and interfaces designed specifically for the color-blind.

  Although VNC is available as an option, I'd prefer either a simple client that will only intercept X calls dependant on the visual class. Another option is a library that can be used to override the standard calls through LD_PRELOAD. While this won't solve the problem for static executables, it will allow me to write a wrapper. A final option is a modification of the X server itself to do remapping of the client's pallette view and display to emulate other visuals.

• Okay, this one's probably never gonna be implemented. Ever. But I thought I'd toss it out, since it's something that's be nice to have for the kinds of stuff that... well, most of you probably would consider me nuts for doing.

  The addition of "depth" as a new dimension to T_EX so instead of working on a plane and looking at area, one can work in a space and look at volume. No, really. I want it. Why, you ask? Well, this is gonna seem really strange, but... imagine a linotype. Now imagine printing on material that's "fluffy" and not perfectly flat. Now imagine varying the height of some of the lead types to get different effects. Think of, say, printing on soft leather. So details like angle of the type, pressure, and how yielding the "material" is.

  It's a nice thing to have for certain looks, it can be done by hand with an image editor after the creation of the output file, and it'll be an incredible amount of work for something rarely used. So I don't expect it to ever get implemented, as I am certainly not willing to invest that much time. :-)