Name

draw, initdraw, ⋯ ­ Graphics

Synopsis

#include <dlib.h>

void draw(Image*, Rectangle, Image*, Image*, Point);
Point runestring(Image*, Point, Image*, Point, Font*, Rune*);
int runestringwidth(Font*, Rune*);
int flushimage(Display*, int);
int getwindow(Display*, int);
int initdraw(void(*)(Display*, char*), char*)
Image*      allocimage(Display*, Rectangle, ulong, int, ulong)
Mousectl* initmouse(char*, Image*);
int readmouse(Mousectl*);

⋯

Description

The draw library is a port of the Plan 9 one to Plan B. This manual page documents the most relevant differences. The aim of the port is to let Plan B run graphical editors/environments to test the system with daily work. A real implementaion for Plan B would probably include important changes so that the state of a term(4) device could be copied/linked to a different one. The current implementation can cope with that only by requesting a refresh to the application.

The interface is mostly unchanged. The most significant change is that the Plan B library steals the “conneciton” to the graphics device (see term(4) for information of such device). This means that if several processes are using graphics on the same terminal box, only the first one must initialize the graphics library.

As a consequence, there is no need to terminate the connection, because there is no connection in the Plan B version. The terminal device releases any previously allocated resource before accepting initialization from a newly arrived process.

Several routines using files/file descriptors in Plan 9 have been changed to use box names/constraints. Routines converting formats (images) operate on memory buffers and not of file descriptors.

Fonts are placed under the /port/lib/font directory in Plan B. The distribution does not contain the font hierarchy, which can be easily copied/bound from a nearby Plan 9 distribution.

Source

/src/libdraw

See also

term(4) and slider(1).

Bugs

Only the routines used by the library itself, and the ones needed by slider(1) have been heavily tested. Those functions should be enough for most applications to be ported to Plan B in a near future, e.g. editors.

Regarding documentation bugs, guess which manual page should be completed?