Slashdot Mirror
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."
wxwindows
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.
Trolltech are mistaken in that statement. They have released QT/E under the GPL, which means an aggregate product can be commercial, as long as it is distributed under the GPL as well.
IE, you can't make proprietary software without paying Trolltech. Commercial software is fine.
QT is most definately under the GPL. (According to the Free Edition of QT/Embedded 2.3.7, it IS GPL'd, and the GPL doesn't prevent commercial software -- it requires that you provide the source to said software and distribute it to those requesting the software:
-- quoted verbatim from the GPL.) It isn't under the LGPL, which allows for the linking of software that isn't under a GPL-compatible license with it (which includes commercial software). And, considering that a "commercial open-source application" can still be under an open-source type license in the first place (such as the GPL), there isn't a single thing preventing you from actually writing software for a device that uses QT/Embedded and Qtopia as it's GUI platform, provided all of it's software is released under a GPL-compatible license.It would also appear that MiniGUI is licensed under the GPL as well. The implications are the same as what you mentioned regarding QT, so I fail to see how MiniGUI is going to benefit you in any way more than QT/Embedded would. The parent poster is correct in this instance, in that the LGPL would have been more suitable for the software, but the licensing of the software is the prerogative of the author, and I'm rather indifferent to the whole thing anyway.
Basically, regarding both QT/Embedded and MiniGUI, as long as you follow the license agreement (in this case, QT/Embedded Free Edition and MiniGUI are both GPL'd), you are free to do as you please with them, including write for-profit software -- with the caveat that the GPL isn't much of a license agreement for purely for-profit software in the first place.
Dogma: Dead (mostly because your Karma ran it over)
Things are totally different in the embedded world. Most embedded companies want to standout by doing their own thing. As far as hardware support goes, embedded devices generally have a fixed set of hardware and often the devleopers write their own drivers. Also, we are not talking about Joe Home user here, these are developers and *should* have enough knowledge to look at all the options and choose which one is best for *THEM*. Why would the embedded market want what toolkits they use dictated to them? On the desktop I agree, picking one or two toolkits (QT, GTK+) and sticking with them is the best option. This pretty much what desktop Linux is doing. Sure there are other choices out there, but the majority of apps are GTK+ or QT. There is no problem with having tons of choices in the embedded world. It will only make it stronger and the embedded developers that can differentiate their products most should get the best sales.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
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.
screenshots here