584 lines
26 KiB
Plaintext
584 lines
26 KiB
Plaintext
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.)
|