mirror of https://github.com/0intro/wmii
116 lines
5.2 KiB
Plaintext
116 lines
5.2 KiB
Plaintext
DEVELOPMENT NOTES
|
|
|
|
Architecture;
|
|
|
|
1. Modularized design
|
|
|
|
wmii separates all concerns into different binaries.
|
|
To share code between the binaries we also got a bunch of libraries,
|
|
which are initially written for wmii, and all wmii binaries are
|
|
statically linked with those libraries.
|
|
|
|
* libcext (collection of useful C-API extending functions)
|
|
* libixp (remote interface library, obsolete)
|
|
* libixp2 (remote interface library, 9P2000 compliant - the future)
|
|
* liblitz (non-wimp GUI-toolkit library)
|
|
* libwmii (convenience functions for wmii-tools)
|
|
* cmd/wm/wmiiwm (core window manager)
|
|
* cmd/wmiibar (a generic bar)
|
|
* cmd/wmiimenu (a generic keyboard-driven one-line menu)
|
|
* cmd/wmiikeys (shortcut handler)
|
|
* cmd/wmiifs (libixp fileserver multiplexer, obsolete)
|
|
* cmd/wmiir (remote interface client for obsolete libixp)
|
|
* cmd/wmiir2 (remote interface client for libixp2)
|
|
|
|
liblitz contains all drawing code beside some geometry code, which is used by
|
|
all tools.
|
|
|
|
2. Remote interface
|
|
|
|
The remote interface is implemented in the libixp library, which
|
|
is independent from all other parts of wmii and provides a client/server
|
|
API for a userland memory filesystem with a similar approach as 9p
|
|
server- and clients of the plan9 operating system. Note that the old libixp is
|
|
obsolete and will be replaced by libixp2.
|
|
An IXP server provides and manages a memory file system (only the old libixp
|
|
does) which is accessed concurrently by several clients over a UNIX
|
|
socket file. wmiiwm, wmiibar, wmiimenu, wmiikeys and wmiifs are IXP servers,
|
|
wmiir is an IXP client.
|
|
An IXP server dispatches its connections with a select() based loop, it also
|
|
represents the X event loop for above components, because the
|
|
ConnectionNumber(X11) is the file descriptor of a connection to the X
|
|
server. If requested, the IXP server also selects() for file descriptors
|
|
provided by the server implementing developer and runs appropriate read()
|
|
and write() callbacks. In above components we need only a read()
|
|
callback for the ConnectionNumber, because the event handling of X is
|
|
single-directional and awakes if X writes data to that file descriptor.
|
|
The file system what the server manages, is capable to manage arbitrary
|
|
length paths, infinite files (as long as memory is available), and byte
|
|
content of files through following functions:
|
|
|
|
* create (creates file/path)
|
|
* remove (removes file/path)
|
|
* open (opens file)
|
|
* read (reads opened file)
|
|
* write (writes opened file)
|
|
* close (closes opened file)
|
|
|
|
Note above functions are obsolete, in future libixp2 provides full 9P2000
|
|
support due to following interface:
|
|
|
|
int ixp_client_init(IXPClient * c, char *sockfile);
|
|
void ixp_client_deinit(IXPClient * c);
|
|
int ixp_client_remove(IXPClient * c, u32 newfid, char *filepath);
|
|
int ixp_client_create(IXPClient * c, u32 dirfid, char *name, u32 perm, u8 mode);
|
|
int ixp_client_walk(IXPClient * c, u32 newfid, char *filepath);
|
|
int ixp_client_open(IXPClient * c, u32 newfid, char *filepath, u8 mode);
|
|
u32 ixp_client_read(IXPClient * c, u32 fid, u64 offset, void *result, u32 res_len);
|
|
u32 ixp_client_write(IXPClient * c, u32 fid, u64 offset, u32 count, u8 * data);
|
|
int ixp_client_close(IXPClient * c, u32 fid);
|
|
|
|
|
|
Technical Details;
|
|
|
|
1. Hint management
|
|
|
|
The window management of wmii conforms to the ICCCM specification,
|
|
although client supplied icons and iconified window states are not
|
|
handled for simplicity reasons and because they don't fit well with the
|
|
tiled window management.
|
|
Apart from this, wmii conforms partly to the EWMH specification to fit
|
|
well with the requirements of more recent applications in the area of
|
|
the KDE and Gnome desktop, although to fulfill these hints are no primary
|
|
target of wmii's window management capabilities.
|
|
|
|
2. Layout interface
|
|
|
|
wmii provides an C-API interface to extend the core window manager with new layouts.
|
|
See wmii/cmd/wm/layout_*.c for samples how to implement a layout.
|
|
|
|
The interface looks like:
|
|
|
|
struct Layout {
|
|
char *name;
|
|
void (*init) (Area *); /* called when layout is initialized */
|
|
void (*deinit) (Area *); /* called when layout is uninitialized */
|
|
void (*arrange) (Area *); /* called when area is resized */
|
|
Bool (*attach) (Area *, Client *); /* called on attach */
|
|
void (*detach) (Area *, Client *, Bool unmap); /* called on detach */
|
|
void (*resize) (Frame *, XRectangle *, XPoint *); /* called after resize */
|
|
void (*select) (Frame *, Bool raise); /* selection */
|
|
Container *(*get_frames) (Area *); /* called for drawing */
|
|
Action *(*get_actions) (Area *); /* local action table */
|
|
};
|
|
|
|
See wmii/cmd/wm/wm.h for further details about the structs.
|
|
See wmii/libcext/cext.h for details about the Container data
|
|
structure which provides a single linked list and a stack in one
|
|
implementation (list for navigation, stack for focus history) -
|
|
which is useful for frames, clients, areas and even pages.
|
|
|
|
To store arbitrary stuff in an area, there is an Area->aux
|
|
pointer, same can be done with frames, which contain a Frame->aux pointer.
|
|
Note that each layout implementation needs to create and destroy
|
|
frames by itself (this is required because otherwise a wmi-10
|
|
alike layout which assumes tabbing, won't be possible).
|