Matchbox -- a Small Footprint Window Manager

An anonymous reader writes "In this technical article at LinuxDevices.com, Matchbox project leader Matthew Allum introduces his creation Matchbox: a small footprint window manager for PDAs and other resource-constrained embedded devices. Allum recalls why he decided to embark on the project, outlines its key objectives, describes its architecture and unique characteristics, and ponders its future. Cool piece of software; good read."

Comments

Hm

[zapfie]

With the extremely limited real estate on small devices, why use standard window controls (title bar, close box, etc.) which take up space? I would think it would make more sense to have an application take up the whole screen, and provide some space-friendly way to switch between them.

Re:Low footprint and X

[lpontiac]

Don't get me wrong , I'm all for X on a desktop. But where in these devices is there a need for remote displays ?

Development work. With platforms like the Palm or Windows CE, you generally need to choose between working on an emulator (which is slower than the device) or the device (which gets irritating when you've been testing a UI for hours and would really, really like to be able to enter text quickly).

Being able to run the app on the handheld, but manipulate it on the desktop, would be very handy. I think recent Windows CE devices have this ability. (Most devices don't have enough bandwidth between the handheld and the desktop for it to be viable).

Remember that when X was first invented, your average Unix workstation was less powerful than today's PDAs (permanent storage and display size aside). I don't think it's too much overhead.

Re:If it's resource constrained, why run X?

[JordoCrouse]

like using the framebuffer device, or Qt/embedded

First of all, QT/embedded is just as bloated as X (maybe even more).

The framebuffer is a good idea, but by the time you end up implementing all the stuff you need to actually run a decent program, you have implemented most of the XLib anyway. Trust me, I have gone that route before.

X has its advantages when used on networks, like the client/server model, but it's overkill for personal devices.

Ok - first of all - if you want to run multiple apps in a window manager environment, you *need* to run it as a client/server setup - Thats exactly what you are looking at on a window manager - multiple clients running on a single server. IMHO, its much better to have a client and server than a monolithic application - less resources to be used.

Secondly, X uses this same client/server configuration on the desktop - and though some take advantage of the networkability of the protocol, most don't. Yet, nobody ever attacks RedHat or SuSE for using X in a client/server configuration.

Re:Low footprint and X

[batkiwi]

There's no greater feeling than firing up an IPAQ running X, ssh'ing to my power-machine with x-tunneling set up, then loading up mozilla/codeguide/gimp/other resource intensive program, and having it respond like a dream.

I actually see a need for it MORE on a tiny device, especially with wireless network adapters for IPAQs.

Mac OS X

[bdesham]

If anyone's interested, I just ported this to Mac OS X, so you can use this WM with XDarwin. You need Xfree86 installed (you can get it from Fink).

Untar and ungzip the package.
cd to the source directory.
With your favorite editor, edit utils/Makefile.am by deleting the reference to minivol on the bin_PROGRAMS line, and removing the minivol_SOURCES line.
Run automake, ./configure, make and make install.
Make the appropriate modifications to ~/.xinitrc.

Re:If it's resource constrained, why run X?

[dmiller]

X is a resource hog

Prove it!

My X is currently using 21M of my RAM (RSS). That is with 6 1600x1200 virtual desktops and a whole lot of windows open.

Seeing as how 21 * 2^20 * (6*1600*1200*4*2). It seems to be doing a very good job of managing resources. Much better than Mozilla (55M RSS) or Evolution (45M RSS).

Are you going to back up your assertion with numbers, your are you just going to recite the tired ./ mantra that "X is bloated"?

Re:Low footprint and X

[g4dget]

X11 is low footprint. X11 is smaller, for example, than a comparable Qt/Embedded environment. X11 is also very efficient: as others have pointed out, too: it was designed for machines less powerful than your PDA. The X11 protocol was hand-designed, unlike the RPC and distributed object protocols in vogue now, which have better tool support but bigger overhead as well. And X11 has been widely used in embedded systems over the years.

I think the reason why people think that X11 is big and resource intensive is because it scales up: if you allow it to (and most desktop installations do), it will take advantage of lots of memory and have all sorts of optional packages installed. Most likely your desktop X11 server includes various compression, image, 3D, and video functionality.

And X11 brings a lot of really useful features to the table. The fact that both client and server are user processes and are separate means that X11-based systems are very robust. The fact that window management and input methods are separate means that developers can really explore different options and pick the best for their device. For example, ]any handwriting input method developed for one X11-based handheld will work on almost any other, even if the user interfaces and toolkits are otherwise completely different. X11 is well-modularized.

The remote display capabilities are enormously useful for debugging. For example, you can prototype and debug your application on your desktop and just display on the handheld, in order to see how the UI works on a small screen. Or, you can have applications and development tools on the handheld pop up windows on the desktop.

Re:small and efficient

[JPriest]

It also uses Tiny-X server instead of the standard Xfree86, which I'm sure has quite a bit to do with the reason it's not huge and doesn't suck.

Re:No X for my pda

[kevin lyda]

wait, pda's are low power, low mem devices and you say they have no need for the remote display ability of x? really?

assume that a low memory foot print version of an x-server exists (and you should assume this since it actually does exist). assume your pda has a wireless card and a color screen (because many do). and let's say you're a web designer and you're in a meeting with just your pda and for some reason you need to do up a quick logo. so you fire off the gimp from your high powered desktop box and hae it display on your pda. you do up a quick logo using some gimp scripts and effects and then pass it around.

there, that's one use for remote display. now use you imagination and fill in the other 1 million cases where gui requirements are small and the stuff behind the gui are highly cpu and/or memory intensive. wait, i forgot java, make that 10 million cases...