MiniGui, GPL'ed Qt/Embedded Alternative
joshmccormack writes "MiniGui, a GUI for embedded Linux devices that offers a GPL alternative to QT/Embedded and other embedded guis has become a 'stable, viable alternative,' according to a recent Linux Devices article. Lots of screenshots on their site, including PDA apps, a web browser and a virtual console."
Ever heard about the Sharp Zaurus? The Zaurus series have Linux pre-installed. I own a SL-5500, and I'm really glad with it. I can do everything on it what I can do on PocketPC (including Word and Excell) + much and much more. Take a look at the Zaurus Software Index to see it for yourself.
- rastakid
In need of reliable and affordable server monitoring?
Is this to imply Qt/Embedded is not GPL?
Shouldn't it say, "an alternative to Qt/Embedded that is also available under GPL terms" ?
Qt/Embedded is dual licensed with the GPL being an avaiable way to license it. IMHO there is no need for an alternative that is an alternative just because it is GPL, Qt/Embedded is good enough.
John
Preferrably ones which reduce interaction to just tapping, and possibly simple / small gestures.
dragging should be kept to an absolute minimum, and there should be (almost) no need to double-click/tap.
Unfortunately, with the demise of PenPoint, dedicated pen UIs have become almost non-existent AFAICT---this project sounds interesting. Anyone able to contrast it w/ Berkeley's Graphical User Interface Research Projects (GUIR) which touch upon pen-enabled UI? (i.e., SATIN, SILK &c.).
This project is a case in point---why does an app on a pen-system need a window title bar? You're not going to be moving it, and surely you're not going to be forgetting what you've just launched, right?
Menus at the top which drop-down are also bad on pen-devices---click w/ the pen, and they appear under your hand, you then need to move away, look, find where to click and move back---this is one of the things which I hate about Windows for Pen Computing.
One UI which I think merits development is LCARS (Library Computer Access and Retrieval System), the ``Okudagrams'' from Star Trek: The Next Generation and later. While there are some programs out there modelled on this (including some commercial products licensed by Paramount), all-too-often it devolves to mere ``eye-candy'' (Berkeley Systems' StarDate anyone?).
Here's hoping someone adds a suitable widget set to this project.
William
Sphinx of black quartz, judge my vow.
I've said this everytime an article on yet another embedded framebuffer attempt is posted. While embedded solutions like MiniGUI and QT/Embedded seem like great ideas, they both suffer from the same problems. First off, all though I love the GPL and wish that everything were GPL'd, in the case of the windowing system/widget set, the GPL is not appropriate. LGPL is more appropriate. Because the widget set is part of the windowing envirnoment, you can't write code under any other license for the environment, because it's GPL'd. This right away will limit MiniGUI's viability, because for most embedded developes, it will not be an option. QT/Embedded, of course can be purchased to avoid this issue.
Secondly, like all embedded framebuffer attempts, this one yet again reinvents the wheel, defining a windowing system, event-handling, input-handling and so forth. And of course only programs using that exact API can run on this environment. This is a significant restriction that I find rather suffocating when I am using OPIE on my Zaurus.
For many devices, including handhelds, the best solution is still venerable X11. Keith Packard's KDrive server is completely self-contained (font support, XRender support) and weighs in at just 700 kb. Run a lightweight environment such as matchbox on top of that (wonderful window manager designed for handhelds) with a nice light widget set, and you have all the same features as this MiniGUI without the restrictions it imposes. See what the gpe people have done with this. It's impressive. In such an X11-based environment, MiniGUI could be viable because it wouldn't exclude any other toolkits or APIs from being used.
The final problem I see with MiniGUI is that code appears more complicated and MS-ish than QT or GTK. Clearly the developers come from a win32 background, as MiniGUI code is full of win32-isms, which I find harder to program and less elegant than the Signal/Slot mechanisms of QT and GTK.
Clearly, with or without X11 you need to change the widget look and behavior from that on a desktop. The idea of "windows" becomes less important as full-screen is the only desirable mode. Modifying the input mechanism is also important. Things that we take for granted on desktops such as right-clicking don't translate well to a handheld. QT/E and gpe solve this by having the user hold his stylus on the widget for a couple of seconds to emulate the right-mouse-button-click.
There is no perfect system, and MiniGUI appears to be yet another attempt and I'm sure has a valid niche to fill. I wish them well.