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

Comments

What about wxWindows?

[csirac]

wxwindows

Re:What about wxWindows?

[csirac]

Oops, the wxWindows embedded link is:

http://www.wxwindows.org/embedded.htm

Google Cache For Entire Artical

[Sir Haxalot]

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

GPL Alternative to Qt/Embeddded?

[jryland]

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

Re:not under GPL for commercial developers

[listen]

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.

Re:GPL

[chrisv]

Qt is NOT under the gpl. it's a modified gpl that will NOT allow me to make a commercial open source application without paying gobs of money to them.

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:

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany with it the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany with it a written offer, valid for at least three years, to give any third party, for a charge of no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; ...

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

Not the solution for all needs.

[caseih]

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.