Slashdot Mirror
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."
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.
slashdot!=valid HTML
This is actually sleek and efficient. The gaps between interface widgets aren't TOTALLY consistent, but they're better than in most WMs. And all three of the themes look pretty nice, which is three more good themes than most window managers have. I will seriously consider using this for my window manager on NORMAL, non-pda unix when i get back up to college and am using Solaris regularly again.
:)
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.
I used to run FVWM on my iPaq, and blackbox on occasion. They work, but due to the limited screen realestate, and also the orientation (3:4 instead of 4:3 aspect ratio), they tend to not work as well as one would expect. Then I tried matchbox, and I must say, Mallum has done a really good job.
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
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 ?
The fact that no one understands you doesn't mean you're an artist.
The people running Linux on the iPaq aren't your average PDA users. Many of them run it exactly because they can get semi-standard networking and can run standard apps. Have you ever played (well, played is an understatement sicne I could only see the top left corner) starcraft on your PDA? You can only do it via a remote display unless you've found a way to efficeiently emulate an 80386 on a StrongARM (and make it fast enough to run the game and still have time left over for the display and such).
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
Yet Another Window Nanager
Sorry, couldn't resist.
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.
Do you have Linux and a DotPal? Click here now!
I use LWM. 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
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).
./configure, make and make install.
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,
Make the appropriate modifications to ~/.xinitrc.
Alcohol and Calculus don't mix. Don't drink and derive.
X is a resource hog
./ mantra that "X is bloated"?
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
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.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
And the Tandy Color Computer threw in multi-user on a 2Mhz processor and 128K of RAM.
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?!?!"
Article X: The powers not delegated... by the Constitution...are reserved...to the people
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...
US Citizen living abroad? Register to vote!