path: root/app/xlockmore/docs/TODO

General problems:
  o PAM get working on solaris

  o fix up -h

  o For security (Theo de Raadt <deraadt@cvs.openbsd.org> and
      Yuri Bushmelev <jay-dev AT simcom.ru>)
    - in initpasswd()
    - create two pipes
    - fork a child
        - read a password from the pipe
        - do a check
        - write a 1 or a 0
        loop
    - have the parent revoke it's uid's completely.
        - use one pipe to send passwords to the child
        - read for 0 or 1
        - use SIGCHLD to detect child exit

    - look to checkpassword-pam (http://checkpasswd-pam.sourceforge.net/)
        for an example.
  o Switching consoles using XFree-4.0, the X server sends a fully-obscured
   event to all its clients, and when I switch back to the graphical
   terminal, it sends fully-visible or partially-obscured event to its
   clients.  xlock doesn't handle these event, it still can consume 99% of
   CPU time in several lock-modes. It would be really good if xlock, when
   receiving an obscure-event, stopped doing anything CPU-consuming stuff.

   The three messages (fully visible, partially visible and fully obscured)
   exist in X11 for a long time. Launch the utility 'xev' and move another
   window over it, and see what it prints. This is useful so that
   applications (such as fractal animators or Spectrum/C64 emulators or
   really anything) know if its window is not visible and therefore can save
   a lot of cpu time if it doesn't even want to draw (update) its contents.
   For example there's a spectrum emulator at
   http://www.inf.bme.hu/~mszeredi/spectemu/spectemu.html, if you launch this
   and switch to full speed mode, you'll see that it runs much faster if its
   window is obscured by another window or windows.

   Using the XFree-3.3 servers if you switched back to the linux console, no
   events were sent to the applications, so they couldn't realize that thier
   contents is not visible to the user in this case. In XFree-4.0 the windows
   get the fully-obscured event when you switch to linux console, so for
   example a Spectrum emulator can save really a lot of cpu time, since it
   doesn't need to redraw its screen 50 times per second.

  o It would be nice to have an option -idletime time.  Where xlock would
   run after a certain idle time.  (Here xautolock may help you, see
   README).

  o Currently for multiple users to unlock the account one has to have
   UIDs to be the same.  whoami, for example, always comes back with
   the first one in the list regardless of which of the users it really
   is.  So they'll have to have special accounts for this app.  That
   is okay, but it would be nice if xlock had some sort of command line
   or xlockrc option that allowed specifiying users who had unlocking
   privileges.

  o xscreensaver compatibility
   writable modes: mandelbrot, tube, (lyupanov?)-> get them to RUN
   (compile OK)

  o Add a way to get xlock to switch to "blank" mode after X minutes
   of (keyboard) inactivity, and to switch back to whatever mode list was
   being used when activity is detected.  This would be good for
   users using DPMS to power down the monitor without using precious cpu
   when the modes are not visible.

  o Some xlock modes take a long time to start.  In particular the 3d ones
can take up about ten seconds for the necessary libraries to load (on a
400MHz Intel Celeron system).  If one of these modes is chosen as the
first one to run after xlock starts, then there will be a ten second
delay between running xlock and the display actually being locked.  If
you start xlock from a window manager then it appears that nothing has
happened, which can cause the user to click on 'lock screen' again and
start a second xlock.

The delay itself is probably unavoidable, but xlock could overcome the
'nothing is happening' problem by always choosing the 'blank' mode
first.  So if you say 'xlock -mode sproingies', first xlock starts and
goes into blank mode to make sure the screen is locked, then starts
loading and running the bouboules mode.  This makes sure that the screen
gets locked almost instantly after running xlock and the user doesn't
have to wait.

Possible further step: always go to 'blank' before even looking at what
mode was chosen, in other words before doing command-line checking of
the mode name.  Suppose I set the 'lock screen' command in my window
manager to 'xlock -mode sproingies'.  This takes ten seconds or so to
load the OpenGL libraries, but it works eventually.  Then I use somebody
else's machine, which doesn't have the sproingies mode included with
xlock.  I click on 'lock screen' and xlock prints an error message which
goes to my .xsession-errors file.  But to the user it looks like nothing
has happened.  Knowing that sproingies takes a while to start up, I
leave the terminal, but in fact it was never locked.  It would be better
for xlock to go to mode blank first of all, and then try to load
sproingies, and if that doesn't exist print an error message to stderr
and on the screen.  At least that way the display is guaranteed to get
locked.

  o Imagine a crowded lab of workstations.  Some have people sat at them but
even those machines with nobody in front of them might be locked.  If
you are a user entering the lab looking for a free machine you look
around for a login screen.  The login screen is probably easy to spot
(at my site, it has a blue background).  Or maybe xlock draws some border
around main xlock mode screen when logout button is available. Or use some
kind of pseudo-transparency to draw such button.

To avoid the problem of workstations being locked for too long, there is
the 'click here to logout' button which is enabled by default and comes
on after twenty minutes.  The trouble is that while a with-button
xlocked machine is just as usable as a machine showing the login screen,
it doesn't _look_ any different to one which is ordinarily locked.
If you see five machines showing an xlock display, there's no way to
find out which of them you could use other than walking past and tapping
a key to see whether the logout button appears.  In a lab of 100 PCs
this is awkward.
I suggest that when the public logout button appears the xlock display
should noticeably change.  I don't know to what exactly, perhaps the
'type password to logout, select icon to lock' screen should be
permanently displayed, with a big logout button in a nice bright colour.
Then it would be obvious, even from a distance, whether a session is
kick-off-able or really locked.

   o when a user runs "xlock -mode unknownmode", it should print a warning
  and default to blank mode or the default mode (random) instead of exiting
  with a usage error. This way, the screen is still locked as requested by
  the user if they ask for a mode that is not available.

  o some sort of command line or xlockrc option that allowed
   specifiying users who had unlocking privileges.

  o some sort of completion is used which may be confusing on UNIX
   Say if a ../bitmaps directory exists and ../bitmap does not
   xlock -mode random -modelist image -bitmap ../bitmap
   will try to load ../bitmaps as a file...

  o kill -HUP to change modes as well as middle mouse button.  Needed when
   using -inroot .

  o -showfps option may give a Zero Page Read and SEGV error using Mesa
   and Sun

  o configure.in should be condensed.  Its getting out of hand.

  o Look into any way of not clearing the screen if can not get control of it
   (2nd xlock running).

  o gentlerandom mode option.  Switching to next mode when mode completed
   what it was working on.

  o On a PsuedoColor display
      xlock -mode life -install &
      sleep 5 ; xlock -mode life -install
   Colors will all be messed up after the second one tries to run.
   This can easily happen if you are using xautolock and decide to lock
   the display manually.

  o -wireframe should be a mode option (i.e. you should be able to turn it
   on and off for a particular mode).  Also a linewidth mode option would be
   nice

  o I got an error with moebius running it on opengl on a 24 bit TrueColor like:
   xlock -mode moebius -visual PseudoColor
   (all the gl modes are messed up anyway... all mono)

  o some configurations of linux: swarm and flow has noise when bees go
   beyond screen (also may happen with forest).
   Sun Ultra5 PCI Bus 24 bit display: flow has some noise (usually red)
   This is especially true if you use -inwindow for swarm, flow, euler2d.
   I think these errors are limited to the graphics card.

  o A few uninitialized memory reads and memory leaks were detected in some
   of the code.  grep for "PURIFY" in the source files to see where the
   remaining problems are.  Also see docs/Purify for more details.

  o superquadrics does not work on some Linux boxes (not mine).

  o Text3d will dump core on some linux boxes (not mine) due to random font
   routine.  Temporary solution: use arial.ttf directly.  See "#if 0" in
   text3d.cc.

  o glplanet does not display stars clearly on Sun with OpenGL except when
   in password window (Sun with Mesa ok).

  o molecule logs me out on Sun Ultra 5 with OpenGL 1.2.1 and 1.2.2
   (using gcc or cc) when the return key is held down.  This has not
   been repeated on any other Sun.  Tracing on this seems to indicate
   the release code but when commented out would still die (done
   with XSynchronize on).

  o -mono does not work for XPM (they just use XBM when mono), also cage
   and stairs.

  o Not all resources are listed in "xlock -resources", e.g. nolock.
   If xlock is renamed these resources are not picked up.

  o Without any programs stealing your colors, like netscape
   xlock -modelist all -sequential -install -verbose
   Hit the middle button a hundred times (not to bad on an ultra actually)
   or try -duration 1 and let it sit for a while.
   The second time it runs the GL modes they have all lost some colors.
   This was only noticed on Solaris with pseudocolor.  Also noticed on an
   ancient HP9000/380 HPUX9.0 with 6 bit depth (without netscape).

  o On a German keyboard and Linux if the password contains special
   characters (`|' vertical bar, `@' at-sign) while in debug mode
   everything works fine. This probably has something to do with the
   X11-keymapping, as these characters are composed with the right Alt-key
   on a German keyboard.

  o OpenGL and DT may be incompatible on PseudoColor.  (MesaGL should be
   OK.)  OpenGL frequently causes xlock to error out on non-default visuals.

  o Errors in modes, if any, should not break lock.

  o Unstable mode "run" allows running of separate processes should be made
   to run on VMS (now just blanks the screen).  The problem is a totally
   different concept of starting other programs from within a program.
   Also get "run" to run with -debug.

  o make -n install prefix=/foo/bar does not work.

  o "xlock -mode random -modelist image -bitmap ./bitmaps/"
   It should change images when middle mouse is pushed or when
   -duration time runs out.

  o jpeg/gif/animated gif support  Fix ras for > 8 bit TrueColor

  o "-visual" commandline argument should accept "best" as well as
   PseudoColor, TrueColor, default, etc.

  o Is there any chance the "visual" selection code could be made
   mode-dependent?  Most Xservers that support TrueColor, etc, visuals also
   support PseudoColor visuals and it would be nice to have color-cycling
   modes like "starfish" and "swirl" pick a PseudoColor visual if available,
   while xpm modes could prevent colormap flashing by picking a TrueColor
   visual.
   I heard that VisualDepthMask taken out of vis.c it seems to work better
   to get a PseudoColor visual one a root window of 24 bits.

  o % make install
[...]
make[1]: Entering directory `/vol/bitbucket/epa98/xlockmore-5.03/modes'
../mkinstalldirs /vol/linux/apps/bin
/usr/bin/install -c -s -o root -m 4111 ../xlock/xlock /vol/linux/apps/bin
/usr/bin/install: cannot change ownership of `/vol/linux/apps/bin/xlock': Operat
ion not permitted
make[1]: *** [install-program] Error 1

Make is trying to install xlock owned by root and suid, but I am not
root.  It might be more user-friendly to either:

- - If the user running 'make install' is not root, assume that xlock
  should be installed non-suid, or

- - If the user is not root, complain and give up.
I looked for a configure option to tell the build process not to install
suid or owned by root, but I didn't find one (or anything obvious in the
README).  But you can certainly use xlock if it's not root.

  o  From Duncan Simpson <dps@io.stargate.co.uk>

Due to the introduction of Xinerama, and a couple of monitor displays, I would
find a horizontal fivision option that runs two windows each half the width
of the display (which corresponds to one window one each monitor).
Let xlock detect Xinerama enabled and draws login display only on primary
screen.

I do not know the details of x2x, although I guess various sorts of multiple
monitor technology might benefit from this sort of support (one could think
of Xnest with re-direction to appropiate screens).

Information on x2x is almost certainly somewhere on the web, but I do not
have a URL on me (ask your favorite search engine, I guess). I think it
involves using multiple boxes for display driving purposes---I hear someone in
the lab has 4 screens across with x2x (the pointer moves off one screem onto
another). Xnest is an xserver that asks a parent X server to do the work, and
I think you can use it to present different display information and so forth.

Xinemera is much easier, it basically just glues mutliple bits of hardware
together into a single huge bit of virtual hardware. It does not appear in the
extensions list. xlock just sees a single display with 2304x900 pixels on my
system, which is actually 2 screens 1152x900 each.  AFAIK there is no easy way
to detect Xinemera modulo strange aspect ratios and the like (e.g. my display
is suspicously wide, assuming I am using conventional display hardware).
Recycled 1990 SUN monitors are conventional, albeit rather pickier about the
video signal that one expects these days.

I was thinking I could add -hdiv 2 and would xlock use half the display width,
in my case 1152, as the width of an appropiate number of windows (2 for half
width). One could think of a maximum window width, with the code generating an
appropiate number of windows, for a similar effect. I image neither option
would involve vast amounts of code or internal changes.

Actually, on a more careful analysis Xinereama is listed in the extensions and
in extensions/Xinerama.h I see the following functions

Bool XineramaIsActive(Display *dpy);
XineramaScreenInfo *
XineramaQueryScreens(
   Display *dpy,
   int     *number
);

XinermaScreenInfo is a structure that contains screen number, x and y origin,
width and height (one per head, judjing by the function prototype). The
extension is not supported everywhere but feature test macros or autoconf
should cope. Imake apparently includes

#define XineramaDefines -DPANORAMIX

if you have the support (and presumably this means you have the header too).
My proposal would be less elegant.

~$ gcc -o xintest.^H ci^H^Hxintest.c -:^HL/usr/X11R6/lib -lX11
=^H-lXext -lXinerama
~$ ./xintest
Xinerama supported: event base 0, error base 0
Xinerama active
There are 2 heads
Head 0: screen 0 size  1152x900 starting at 0,0
Head 1: screen 1 size  1152x900 starting at 1152,0
~$ exit

Script done on Sat Apr 15 19:25:46 2000

Which has interesting effects in ink blot mode (50% of the ink blot on each
screen, not indeal). Modes dewsned for about 4x3 suffer quite badly from
stretching pn 2304x900... hence my desire for a version aof xlockmore aware of
the screen boundaries.
#include <stdio.h>
#include <X11/Xlib.h>
#include <X11/extensions/Xinerama.h>

int main(void)
{
    Display *dpy;
    int xin, ev, err, i, nh;
    XineramaScreenInfo *scr;

    dpy=XOpenDisplay("");
    xin=XineramaQueryExtension(dpy, &ev, &err);

    if (!xin)
    {
        printf("Xinerama not avialable\n");
        XCloseDisplay(dpy);
        return 0;
    }
    printf ("Xinerama supported: event base %d, error base %d\n",
            ev, err);

    printf("Xinerama %sactive\n", XineramaIsActive(dpy) ? "" : "in");

    if ((scr=XineramaQueryScreens(dpy, &nh))!=NULL)
    {
        printf("There are %d heads\n", nh);
        for (i=0; i<nh; i++)
        {
            printf ("Head %d: screen %d size  %dx%d starting at %d,%d\n",
                    i, (scr+i)->screen_number,
                    (scr+i)->width, (scr+i)->height,
                    (scr+i)->x_org, (scr+i)->y_org);
        }
        XFree(scr);
    }
    XCloseDisplay(dpy);
    return 0;
}


  o modes from xscreensaver :) : bubbles, moire, LMorph, halo, ImsMap, BlitSpin


Mode specific problems:
----------------------
  Various modes need better refresh capability.
  Various modes need more mouse capability like worm.

  ant:
    round ants.  This would involve masking and images to do efficiently.
    3d version (up, down, left, right turns)?  May be hard to see interior
    though.

  ball: can it be updated to use a pixmap instead of a slow circle fill?

  braid: should be made so that it can be interrupted quicker.

  bouboule: always starts at the bottom right

  bounce:
    sometimes a ball does not roll off another ball.
    momentum seems to be created.
    A -wall option, multiscreens should have balls bouncing between
      screens.
    -mode bounce -inroot may give BadWindow in X_GetWindowAttributes
      if run for a while, but the screen is not locked :)
    allow a background picture to be seen behind the bouncing football
      (soccer ball) in "bounce" mode.  Thus a picture of your favorite
      team, etc. can be seen behind the bouncing balls.
    football version of "bounce" using a pigskin instead of a soccer ball for
      Americans/Canadians/etc.
    Different balls with different mass and size.

  bug:
    3d version?  Will triangular bugs evolve, if not, can they?

  flag: add an option for amplitude.

  ico:
    should have all the features of the original.
    triangular face objects do not look good when rotated.

  image: middle button should do something when called like
     "-bitmap ./bitmap/"

  hop: center and size many of the hops.

  life:
    -find option to find new lifeforms.  (mail the results out :) also life3d).
    When the bitmap is big it is rejected.  Probably could be handled
      better but if accepted then the screen could be blank because there
      are bitmaps that are off the screen.

  life3d:
    A densely packed spherical version on corners of a cuboctahedron (or
       rhombic dodecahedrons).

  lyapunov: needs to be speeded up

  marquee:
    "-messagefile filename" truncates a large file.
    "-message string" does not handle Control-H correctly.
    fallback font if screen is small... like bomb


  mountain: -size # for mountain should do something.

  noof: a cpu killer.  Strip out OpenGL or increase the variablity
    like having the "flowers" skew with respect to the viewer.
  nose:
    should handle Control-H better for underlining and accents.
    fallback font if screen is small... like bomb

  pyro: needs XDrawSegments code similar to swarm to give it depth.

  slip:
    should be less jarring
    get rid of single color blotch.
    should be made so that it can be interrupted quicker.

  star:
    fractal cracks when hit by rocks (with sound?)
    user defined ships (user defined pixmaps like eyes and pacman).
    stars should look more star-like "*"'s
    combine space and star for a backwards and sideways motion

  swirl:
    needs to be refreshed quicker
    does not refresh well when colormap changes

  text3d:
     time stuff in text3d
     maybe dclock and marquee could be combined too?
     a separate -message3d for text3d

  voters and wator:
    neighbors option bug ... sometimes circles are not
      drawn in the correct spot.
    A -/+ wrap option would be nice also.

  wire:  it needs a better circuit generator.

  xglock:  Needs a lot of work.

  kscreensaver:  port xlock to KDE.


New mode ideas... (some may be very hard :) ):
---------------------------------------------
  o "bsdworm" BSD worm game with computer (and later mouse control), also
      have more than one worm
  o "dead" a Grateful Dead mode with dancing bears/skeletons/turtles.
      (Or maybe "nose" in a tie die?)
  o "floyd" a Pink Floyd mode from the cover of "Dark Side of the Moon"
      with a turning prism and rainbow effect.
  o "graph" a random planar graph drawn ... filled in by a 5 (or 4 :) )
      coloring algorithm.
  o "mail" show that one has mail (can also be an option on flag, image, etc.)
      A spinning GL mailbox would be really cool.  Note that the password
      screen can be setup to show if one has mail.
  o "minimal" a random minimal surface generator.
  o "pangea" a mode showing the changes to the earth's surface over
      millions of years.
  o "snow" mode with a nice Winter scene picture background and snowflakes
      falling
  o "soap" mode showing soap films
  o "squig" mode from squig/xsquig (xsquig is too slow)
  o "venus" mode showing the transformation of a Etruscan Venus to a
      Roman surface to a Boy surface to a Ida surface, back into a
      Etruscan Venus using GL.  This is a 3D shadow of a 4D Klein Bottle
      (which in turn is a a 3D moebius strip).
      (Science News October 24, 1987 Vol 132, No 17.)
  o Simulations like sandpile avalanches or forest fires.
      (Science News July 15, 1989 Vol 136, No 3.)
  o A NT-like GL 3D Maze, where you are inside the maze
  o NT-like GL FlowerBox spring and Flying Objects
  o A GL 4D ico where the 6 4D "platonic" objects "roll" around in 3D space.
  o GL modes based on demos: isosurf, reflect, bounce, stex3d
  o KitCat (R) clock mode (based on X11 catclock, a version of xclock) where
     the cat clock floats around the screen like "dclock" mode does.  Colors
     of cat clock could be picked like nose-guy in "nose" mode.
  o Lottery with bouncing numbered balls like PowerBall.
  o morph3d for rhombic dodecahedron and rhombic triacontahedron
  o A simple set of 2D geometric shapes that morph into one another whilst
     colour cycling. So say you start with a rectangle that morphs into a
     circle (leaving a small trail like Qix) that morphs into a triangle
     that morphs into a polygon that morphs into a rectangle, etc.  All the
     while you have movement and colour cycling like Qix.  If the trail is to
     large then things could become messy, but if too short then you loose the
     history element.
  o A simple bouncing ball on a chess board. The ball is a silver
     ray-traced/rendered globe. The chess board is a series of black and
     white squares. Each black square is gold veined marble with the gold
     glinting. Each white square is a textured surface (like little bumps, or
     ridges). The whole screen is lit from two light sources (either fixed or
     moving). As the ball bounces it reflects like a mirror what is around it.
  o A variant of the above would be to hold that ball still in the centre of
     the screen and move a randomly chosen bitmap around the ball.
  o The above could also have embossed on standout lettering added (say a
     single word like Linux). The lettering could either be stationary or
     float around the ball in orbit a bit like the the Universal studios logo
     where the Universal name revolves around a picture of the earth.
  o Take pipes and add the constantly moving view point that you get with
     rock so the mass of pipes seems to revolve and rotate around a moving
     point in space.
  o Make the little man in Nose seem to carve the letters of the message into
     rock, or paint them on the screen.
  o Make marquee use 3D extruded text that can be texture mapped and seem to
     zoom into and out of the screen with the zoom source point drifting
     around the screen at random
  o Make puzzle take the present desktop image, invert it and shuffle the
     pieces then put the whole things back. Once it has reassembled the
     desktop you could have the image flip top over bottom as it reseeds into
     the screen, only to have a new randomly shuffled version of the desktop
     flip back out.
  o Use the spheres generated in sphere to draw molecules on the screen,
     colour coding for the various types of atom present. A limit on the size
     of each sphere would be needed. The spheres could be joined by simple
     white lines. If you are feeling adventurous you could make it seem to
     rotate in space so all parts of the molecule could be seen.
  o In shape change things so that the shapes appear to be extruded from a
     random point on the screen. You could also have a number of shapes be
     extruded, each from its own origin, only to shrink back into the screen
     again.  Each time a shape shrinks back into the screen the origin would
     move and a new shape would be chosen.
  o When the screensaver is started have curtains drawn across the desktop
     at a medium pace, a second or twos pause then the curtain a pulled open
     quickly to reveal a bitmaped image in place of the desktop. This cycles
     with a different image each time.
  o In pyro have the fireworks appear to zoom from a randomly choose point on
     the screen. This would give the effect of the display being seen from
     above.
  o In decay mode, have a Blue Screen of Death option.

PLEASE NOTE:
-----------
  I _REALLY_ hate to turn down contributions...  I will try to consider
   all submissions.  Some things on new modes that bother me are:
   Did not black out the screen when they start.  I do not like people
     to see what I am doing. :^|  (This could be a non-default option...
     see decay mode).
   Did not work in the little window or buggy.  (I usually try to clean
     it up).
   Is too similar mode to a mode that already exists. (Maybe an option could
     be added on an existing mode?).
   Many people complained about the mode.
   Just not enough randomness or is not interesting enough.
   No multiscreen support (I usually try to clean this up too).
  But I labor over them (in a haphazard fashion) and they usually are
   released eventually.  (If they are in assembler I would definitely need
   a working example and all the binaries and libraries to get it to run.)