FBUI is a small, fast in-kernel GUI windowing system for Linux.
· FBUI exists to reduce the software bloat that plagues modern operating systems. It does this by virtue of its being a simple windowing system in the form of a small, 32 kilobyte driver which for some purposes may be quite sufficient. Liberation from bloat is desirable for a number of reasons that I explain in the Philosophy section.
· FBUI exists to assists people who are prohibited from using X Windows because they are using resource-limited platforms such as old computers and embedded devices. On these, X is an impossible burden. However a vanilla framebuffer is often too primitive. FBUI is "just right", and libfbui makes using FBUI even easier to use by providing abstractions and additional functions.
· FBUI exists to correct a flaw in the Linux operating system architecture. The traditional GUI -- X Windows -- is unlike any other subsystem of Linux in that the hardware-accelerated video drivers it uses are located within the X server, outside the kernel. Notice: normally Linux drivers and vital subsystems such as keyboard, USB, filesystem, serial I/O, et cetera are all located inside the kernel. FBUI simply puts the graphics UI driver where it belongs: inside the kernel with all the other drivers.
Here are some key features of "FramebufferUI":
· Unlike X Windows, FBUI supports windows on every virtual console.
· Each program may have more than one window.
· Overlapping windows are currently not supported, but I am adding support for them now.
· There is no concept of parent and child windows.
· Programs can receive raw keystrokes from FBUI which they can then translate to ASCII using a library routine. One process is permitted to have keyboard focus.
· Each process accesses its windows completely independently of all other processes.
· In X, the library has to send all drawing commands to the server process, which puts them in a queue and executes them whenever it has a chance. If the server is busy, or another X application is flooding the queue, then an X application must wait. Not so with FBUI, where the ioctl takes a list of drawing commands that go directly to be executed if the window is visible and irregardless of what any other window is doing. To further ensure the above concurrency is the norm, use of semaphores within FBUI to access common data is made as brief as possible.
· Each virtual console can have its own optional window manager process. But this is not necessary and for instance many programs that I've written are also designed to run in standalone mode, examples being fbcalc, fbview, fbscribble, and the my FBUI variant of mpeg2decode.
· I'm providing a fairly basic window manager fbwm, but current development is centered on fbpm, which is my panel-based window manager.
FBUI offers a sufficient set of drawing routines:
· draw point, line, horizontal line, vertical line, rectangle
· draw text (8-bit)
· window clear, fill rectangle, clear rectangle
· copy area
· put pixels (3-byte RGB, and 4-byte (unsigned long) RGB, and native)
· wait for event
· poll for event
· the window manager process can hide and unhide other processes' windows, move, resize, re-expose, and delete windows.
· read point
· FBUI is currently written for 8,16,24, and 32-bit directcolor and truecolor. I am presently adding 4-bpp VGA. (Note : on VESA, I've done testing for 24 bit only.)
Sample programs provided (I suppose I've gotten carried away) :
· panel-based window manager (current focus of work)
· conventional window manager
· JPEG+TIFF image viewer
· very simple MPEG playback based on circa 1995 MPEG2 library
· terminal emulator (based on ggiterm)
· load monitor
· "scribbler" drawing program
· analog clock
· simple calculator
· "Start" button program, which invokes fblauncher menu program
· POP3 mail checker
· "to do list" displayer program
· FBUI requires kernel 2.6.9.
What's New in This Release:
· This release adds overlapping windows and transparent drawing.