This page describes the Plan 9 version of Object Icon. This version does not use Plan 9’s Posix porting library (“APE”), but rather attempts to be a pure Plan 9 version, using Plan 9’s native features directly.
A full graphics implementation is included; however it requires a modified version of the rio window manager in order to work. This is called riox and is compiled along with the rest of Object Icon. It is described in full on this page.
The source code is contained on a separate branch, and can be obtained with the following command :-
svn co svn://svn.code.sf.net/p/objecticon/code/branches/plan9 objecticonThis directory must then be made available from within plan 9, either by copying it or sharing it via 9p (eg using the u9fs program).
This version has only been compiled and tested for x86. A compiler bug in the ARM compiler (5c) unfortunately prevents compilation for that architecture. See https://www.mail-archive.com/9fans@9fans.net/msg37252.html
Firstly, ensure that the sh program is available on your path. It can be found in /bin/ape, and is needed to run the test scripts. If it is not on your path, edit your profile to include the command :-
bind -a /bin/ape /binThen, from the checked out Object Icon directory, run the command :-
./configure.rcThis sets up the mkfiles and other configuration files. Now run
mk all testto compile and test everything. Hopefully at the end “Testing successful” will appear.
To add the Object Icon executables to your path, and set up the usual environment variables, it is necessary to “source” the paths.rc file from your profile file. For example, I have the following line in my profile :-
. /usr/rparlett/objecticon/paths.rcAs mentioned in the introduction, the modified window manager riox must be used with the graphics facilities.
One notable limitation relates to keyboard handling. riox reads keyboard input from the cons device, which simply produces a stream of UTF-8 characters. This means there is no way to tell when the user presses one of the modifier keys (shift, control, etc.), since these do not by themselves produce characters. In turn, this means that operations which rely on a modifier key being pressed together with a key or mouse button will not work correctly. Examples include shift and mouse or cursor key in a text area or list (to move the cursor whilst keeping the selection), and control and mouse in a list (to multi-select rows). Keyboard release events are also never generated.
A further minor keyboard problem is that the cons device generates a newline character (ASCII 10) when the return key is pressed. On X11 and Windows on the other hand, the return key normally produces the carriage return character (ASCII 13). For consistency therefore, a newline read from cons is converted to carriage return before being placed in a window queue. This unfortunately means that Control-J incorrectly produces a carriage return character, rather than newline.
The environment variable OI_USE_WIN allows the first window opened to take over the current window, assumed to be mounted in the directory given by the environment variable wdir (default /dev) . If OI_USE_WIN is unset, or is 0, then the current window is not used. Otherwise, it is taken over, and adjusted depending on the value :-
It is important that the program running does not produce output to the console, as this will overwrite the graphics drawn to the window.
Windows are mounted under the directory given by the environment variable OI_WIN_MNTGEN (default /n). A typical example of a mounted window directory might be /n/oix-win.543.1. Using mounted window directories presents a problem, however, which can be illustrated by running the following commands :-
% mount $wsys /n/win new
% page -w something.pdf # View any pdf (keep this window open).
% unmount /n/winYou would expect the last command to close the window opened by the first. But in fact it doesn’t appear to do anything. The reason for this is that the page command has, under the covers, copied the namespace used by the shell, by calling the system function rfork with the RFNAMEG flag. This means there are two references to the window mount, and the unmount command only removes one of them. The window thus stays open until the page window is closed.
There are several ways to deal with this problem, and to choose between them an environment variable OI_WIN_NAMEG is provided. If the variable is unset, or is 0, then oix will look under the directory indicated by the environment variable OI_WIN_WSYS (default /dev/wsys) for a directory corresponding to the window mount directory, and, if found, use it instead, after unmounting the window mount. Since there is no longer a mounted directory, the problem of “mount capture” doesn’t arise. The only drawback with this technique is that it relies on another window directory already being mounted and providing the alternative wsys directory.
If OI_WIN_NAMEG is 1 then the switch just described isn’t made, and the mounted directory is always used. This isn’t really a solution at all of course, but the option is there for completeness’ sake.
If OI_WIN_NAMEG is 2, then oix will use rfork(RFNAMEG) to copy the namespace, and then mount windows as usual. Because these mounts will be in a copied “private” namespace, these mounts cannot be captured by other programs. This option does however, have two disadvantages. Firstly, the program won’t be able to manipulate the original namespace, and secondly the rfork will potentially capture other mounts (it is odd that this solution can actually cause more of the original problem).
The Window.get_id() method returns the path of the directory on which the window is mounted. From this directory, all of the usual riox window files may be accessed, giving complete flexibility to the client program.
The Plan 9 implementation includes some classes for providing file system servers using Plan 9’s 9P protocol. Full details can be found on this page.
The I/O package exhibits some necessary differences in the Plan 9 implementation; these are detailed on this page.