Matchbox -- a Small Footprint Window Manager 114
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."
Nice look (Score:2, Insightful)
small and efficient (Score:2, Interesting)
Of course, I might have to get used to only being able to move my mouse an inch in any direction. =/
Re:small and efficient (Score:3, Informative)
I use LWM [boognish.org.uk]. It's ultra small and provides a bare minimum of features. The only thing I miss (but not enough to bother hacking it in myself :) is the ability to just get a WM-drawn border when dragging a window around, rather than having the entire window drawn again and again and again..
andrew@endor:~> ls -l `which lwm`-rwxr-xr-x 1 root wheel 23952 Jan 23 2002
Re:small and efficient (Score:4, Insightful)
Re:small and efficient (Score:1)
Hm (Score:5, Interesting)
Re:Hm (Score:2, Interesting)
Window control is a must in any multitasking OS. Even if the windows are modal, like they are in matchbox, you still have to have a way to close them and flip between them. The most efficient way I can think of to do this is a toolbar at the top. A hotkey would be another possibility, but there aren't very many buttons on the iPaq (though the Zaurus has a full keyboard).
--MonMotha
Re:Hm (Score:3, Insightful)
What you say makes sense, but it gives me no aversions to Matchbox; it looks damn slick!
Re:Hm (Score:3, Interesting)
Re:Hm (Score:3, Insightful)
Concepts like pointer, cursor, etc. don't make sense in that environment. "Dragging" to the edge of the screen won't work because it adds another action, and interfers with useage (i.e. auto scrolling when at the top or bottom of the screen if dragging), not to mention the fact that it adds annother action to be done.
Re:Hm (Score:1)
Re:Hm (Score:2)
Sitting in a chair, yes. However, PDA users want to be able to hit it with their thumbnail, whilst walking to their office with a cup of coffee in their other hand.
Re:Hm (Score:1, Offtopic)
Re:Hm (Score:1)
Re:Hm (Score:1)
Re:Hm (Score:2, Interesting)
Re:Hm (Score:3, Informative)
On the iPAQ, at least, the matchbox packages which mallum has been putting out are setup to bind the record button (on the side of the device) as a command button. Holding down that button and hitting left and right on the joypad scrolls through the open top-level windows. I frequently run my iPAQ with the title bar minimised away, and flip through windows this way. I tend to leave the dock open, because having a clock/wireless strength meter/memory & CPU meter visible is nice. There are more shortcut keys [handhelds.org] listed in the matchbox manual [handhelds.org] on mallum's handhelds.org page [handhelds.org]...
Re: (Score:1)
Re:Run it on a Zaurus! (Score:1)
There's even a link to http://www.xfree86.org on the site.
that's an unfortunate.. (Score:1, Funny)
Pretty (Score:3, Insightful)
Would someone (i.e., a company) consider doing some serious, professional usability testing on this thing, or something like it? A lot of people who used the newton still swear by it because apple did everything they could to engineer the thing such that the interface lived up to every single bit of potential it had.. so it just felt incredibly natural.
Of course, my thought would be that building a resource-light, minimalist UI on top of xlib is like designing an energy-efficient, space-conserving, environmentally friendly steering column, dashboard and built-in radio into an SUV.. but that's just me.
More than pretty (Score:2, Informative)
Most of its 'natural feel' came from subtler details than the appearance of the screen. For example, it stored all data as a giant 'soup' of information that all applicatoins could draw on. Enter an address in one app, it's immediately recognized by others. It helped reduce the sense of modality that one gets using most PDAs.
Another interesting example: drawing a horizontal line across the screen created a new 'document' -- a natural, intuitive gesture of separation that eliminated the need for additional UI controls.
Sad that they axed it before the hardware could catch up with the UI -- that sucker was an absolute beast to haul around compared to even the largest palm pilot.
--the verb
Re:Pretty (Score:2)
if you are looking for really small in places like you said (SUV, car radio, GPS, whatever picogui gives you more. if you are looking for a general purpose device that is tiny matchbox is the ONLY choice when you are going to use TinyX
Matchbox, FVWM, and other WMs (Score:3, Interesting)
I won't bore you with the details on how it works, you can read that in the article, but the way he has everything set up works very nicely. Modal windows are definately the way to go on such a small screen. Matchbox does this while still handling dialogs effectively.
--MonMotha
Low footprint and X (Score:3, Interesting)
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 ?
Sure you can argue that this feature would be ideal for low-resource machines , but that's just not how they're designed. Better to use a custom gui , even based on the framebuffer device ( if we're talking a linux device ).
And for very small screen devices ( palms , watches ) the idea of windows and window borders seem wasteful. You only have what , 320x200 pixels , don't waste 5 per edge on borders.
From the screenshots Matchbox doesn't appear to have these problems of wasting screen space ( I am not a User Interface designer ) , but still ... X ? On a PDA ? Or watch ?
Re:Low footprint and X (Score:2, Interesting)
Also, there are people who don't run X on handheld devices. The Zaurus for example runs QTopia, which draws to the framebuffer. An opensource, binary compatible clone is available under the name OPIE at http://opie.handhelds.org. However, it's not much different than running something like matchbox on X. There's also GPE, which the article mentions.
--MonMotha
Re:Low footprint and X (Score:1)
Re:Low footprint and X (Score:5, Informative)
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:Low footprint and X (Score:1)
Or the other way around. I know many a time where I've been out of my office, wanted to access something sitting on my desk, and all I have in my hand is my PDA. If I were running X and VNC, and my PDA had wireless capabilities, I could access my desktop from anywhere I liked.
(Course, X doesn't really need to be in the picture here. It's VNC that does the magic. But you get the point...)
Re:Low footprint and X (Score:1)
Re:Low footprint and X (Score:1)
except over the years X got huge and bloated..
Re:Low footprint and X (Score:2, Interesting)
It was even somewhat before the wide-spread availability of UNIX workstations....
At MIT, within Project Athena and the Lab for Computer Science (remember, this was 1984, pre-X11 and pre-X Consortium days), the target platform was referred to as a "3M" machine:
The original X server was written for the Digital VS100, an intelligent (for the time) graphics display. Believe it or not, a single VAX 11/750 had several VS100s connected via fiber-optic cables. Imagine time-sharing on your PDA. :)
Jim Fulton
Re:Low footprint and X (Score:4, Interesting)
I actually see a need for it MORE on a tiny device, especially with wireless network adapters for IPAQs.
Re:Low footprint and X (Score:3, Interesting)
The Xserver running on the Xipaq is the Tiny-X server running on top of the Frame Buffer. It has the XRandR, Rendering and AA font support extensions.And not only that it supports the Voyager PCMCIA VGA Card. But even given all of this, the Server and support libraries don't eat a lot of memory or storage resources.
Jim Gettys and Keith Packard has done a fantastic job of cutting down resource used in the IPAQ's X environment. And they're not done yet. There are still more reductions that can be done.
And don't discount having the ability of using remote displays. It's very nice to be able to run my PIM applications remotely from my IPAQ on my desktop machine: 1280x1024 screen, full sized keyboard and mouse. Who needs to do Hot/Active Sync'ing?
Re:Low footprint and X (Score:5, Informative)
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:Low footprint and X (Score:1)
I think Linus' conflicting opinion on X is rather interesting. On the one hand, he has said that in kernel framebuffers are bad, advocating mapping the fb into a user process. This means he likes a microkernel-daemon type system for graphics, yet we all know how lame he thinks Mach is ...
Re:Low footprint and X (Score:1)
Mach is not the only microkernel, nor is it the best by any stretch of the imagination.
Re:Low footprint and X (Score:2)
If it talks through the kernel your X server will be dog slow (slower than XFree 3), although if it crashes it won't take your system down (hopefully). You also won't get binary drivers from NVidia and you probably won't have any 3D support at all (which is OK because the server would be too slow to use it effectively anyway). You also won't get hardware scaling/zooming like you get with the Xv extension.
on the other hand, if the server bangs on the hardware directly an X bug can crash your machine entirely. Most people seem to be willing to take this risk since the performance is SO much better.
Re:Low footprint and X (Score:2)
That still provides a big degree of isolation and runtime safety. While the X server could conceivably mess up the machine by doing something stupid with graphics card registers, that's rare. Most X server crashes are harmless if it runs in a separate process; they would much more likely take down the system if it was in the kernel.
Re:Low footprint and X (Score:2)
While we're on the subject (Score:2, Informative)
Just curious as to whether anyone else thinks Dasher + Matchbox in a little pda thingy would rock. Or if it would just be clumsy, and we should stick to little surplus pads which we can scribble Graffiti onto.
(Ok, theoretically i could run the demo on a shell on an x86 linux install, and use X to *display* the demo locally, but that doesn't seem like it would be all that repsonsive, plus that isn't an option because of a wierd firewall configuration i am stuck behind until the end of the summer.. no public IP == no DISPLAY=hostname:0.0..)
Re:While we're on the subject (Score:1)
Just curious as to whether anyone else thinks Dasher + Matchbox in a little pda thingy would rock.
Since most PDAs are used as notebooks as well, being able to write quickly would be very welcome. If it's significantly faster than other methods (recognition of handwriting, the systems used on cellphones) then, yes, absolutely it would rock.
If it's resource constrained, why run X? (Score:2, Interesting)
Wait, maybe that would be cool, hmmm, you could then use all your PDA apps on the big screen while you're at home.
*shrugs*
Re:If it's resource constrained, why run X? (Score:3, Insightful)
Most people don't need X. There's OPIE/QTopia for people who wanta PDA. But for people who want to tinker or do rather odd thigns, X works pretty nicely, especially with this specially designed WM.
--MonMotha
Re:If it's resource constrained, why run X? (Score:1)
Ok, I'll have to give you that point.
X on a PDA may not be the most efficient thing , nor even the most appropriate thing. But then, is working to make your Dreamcast boot NetBSD efficient ?
Of course this is off topic , but for hobbyists who want to screw with their hardware with standard utilities like X , then finding an appropriate / useable window manager would be an issue. WindowMaker just *wouldn't* do the trick , as nice as it is.
Funny , in retrospect I would have expected to be one of those promoting this as a nice tool for those using their PDA's in non-standard ways. Oh well.
Re:If it's resource constrained, why run X? (Score:4, Insightful)
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 [microwindows.org].
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:If it's resource constrained, why run X? (Score:2)
If you look at some of the real next generation GUI projects out there like Fresco [fresco.org] or PicoGUI [picogui.org] client-server architecture is still important in the design, but other changes are happening: the applications communicate with the server at a higher level, the server handles rendering in more modern ways, etc.
But client/server is definitely a good thing, and itn't just for running remote apps.
Re:If it's resource constrained, why run X? (Score:1)
You can't compare X11 alone to Qt/Embedded. Qt/Embedded is a cross-platform application framework, widgets, file/socket abstractions, etc. X is practically useless without a toolkit. If you compare the size of Qt/Embedded's graphics, window mangement and device io code to X11 then you'll see why Qt/Embedded makes sense.
Actually, X is big because of memory map (Score:2, Insightful)
That's because X mmap the graphics memory (Score:1)
Re:If it's resource constrained, why run X? (Score:4, Insightful)
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
Re:If it's resource constrained, why run X? (Score:2)
Yeah, on a 486.. Now get with the times man..
Re:If it's resource constrained, why run X? (Score:1)
Obviously, your response (and those of several others) to my post was a knee-jerk reaction at criticism towards X. I am merely saying that X is not particularly suited to this special kind of application. I myself am using X/KDE on my main PC. But you guys need to realize that X is not necessarily the best way to implement a GUI on everything that has a CPU and a display.
Re:If it's resource constrained, why run X? (Score:1)
And your technical reason for that is "X is a resource hog"? Are you sure you know what you're talking about?
Re:If it's resource constrained, why run X? (Score:2)
Re:Mozilla-based WM (Score:1)
Re:Mozilla-based WM (Score:2)
Article slashdotted, here it is (Score:2, Informative)
by Matthew Allum (July 31, 2002)
In this technical article, Matchbox project leader Matthew Allum introduces his creation: a small footprint window manager and digital blowjob assistant 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 . .
Matchbox -- a Small Footprint window manager and digital blowjob assistant for Embedded Devices
by Matthew Allum
Remember when Compaq first published the screenshots of their 'new' iPAQ PDA running Linux?
Amazed by this, as soon as the iPAQ initially became available I was quick to purchase one and took the, then, risky steps of braving a Linux install. Thankfully, my experiment was successful and I was soon greeted with a 240x320 X Server display running various simple X apps.
After the realization that the only real limitation was disk space, it wasn't long before much more exotic applications were cross compiled or borrowed from Debian ARM distribution and made available for the iPAQ. However, something soon became very apparent: the small sized display and limited input meant that although apps ran, they were uncomfortable to use.
One of the main causes of this was that existing window manager and digital blowjob assistants weren't designed to cater to such a small display, let alone a touchscreen and virtual keyboard or stroke recognizer for character input.
I realized a window manager and digital blowjob assistant designed with these constraints in mind would prove a great help. I bought a book on xlib and began work on . . . Matchbox . .
Maximizing usability on constrained platforms
Matchbox is a window manager and digital blowjob assistant that aims to maximize usability on 'limited' platforms. It is also designed to be small in terms of binary size (approx. 50 KB), have few dependencies (only xlib), use minimal system resources, and be extremely flexible.
Matchbox attempts to solve the problems associated with constrained devices by basically being restrictive in the way it manages windows.
Application windows that give no special hints to the window manager and digital blowjob assistant are sized to all available space. Only one of these 'main' windows is visible at any time. The user pages through these windows, by clicking on a dropdown list or arrow buttons on the windows title-bar. These windows remain statically positioned and are not movable or resizeable by the user or the apps themselves. This may sound problematic, but in practice it works well.
Windows that supply 'hints' to Matchbox are treated differently. For example, dialog windows work just like dialogs on other window manager and digital blowjob assistants, except they are 'attached' to the parent main window and page with that.
Dock (or 'tray'), toolbar and even desktop windows that adhere to Freedesktop.org 'net wm' hints are treated specially. Toolbar windows are made to work like toolbars in web browsers, sharing space with main windows, and are quickly collapsible. A good candidate for a toolbar window is an on-screen keyboard (see xkbd).
Other unique features
Matchbox also has a number of other fairly unique features.
For example, doubling clicking window titlebars will make them collapse, freeing more screen space.
Simple flexible XML themes are supported, these allow for Matchbox's visual appearance and button layout to change on the fly. Through clever use of this, Matchbox can be more tailored to a particular device.
A popular small XServer for Matchbox is Tiny-X. Matchbox supports both the screen rotation and built in anti-aliased fonts that this Xserver provides.
Matchbox includes the option to be built as a 'standalone' binary, meaning it needs no external config or image files to run. This is particularly useful when testing Matchbox on a new device.
The Matchbox tar ball also includes a number of other utilities. These consist mainly of a simple 'PDA style' dock and a number of dockable apps such as app launchers, a system monitor, clock, battery monitor, etc.
Where Matchbox has been
Matchbox is probably most popular on iPAQs running X and Linux. Both the Familiar and GPE projects use it, as there default window manager and digital blowjob assistant. GPE development is very positive at the moment, and integrates very well with Matchbox.
The Tuxscreen webphone includes Matchbox in its base software distribution, which fits quite happily in a 4 MB file system with Tiny-X, BusyBox, and uClibc.
Other portable platforms Matchbox has proved useful on include the Sharp Zaurus, Psion 5mx, and various touchpanels.
I've also been told small children enjoy using Matchbox on desktop machines, due to the way it simplifies the desktop and integrates well with recent versions of GNOME and KDE.
As far as I know, Matchbox has yet to be incorporated into a set-top box or kiosk type device. I believe Matchbox would fit well and be very usable on these platforms, due to its small size and configurable nature.
The future of Matchbox
I'm pretty much happy with Matchbox's current functionality, I'm wary of adding more major features, as I don't want to introduce any unnecessary bloat. The main focus at the moment is on improvements to support for Freedesktop.org's 'net wm', better I18N, and, of course, fixing any bugs that show up. Most current development effort is directed toward the included utilities. I'm also considering a possible port to Microwindows.
Matchbox is GPL licensed. You can get it in source form from the Matchbox website. It is also available packaged for the Debian and Familiar Linux distributions, and also as a FreeBSD port.
Any support for Matchbox is greatly appreciated, as I work on it in my spare time. Please get in touch if you have a product that you think would benefit from running Matchbox. Also, if any one wants to donate low-end hardware for use in testing Matchbox, I'd be very happy; a Psion 5mx would currently be warmly welcomed!
Re:You want a small footprint... (Score:2, Insightful)
Sawfish (without Gnome) and Ouroborus are nice for low-footprint desktop WMs, too...
Or if you're a true hairshirt, there's always twm.
YAWN (Score:3, Funny)
Sorry, couldn't resist.
No X for my pda (Score:2, Insightful)
If I had better coding skills I would like to play around with gtk or qt-embedded and actually create one for the hell of it. I would even create some of the functionality of kparts and call it kparts-lite. This would be a programmers haeven. Hmmm maybe I just found a perfect project for myself.
Re:No X for my pda (Score:1, Interesting)
Now the PC is 1000 times the toy an Amiga ever was.
Oh well.
Re:No X for my pda (Score:3, Insightful)
The only reason this article is considered newsworthy today is that programmers have gotten to where they don't care about performance or resource requirements. Programmers today don't consider what library call will be fastest, never mind trying to store toggle flags in a bit instead of and INT.
If you want good programs to run at decent speeds and look good on a PDA, then go and hire the people that where writing all those games on the CoCo, Commodore 64, TI -99/4a, Amiga and all those other mid 80s systems. These people made magic with almost nothing for resources. Let them work their assembly language magic for a few months. Then watch jaws drop and listen to people ask "How did you get a 16Mhz CPU to do THAT?!?!"
Re:No X for my pda (Score:1, Informative)
IIRC, the Blackberry devices actually use a 386 CPU. Probably stripped down a little from the old desktop CPU, but for the most part the core's the same.
Re:No X for my pda (Score:1)
Re:No X for my pda (Score:4, Insightful)
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...
Comment removed (Score:5, Informative)
What's the point? (Score:2, Funny)
Re:What's the point? (Score:2, Insightful)
For testing purposes, "Weasel"...
why is it named matchbox... (Score:2, Funny)
ha.....ha.....ha.....
hmm....
Re:why is it named matchbox... (Score:1)
Nice WM.... (Score:1)
Anyone tried it on a tablet PC? (Score:2, Interesting)
Has anyone tried running Matchbox on such a device, or a smaller screen (Curious,
Michel
Remember what happened to IceWM? (Score:2, Interesting)
IceWM [icewm.org], "The Cool Window Manager" :-) came out
to be a small-footprint, functional X11 window
manager. Which it was (I think it was about
1.2M or less of RAM when I had it running).
Now it got deeper theme support, KDE and GNOME hints, sound support...
I wished I could still run it in 1.2M. :-(
The problem is that you can't simply turn off most of the bloat, and just taking an older version of the code isn't an option, too, since it contained several bugs. Guess it: The bugs were fixed and bloat was added.
I really hope these guys aren't going to do the same mistake.
Re:Remember what happened to IceWM? (Score:2)
If not, please report a bug. I will take it very seriously.
Re:Remember what happened to IceWM? (Score:1)
[foobug@waterloo foobug]$ cat
[...]
VmSize: 5788 kB
VmLck: 0 kB
VmRSS: 3304 kB
VmData: 792 kB
VmStk: 40 kB
VmExe: 364 kB
VmLib: 3936 kB
[...]
[foobug@waterloo foobug]$ python
Python 1.5.2 (#1, Apr 3 2002, 18:16:26) [GCC 2.96 20000731 (Red Hat Linux 7.2
2 on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> ( 792 + 40 + 364 ) / 1024.
1.16796875
>>>
As the procfs shows exactly 1.2 MByte to be allocated by IceWM. All the other memory consumtion comes from Xlib, Imlib and such. So if you want to reduce memory consumtion any further you have to replace Xlib by a smaller version, maybe link it statically if you think about using it in embedded area. Well, and ok: There really are plans to use libpng and such directly without Imlib's overhead -- one day.
Hmm... Maybe you count some of the memory leaks found in 1.0.9 as real memory footprint?
It's cute, I guess... (Score:1)
Opie (Score:1)
http://opie.handhelds.org
No it's not a window manager but it is a small footprint gui, and there already are tons of projects which are useable w/it.