The contents of this website are Copyright (c)2004 by Brian Manning <brian at antlinux dot com>. Please do not reuse any of the content on this website without permission from the author.

Currently DocBook PortaBoom Documents

• FAQ
• User's Guide
• Developer's Guide

TODOs

Documentation TODOs

• have each dialog be it's own module,
  • for each module, document the controls in that module in perldoc markup
  • use pod2html to display them in a box at the bottom of the form when running in beginner mode
  • programming details can be documented in the XML docs

Project Ideas

• fbsplash, a framebuffer splash screen
• Use a syslog server for script debugging. See ToDos#Syslog for more information
• The Knoppix boot script is called /etc/rcS.d/S00knoppix-autoconfig
• Hack Gnome/Windows autoplay, so when a PortaBoom CD is inserted into the CD ROM drive, a web page/text page on the CD runs, or an application runs from the CD that displays a web page and/or helps the user make boot floppies. The application can be made up of a statically compiled Perl binary with Tk libs for either Windows or Unix.
• use fakeroot/chroot for building packages (PCMCIA, SDL) into a PortaBoom tree
  • chroot slackware
  • Linux From Scratch
  • Build relocatable packages using fakeroot
  • newbie doc: using fakeroot to build a kernel
  • apt/dpkg quick reference
  • debian binary package building guide
  • scratchbox cross-arch toolchain
• use hdparm to tune/spin down a hard drive
• Create a database of files on a typical Debian system, and add the information about each file in the database:
  • purpose of the file
  • file size
  • whether the file is a stripped binary/library or not
  • whether or not the file is included with PortaBoom, and why the file was/was not included
  • extra notes about the file
  • project the file will be used with
  • file permissions
  • checksums with md5sum or checksum
• redirect startx/x output to tty3 for debugging
• Use HTTP requests from the server to client to control PortaBoom client nodes prior to starting a game
  • this would allow clients to run automatically
  • also allow the server to push out wad files to the client as needed
    • server sends game setup info to the client HTTPd
    • client requests files from the server (nfs mounts?)
    • server instructs client to start a game, with correct WAD options
• Use perl HTTP server, or tinyhttpd (maybe with SSL and custom certs/shared secrets/HTTP authentication?)
• capture keystrokes in X for controlling the following:
  • volume up/down
  • screenshots (ingame and out of game)
• put screenshots in a common directory, then offer to upload them to a server, and create thumbnails for viewing locally on the machine
• add fortunes to the portaboom startup screen. mebbe even fortune -o too
• Use XResources to set properties in Tk dialogs. Things like Dialog titles, text labels and colors can be set with XResources? ( see page 64 from the X book 4 for more info )
• Use qjoypad for allowing the joystick to control the mouse cursor/keyboard
• force feedback driver for linux
• create a "package file" that can be placed on an NTFS filesystem. Then make boot CD's/floppies that will mount the NTFS partition on boot and mount the "package file" via the Linux loopback interface. The "package file" in this case can be read from and written to, as the NTFS drivers will support rewriting of files that do not change the original size of the files; a loopback file should expand itself to be as large as needed to hold all of the Portaboom base files plus any WAD files the user wants to add. See http://topologi-linux.sourceforge.net/index.php?menu=1 and http://marc.theaimsgroup.com/?l=linux-kernel&m=103089008129720&w=2 for examples. Maybe use this for storing configuration files and user created lists of WADS?

PortaBoom Specific TODOs

• clone boot images - http://pingu.salk.edu/LDP/HOWTO/Clone-HOWTO/index.html
• have getlibs.pl output it's list sorted by package, and output as a delimited list for further processing
• for each module, create a list of supported hardware, including mouse, joystick, sound, OpenGL 3D, etc.
• Convert portaboom modules (only TkBoom right now) to a wrapper script and a module, that way it can inherit the "look and feel" settings from PCC.
• create hashes of look and feel settings, then create a master hash with references to the other hashes
• Have expert mode display script status in a status bar, have beginner mode display status in a modal message box
  • create a debug module, that includes a function called debug_data_dump, which would dump any/all data structures currently being used in PortaBoom
• Use some Xsetrootimage program to set the root image of PortaBoom. For the inital boot, create a splashscreen image, so that the user has something to look at while Perl/Tk starts. For each PortaBoom module that runs, change the desktop so that the logo for that module is displayed on the desktop; this way, the user will always know where they are at in PortaBoom
• Add trademark to PortaBoom web page
• update-fonts-dir update-fonts-alias scripts will create the files that X needs when adding/removing fonts from the system
• create a PortaBoom package system (using packages listed on the PackageIdeas page), where each PortaBoom package gets put into it's own compressed file archive (cramfs/squashfs). The end user will be able to mix/match packages to build the final system
• modularize PCC and TkBoom so that the same front end script can be used to call the correct GUI module. Frontend can also check for the existence of the Perl Tk module before trying to run one of the GUI modules.
• make PCC a module (like TkBoom.pm), the launcher script reads config files, then calls the correct GUI module based on how the launcher script was called
• change dashes '-' to underscores '_' for modules listed in pcc.cfg, and change module parser so that it understands the changes; modules with a dash or underscore won't work as a Perl hash key
• netcards with a dash '-' not listed in display of cards
• Move all of the shareware wads to a squashed archive, remove them from the ISO
• load all of the functions from Common.pm into the %z hash as references, that way you can call functions from other modules that may not be able to see Common.pm
• change netmask in Network Setup to be a dropdown with netmasks already preset, instead of manually entering the netmask into the dialog, and having to check formatting of the user's entry
• recode all of the game modules so they return() to launcher.pl the command string (with arguments) of the application to run. This will free up memory used by the frontend launcher module. When the application exits, launcher.pl will then reload the last used frontend module
• add smbclient to PB image for testing/debugging
• use find's search algorithim as an example to filefind
• create a GooglePimp module, when the user selects a MAME game to play but doesn't have images for, the GooglePimp searches for that .zip file on the net, and downloads it automagically
• when PCC has $DEBUG set, it should call TkBoom with $DEBUG set as well (-d switch, or read it from %ENV).
• add a $DEBUG checkbox to all dialogs, which sets/resets $DEBUG in the %z hash, which will make all scripts enter/exit debug mode
• change hardcoding of kernel module paths to include the output of uname -r (release version) as part of the path, that way you'll never have to update the scripts for new modules paths
• add a box in Portaboom that shows a thumbnail of the selected game/application, i.e. Doom shows a Doom screenshot, xpilot shows a cropped screenshot of a spaceship
• use NVRAM for storing system settings (video, storage, etc.) between sessions. If the user selected framebuffer or NVidia instead of VESA driver, store that in NVRAM as well.
• create a warning message/disclaimer that syslinux can display on startup; possible video problems, author is not responsible for damage to computer, etc.
• write a game module API that describes exported functions and variables, for example:
  • share types and names
• for each PortaBoom module, write an XML guide to that module, and put the developer's info into it's own file, so it can be compiled standalone as a document of the module, and also included via a SYSTEM call in the PortaBoom Developer's Guide
• change the /etc/profile so that if a screen session is started, the PS1 prompt is changed, and a MOTD message is printed in the console window saying that the term running in PortaBoom is really a screen session and not just a normal term
• add a "Takes a few minutes" message to ldconfig and symlinks part of rc.S script
• increase width of PCC status labels (goes along with adding Module listbox)
• is there no exec call in the startx script?
• after obtaining an IP address, clear/replace Network Card Setup status box with a message saying the machine already has an IP
• after ifconfig is successful, print a message saying that the user can return to PCC; "Networking is configured, you may now return to PCC. Please press "Back to Network Setup" button"
• do a ping test (with 0xdeadbeef ?) to the gateway as a configuration test, report success/failure in status window, make $state call based on success/failure of ping test
• shell smbmount process never exits, causing umount to hang
• fix titlebar images on all submodules (sound config image is actually add/remove wads)