Slashdot Mirror

← Back to Stories (view on slashdot.org)

Matchbox -- a Small Footprint Window Manager

Posted by michael on from the hunt-and-peck dept.

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."

114 comments

  1. Nice look by B3ryllium · · Score: 2, Insightful

    I think that's actually one of the nicer WMs I've seen ...

    1. Re:Nice look by Anonymous Coward · · Score: 0

      It still suffers from the age-old ugliness factor that has affected all 'nix-based WMs since day dot. Ugly fonts. Big buttons with over-sized bevels. Backward mouse pointers.

      Same shit, different WM.

    2. Re:Nice look by Anonymous Coward · · Score: 0

      I thought that looked pretty damn sweet compared to other X WMs I've seen.

      Although, that's the first time I've seen a right-aimed default mouse pointer and it is kinda weird.

  2. small and efficient by Prizm · · Score: 2, Interesting

    After reading the article, it's apparent that this is very small and efficient code. Solid stuff! What I'm excited is, how long until somebody adapts it to linux for the desktop. A manager that rips through windowing operations - yum!

    Of course, I might have to get used to only being able to move my mouse an inch in any direction. =/

    1. Re:small and efficient by lpontiac · · Score: 3, Informative

      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 /usr/X11R6/bin/lwm
    2. Re:small and efficient by JPriest · · Score: 4, Insightful

      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.
    3. Re:small and efficient by minaguib · · Score: 1

      If you want a small, efficient and fast WM for the linux desktop do checkout FluxBox. The nice thing about it is that you don't need a desktop environment such as GNOME or KDE to make Fluxbox usable, since it provides an efficient built-in launcher. It's not appealing if you want bells and whistles, but if you want something that's fast and functional, do give it a shot.

  3. Hm by zapfie · · Score: 5, Interesting

    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
    1. Re:Hm by Anonymous Coward · · Score: 0

      It's all about the themes!
      You can theme the title bar, border, max/min/shade buttons and status bar but, you cannot theme the contents of the window.
      And since the most important feature of a window manager is how well it handles themes...you get title bars and little boxes with an X.

    2. Re:Hm by MonMotha · · Score: 2, Interesting

      Actually, it looks quite a bit like WinCE or QTopia. The window control widgets are very small and unobtrusive. As another poster mentioned, they're also themeable should you not like the boring defaults.

      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

    3. Re:Hm by pediddle · · Score: 3, Insightful

      Although Matchbox "wastes" real estate with titlebars, it uses them very smartly. As you can see from the screenshot in the article, the titlebars double as taskbars. If I ran KDE's kicker on my iPaq, I'd have no room left for anything. So, since everyone needs a taskbar in order to switch windows, and since I don't want to have to press a hard-button to do that, I think Matchbox does it very logically, in an interface with which everyone is already familiar.

      What you say makes sense, but it gives me no aversions to Matchbox; it looks damn slick!

    4. Re:Hm by Pig+Hogger · · Score: 3, Interesting
      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.
      The Windoze disappearing taskbar is a good point to start; why not have the improductive window border with all the scroll bars, buttons and whatnot disappear beyond the screen edge, only to appear when the pointer hits the side?
    5. Re:Hm by yasth · · Score: 3, Insightful

      because it was designed for mobile applications using styli?

      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.

      --
      I'd do something interesting, but my server can't handle a slashdotting.
    6. Re:Hm by zapfie · · Score: 1

      Agreed, but I think a taskbar style thing would work. You have a physical edge on the screen, so it would be easy for the user to hit this.

      --
      slashdot!=valid HTML
    7. Re:Hm by mgoff · · Score: 1

      sheesh. From the article: "Matchbox also has a number of other fairly unique features. For example, doubling clicking window titlebars will make them collapse, freeing more screen space."

    8. Re:Hm by Anonymous Coward · · Score: 0

      Just launch matchbox with '-use_titlebar no'

      -- mallum

    9. Re:Hm by clickety6 · · Score: 2, Interesting

      As you typically don't have many applications open on a handheld, isn't there a way to use the scroll button in combination with otehr buttons to either a) scroll the window b) scroll through open applications or c) scroll through the list of availbale applications?

      --
      ----------------------------------- My Other Sig Is Hilarious -----------------------------------
    10. Re:Hm by Dicky · · Score: 3, Informative
      As you typically don't have many applications open on a handheld, isn't there a way to use the scroll button in combination with otehr buttons to either a) scroll the window b) scroll through open applications or c) scroll through the list of availbale applications?

      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 listed in the matchbox manual on mallum's handhelds.org page...

      --
      Paranoia isn't an infectious condition, it's a way of life
    11. Re:Hm by lpontiac · · Score: 2
      You have a physical edge on the screen, so it would be easy for the user to hit this.

      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.

    12. Re:Hm by Anonymous Coward · · Score: 0

      this can fairly easily be done with for example the pwm window manager. on my ipaq, clicking on background brings up the root menu, and selecting an application lainches it (usually) in full-screen mode. some button is assigned to toggle between virtual screens.

      come to think of it, i do the same with xterm at home. full-screen xterms and alt- to toggle between desktops. no space wasted and lots of space for text.

    13. Re:Hm by zapfie · · Score: 1, Offtopic

      Good point..

      --
      slashdot!=valid HTML
    14. Re:Hm by zapfie · · Score: 1

      Sheesh? There's a reason I posted what I did as a question, not a statement. That's a nice feature, but it still doesn't address the question.

      --
      slashdot!=valid HTML
  4. Run it on a Zaurus! by gearheadsmp · · Score: 1

    I wonder how much faster it would be than X is with OpenZaurus for the SL-5500 PDA...

    1. Re:Run it on a Zaurus! by SocialWorm · · Score: 1

      No faster. Being a window manager, it should run on top of X, much like Sawfish.

      There's even a link to http://www.xfree86.org on the site.

      --
      My Blog: http://nic.dreamhost.com/
  5. that's an unfortunate.. by Anonymous Coward · · Score: 1, Funny

    ..name for an application: "dillo".

    1. Re:that's an unfortunate.. by Memetic · · Score: 0, Offtopic

      Why? now if it were dildo that might be but dillo?

      Nope, not laughing.

  6. Pretty by Anonymous Coward · · Score: 3, Insightful

    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. :)

    1. Re:Pretty by Lumpy · · Score: 2

      what you are looking for is picogui. it is a windowing manager/server/widgetset all in one that is 1/5th the size of tinyX+matchbox+Embedded GTK or whatever widget set you like.

      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

      --
      Do not look at laser with remaining good eye.
  7. borst prist! by Anonymous Coward · · Score: 0

    frit pork

  8. Matchbox, FVWM, and other WMs by MonMotha · · Score: 3, Interesting

    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

  9. Low footprint and X by Lupulack · · 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 ?

    --
    The fact that no one understands you doesn't mean you're an artist.
    1. Re:Low footprint and X by MonMotha · · Score: 2, Interesting

      Part of the reason for running X on these things is the fact that there's a HUGE amount of software instantly available. Remember, matchbox has modal windows for things other than dockables and dialogs. This elminates the problems with borders. When I ran FVWM I also turned my border width down to 2px.

      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

    2. Re:Low footprint and X by mr.+marbles · · Score: 1

      well to be fair they are using an implementation of X designed to be small and fast. http://www.linuxdevices.com/news/NS8925620279.html sounds like it's a good trade off to be able to run all the software writen for linux. and anyway if it wasn't X what would be the alternative? reinvent everything to shave off a few bytes?

    3. Re:Low footprint and X by lpontiac · · Score: 5, Informative
      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.

    4. Re:Low footprint and X by batkiwi · · Score: 4, Interesting

      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.

    5. Re:Low footprint and X by urulokion · · Score: 3, Interesting

      This isn't your Grandfather's X Windows.

      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?

    6. Re:Low footprint and X by g4dget · · Score: 5, Informative
      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.

    7. Re:Low footprint and X by SeanAhern · · Score: 1

      Being able to run the app on the handheld, but manipulate it on the desktop, would be very handy.

      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...)

    8. Re:Low footprint and X by MuMart · · Score: 1
      Fair enough, but ...
      The fact that both client and server are user processes and are separate means that X11-based systems are very robust.
      Most XFree servers bangs on the hardware, and I simply can't accept this as a good thing for a user process.

      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 ...

    9. Re:Low footprint and X by psychofox · · Score: 1

      PocketPC 2002 (the OS for the more recent iPAQ models) include a built in Microsoft Terminal Server Client. It works quite quite well, even over a mobile phone diallup.

    10. Re:Low footprint and X by Anonymous Coward · · Score: 0

      "X11 is smaller, for example, than a comparable Qt/Embedded environment."

      Yeah but that is just comparing apples to oranges.
      To use X you NEED to add libs for the toolkits your apps are linked with ( GTK, MOTIF etc .)
      Qte has it all build in.

    11. Re:Low footprint and X by naasking · · Score: 1

      This means he likes a microkernel-daemon type system for graphics, yet we all know how lame he thinks Mach is ...

      Mach is not the only microkernel, nor is it the best by any stretch of the imagination.

      --
      Higher Logics: where programming meets science.
    12. Re:Low footprint and X by Anonymous Coward · · Score: 0

      Uh, okay. What if I wanted to access a Unix box? Or a Mac? Microsoft Terminal Server is fine, but certainly not the cross-platform solution that people generally need.

    13. Re:Low footprint and X by jandrese · · Score: 2

      Well, you have your choice. You can either have your X server totally in userland, sending updates to the kernel through some API, or you can have it bang on the hardware directly.

      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.

      --

      I read the internet for the articles.
    14. Re:Low footprint and X by Suppafly · · Score: 1

      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.


      except over the years X got huge and bloated..

    15. Re:Low footprint and X by g4dget · · Score: 2

      No, I'm including those in the comparison. There are plenty of small toolkits for X11.

    16. Re:Low footprint and X by g4dget · · Score: 2
      Huh? X servers have talked to the hardware directly forever: the framebuffer and control registers are mapped into the X server process's address space, and it pokes around in there. There didn't even use to be any kernel API for doing anything with the frame buffer.

      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.

    17. Re:Low footprint and X by jimfulton · · Score: 2, Interesting
      Remember that when X was first invented, your average Unix workstation was less powerful than today's PDAs (permanent storage and display size aside).

      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:

      • 1 megapixel display
      • 1 MIPS processor
      • 1 MB of memory

      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

  10. While we're on the subject by Anonymous Coward · · Score: 2, Informative

    I remember seeing this incredibly cool alternate-input system for text on PDAs called Dasher on slashdot awhile back. here's the link. It has to take over the screen to function on a PDA, but, then, that's okay becuase so does the flp-up keyboard. (And on a tablet PC, it would rock.) It interested me because it was minimalist, yet used the device to the extent of its potential and looked at an old problem in a new way. Anyway, the project's awesome, i was wondering when if ever we might see that picked up as something widely embraced. There's windows and linux versions of a demo available, but i dont' think it will get very far unless the cambrige people creating it embrace open source. At the least, i can't run the demo because they only make binaries available, and my Linux install is not x86..

    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..)

    1. Re:While we're on the subject by jorleif · · Score: 1

      Hey, that seems really cool, has anybody tried using one of these? I mean how well does it work in practice and how fast can one type?

      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.

  11. If it's resource constrained, why run X? by Rolo+Tomasi · · Score: 2, Interesting
    X is a resource hog. There are more efficient ways to implement a GUI, like using the framebuffer device, or Qt/embedded. X has its advantages when used on networks, like the client/server model, but it's overkill for personal devices. You don't run Oracle on your handheld to store your phone numbers either. Or do you maybe want to connect an X Terminal to your PDA?

    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*

    --
    Did you know you can fertilize your lawn with used motor oil?
    1. Re:If it's resource constrained, why run X? by MonMotha · · Score: 3, Insightful

      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

    2. Re:If it's resource constrained, why run X? by Lupulack · · 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.

      --
      The fact that no one understands you doesn't mean you're an artist.
    3. Re:If it's resource constrained, why run X? by JordoCrouse · · Score: 4, Insightful

      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!
    4. Re:If it's resource constrained, why run X? by dmiller · · Score: 4, Insightful

      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"?

    5. Re:If it's resource constrained, why run X? by micahjd · · Score: 2
      I agree wholeheartedly. It's interesting how people clamor for a new GUI "because X sucks" and try to get away from client/server and toward using the framebuffer directly... but then you end up like something like GTK/framebuffer or DirectFB that, while nifty, aren't usable as a real windowing system because they have no way to arbitrate between multiple applications.

      If you look at some of the real next generation GUI projects out there like Fresco or PicoGUI 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.

      --
      -- 2 + 2 = 5, for very large values of 2
    6. Re:If it's resource constrained, why run X? by ainsoph · · Score: 2

      X is a resource hog.

      Yeah, on a 486.. Now get with the times man..

    7. Re:If it's resource constrained, why run X? by MartinJ · · Score: 1
      First of all, QT/embedded is just as bloated as X (maybe even more).

      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.

    8. Re:If it's resource constrained, why run X? by kevin+lyda · · Score: 2

      x is a resource hog? prove it.

      --
      US Citizen living abroad? Register to vote!
    9. Re:If it's resource constrained, why run X? by Rolo+Tomasi · · Score: 1
      If you had read and understood both the article and my post, you would have realized that we are talking about using X on resource constrained devices, i.e. PDAs. Those have commonly not more than 32 MB of RAM. They also don't have a harddisk, and their CPU power is maybe comparable to a slow Pentium, and that's for the high-end models.

      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.

      --
      Did you know you can fertilize your lawn with used motor oil?
    10. Re:If it's resource constrained, why run X? by Anonymous Coward · · Score: 0

      No, X11 is not a resource hog. Go back and redo your homework. In fact, most X terminals have far fewer resources than today's PDAs, and support far greater resolutions.

    11. Re:If it's resource constrained, why run X? by Anonymous Coward · · Score: 0

      When the X server is made well, like on my 33MHz Personal Iris it kicks ass (watch powerflip run!!!!!)

    12. Re:If it's resource constrained, why run X? by alienmole · · Score: 1
      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.

      And your technical reason for that is "X is a resource hog"? Are you sure you know what you're talking about?

    13. Re:If it's resource constrained, why run X? by Anonymous Coward · · Score: 0

      He is probably thinking back to the good old days.. I remember running X on an old computer when I had Slackware installed. There was only 16 megs of RAM total and X used most of it, and it slowed the computer to a crawl.

      These days X is still large but the personal computer has caught up to it and passed it by, so it is no longer an issue.

      It is still my least favorite program though. After all these years it is still an enormous pain to configure. You'd think it would be able to figure out a Matrox video card + Viewsonic monitor + MS usb mouse with no trouble at all, but of course not... Oh well, maybe some day.

    14. Re:If it's resource constrained, why run X? by Anonymous Coward · · Score: 0

      What the hell are you calculating, exactly?

    15. Re:If it's resource constrained, why run X? by Anonymous Coward · · Score: 0

      I'll believe X is slim when it runs smoothly on a 16 meg or 8 meg machine.

  12. Mozilla-based WM by Anonymous Coward · · Score: 0

    After reading the article two days ago about the linux GUI, I came up with the idea for a WM based on Mozilla. It would be a skinable interface with the bulk of the information in XML/HTML and CSS. When a user clicks on a program to run, the program would start and the command-line used to start it would be shown in a lower console window, allowing people to learn linux better as they use it. The mozilla interface would drop down from the top of the screen, overlaying the entire screen with a semi-transparent layer. Very simple to program, I'd guess, and very simple to provide skins for (mozilla theme + css). If anyone shows interest in the idea, I'll post the link to a mock-up I did in Photoshop. I'm a Perl/PHP hacker, so I don't know how to get started on the project, though. :/

    1. Re:Mozilla-based WM by bzzzt · · Score: 1

      And people think X is bloated...

    2. Re:Mozilla-based WM by Anonymous Coward · · Score: 0

      some company's already done this. i think they're out of canada, they sell all-in-one imac looking lunix computers.

      or they did, they're prolly out of business, just like every other lunix company..

    3. Re:Mozilla-based WM by BitwizeGHC · · Score: 2

      Don't you remember GW-BASIC? How about COBOL? Scary...

      --
      N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
    4. Re:Mozilla-based WM by Anonymous Coward · · Score: 0

      This is all well and good, but...

      Would you use a window manager written by someone with a ginger beard?

  13. Article slashdotted, here it is by Anonymous Coward · · Score: 2, Informative

    (non-k-whore AC)

    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!

  14. You want a small footprint... by tellurian · · Score: 0, Troll

    I give you FVWM2. Here's my screenshot.

    The Grid Report

    1. Re:You want a small footprint... by hazyshadeofwinter · · Score: 2, Insightful

      FVWM is snazzy and all, but it tends to lose a little of that leanness if you try to implement too much of a fancy config (ie by running fvwm-themes). Still, I got a kick outta using PipeRead + awk + cda to implement a point & click, CDDB aware CD player in my wm menus.

      Sawfish (without Gnome) and Ouroborus are nice for low-footprint desktop WMs, too...

      Or if you're a true hairshirt, there's always twm.

      --
      Click here if you just like to click on shit.
  15. YAWN by WhaDaYaKnow · · Score: 3, Funny

    Yet Another Window Nanager

    Sorry, couldn't resist.

  16. No X for my pda by Billly+Gates · · Score: 2, Insightful

    Is it just me or does resource-constrained and X sound like they do not belong in the same sentence. I for one would like a slimmed down desktop environment then just a simple window manager on a bloated X. X was designed for server/terminal archicture and is not needed for pda's. I know a slimmed down programmable desktop environment is possible because of the original mac. With a 6mhz processor and 128k of ram it could run with a desktop environment, networking, and its own apps! Of course 256k or 500k was more optimal back then but I look at old 80's computers as todays pda's. Infact today's pda's are more powerfull with 4 megs of ram and 16 mhz processors which are as fast as 286's and some of the early 386's. If it could be done like the original mac and Windows 2.0 then it can be done with pda's.

    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. :-)

    --
    http://saveie6.com/
    1. Re:No X for my pda by Anonymous Coward · · Score: 1, Interesting

      The original Amiga, the 1000, even threw in true multitasking and multimedia in 1985 with the same specs. Of course, the Mac/PC crowd was into monochrome screens and bleeps back then, so the Amiga was considered a "toy".

      Now the PC is 1000 times the toy an Amiga ever was.

      Oh well.

    2. Re:No X for my pda by Anonymous Coward · · Score: 1, Informative

      Infact today's pda's are more powerfull with 4 megs of ram and 16 mhz processors which are as fast as 286's and some of the early 386's.

      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.

    3. Re:No X for my pda by gerardrj · · Score: 3, Insightful

      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
    4. Re:No X for my pda by Hadlock · · Score: 1

      i was wondering when someone would put a .13 micron 386 in a PDA...

      --
      moox. for a new generation.
    5. Re:No X for my pda by kevin+lyda · · Score: 4, Insightful

      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!
  17. Mac OS X by bdesham · · Score: 5, Informative

    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.

    --
    Alcohol and Calculus don't mix. Don't drink and derive.
  18. why is it named matchbox... by skydude_20 · · Score: 2, Funny

    because in developement the software would still overwork the processors causing them to flare up and make the PDA's burn away like burning Matchbox

    ha.....ha.....ha.....
    hmm....

    --
    Jesus saves souls and redeems them for valuable cash prizes
    1. Re:why is it named matchbox... by MonMotha · · Score: 1

      Flamebait...somehow that maked it even funnier than the first time I read it. Honestly folks, I found that quite hilarious having used matchbox. It's definately one of the lighest window managers I've used. --MonMotha

  19. Actually, X is big because of memory map by edyu · · Score: 2, Insightful

    The reason a lot of people say that X is a memory hog is because when they run top, all they see is X. In fact, X is a hog because X mmap the graphics memory and pixmaps to be more efficient. If you take away these, X is quite efficient. Of course, for the ultimately efficiency, Matchbox is GREAT! I just want to point out some of the misunderstanding out there.

  20. That's because X mmap the graphics memory by edyu · · Score: 1

    X looks big when you run 'top'. But the truth is that X memory maps the whole memory on the graphics card plus it caches a lot of the pixmaps other programs use. In essence, if you strip away these things that is not part of X, X is quite effient. Of course, it will never be as efficient as a stand alone windowing system, but it is very efficient considering the good things X has. Of course, I applaud the efforts for Matchbox; it looks GREAT! And it does what it intends to very well.

  21. Now... will it burn Windows CE? by xactoguy · · Score: 0

    Now.. the only question is... will it whip out a virtual match and burn windows CE to bits, or any other incarnation of windows which can be run on a PDA? :)

    --


    And so we go, on with our lives
    We know the truth, but prefer lies
    Lies are simple, simple is bliss
  22. Re:How does this stack up to Yuuki? by Anonymous Coward · · Score: 0

    I'll tell you this much, it's ten times better than TWM. In fact I would venture to say it's better than RedHat's Loopback Window Manager.

  23. More than pretty by the_verb · · Score: 2, Informative

    It's interesting that you should mention the Newton... IIRC, it completely abandoned the concept of windows.

    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

  24. What's the point? by Weasel+Boy · · Score: 2, Funny

    Who would run a lean, small-footprint second window manager ON TOP OF the first window manager that already takes 75% of their CPU resources? What is the world coming to? We already have window manager managers. I suppose someone might want to use Matchbox for their window manager manager window manager.

    1. Re:What's the point? by gregorio · · Score: 2, Insightful

      Who would run a lean, small-footprint second window manager ON TOP OF the first window manager that already takes 75% of their CPU resources? What is the world coming to? We already have window manager managers. I suppose someone might want to use Matchbox for their window manager manager window manager.

      For testing purposes, "Weasel"... :D If you can run the WM on Windows, programmers inclined to develop systems using your Window Manager, because this way they can test the solutions wherever they want to.

  25. Nice WM.... by bezza · · Score: 1

    ...but they should really change the name of that web browser...I know I got a little bit confused (and excited I may add) when I saw it for the first time!

    --
    WARNING: This sig does not contain a joke
  26. Re:Why is this front page news? by Anonymous Coward · · Score: 0

    Nobody gives a fsck what you have to say. Do you think just because you wrote a window manager, you'll get a Sourceforge site? Hell no. These guys at Matchbox have talent, you don't. Your best bet is to shut your hole and don't post on Slashdot again. PUSSY

  27. Anyone tried it on a tablet PC? by salimma · · Score: 2, Interesting
    I'm getting one of those ProGears that Mira2Go is fire-selling - Transmeta TM3200/400MHz, 10.4" TFT, portrait/landscape mode, Slackware 7-based OS.

    Has anyone tried running Matchbox on such a device, or a smaller screen (Curious,

    Michel

    --
    Michel
    Fedora Project Contribut
  28. Remember what happened to IceWM? by Antity · · Score: 2, Interesting

    IceWM, "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.

    --
    42. Easy. What is 32 + 8 + 2?
    1. Re:Remember what happened to IceWM? by CaptnMArk · · Score: 2

      You should still be able to get close to the old size by using appropriate configure options.

      If not, please report a bug. I will take it very seriously.

    2. Re:Remember what happened to IceWM? by tbf · · Score: 1

      Hmm? Even BloatWM (that means 1.2.1/CVS with all experimental options) is on this 1.2 MByte barrier:

      [foobug@waterloo foobug]$ cat /proc/$(/sbin/pidof icewm)/status
      [...]
      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?

  29. It's cute, I guess... by ruhk · · Score: 1

    But it looks, to me, an awful lot like Qtopia, except the 'menu' button in the lower left is a lot bigger. So... what's the point?

    --



    404 Error: .sig not found.
  30. Opie by Oriumpor · · Score: 1

    Why bother there already is such a thing at:
    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.

  31. Article doctored by Anonymous Coward · · Score: 0

    Hmm: sed "s/digital/digital blowjob/g" article > article-poted