The GNOME Foundation announced today the GNOME Mobile and Embedded Initiative (GMAE) today at the Embedded Linux Conference in Santa Clara, Calif. The initiative is aimed at bolstering GNOME usage as an embedded and mobile development platform. The initiative has been in development since last year, says GNOME Foundation board member Jeff Waugh. The platform will be distributed under the GNU Lesser General Public License (LGPL). In the next 12 months the group plans to add a mobile email framework called Tinymail, the GeoClue geolocation service, Java Mobile & Embedded (Java ME), PulseAudio audio management, and the HAL hardware information system.
GNOME Mobile and Embedded Initiative Launched
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Very nice, does this mean it could one day replace (read: unite) platforms like maemo and openmoko?
There is already an iniciative to do this.
Maemo is already partly Gnome based.
Is it a feasible idea? The GTK+ toolkit is pretty taxing on system resources, and I quote from the article:
Although if they can overcome this, then it would be a really nice platform to see, especially if you could use it on the Linux-based Nokia phones.
Edited 2007-04-19 20:55
Optimising Cairo on non-FPU devices is one of our success stories, working together as a developer community, before GMAE was announced today. 🙂
Besides that, the ARM11 based SoC’s are gettng more popular by the day, and most of those tend to include FPU anyhow….
Now, I don’t mean optimizing isn’t worth it
Nokia already use (a subset of) GTK and Gnome on their N800 linux internet tablet, so they certainly have experience.
It’s certainly feasible: we’re doing it in the ACCESS Linux Platform, Nokia’s doing it in the N770 and N800, Vernier’s doing it on their data acquisition device…
I’d also mentioned to Zonker–and this point didn’t come out strongly enough in an otherwise-excellent article–that the upshot of our discussion around GTK+ (and particularly, Cairo) performance was that the developers reworked the code significantly to offer another approach for systems without hardware floating-point support, a change which went in around v2.16 of GTK, I think. So GMAE has had positive, measurable impact, in the code, even before we officially announced our existence. Like I keep saying, we’re all about the code.
Matt Allum of OpenedHand presented on “X (Without a Desktop)” yesterday as well, and mentioned that they’ve gotten a whole X stack (fonts not included) into 1 meg of RAM.
We’re planning on getting more “mobile-relevant” additions, adaptations and applications, even, included in the GNOME v2.20 release, coming this September. And, as jdub correctly pointed out at the announcement, we’re not talking about a “toy version of GNOME” in this context, we’re talking a full-on stack, potentially–although it’s noteworthy that the stack is quite modular, and it’s possible to pick and choose the pieces you need.
I don’t expect, for example, that anyone’s going to run the GNOME desktop itself on a cellphone or media player. But the user interface on those devices can still take advantage of the goodness of GTK+, Gstreamer, etc.
(They’re aren’t, by the way, any “Linux-based Nokia phones” that I know of, just the web tablets. All the phones run Symbian.)
I’ve done it on a Zaurus just to prove it could be done. Reminded me of the dancing bear, only a lot slower.
You haven’t lived until you’ve brought FireFox up on a QVGA screen.
Gnome on the mobile? Gnome on embedded devices ? I hope they can make it fit ? I am running gnome 2.1x on 256MB,PIII and they want to fit this on an embedded device. It’s not like they have an integrated toolkit like Qt, or platform like Java to “cut back”, but they have a full desktop environment that is not as well integrated as the above examples to cut back ? That’s a lot of work and hacking. I hope the company adoption follows to make this expensive community effort worth it
The GNOME Platform is very modular, that’s one of the reasons it’s such a popular choice for embedded work. For a simple embedded device, there’s no reason to have more than 32MB RAM for the GNOME Mobile Platform, X and your application. All of the optimisation and performance work happening in the embedded space is improving GNOME for your PC! 🙂
For a simple embedded device, there’s no reason to have a gui.
The overwhelming majority of embedded devices don’t have any UI. That’s part of what “embedded” meant before the market-droids got their claws into the term.
Um, dude, given that this is a user experience platform, we’re kind of assuming a requirement for a GUI… That’s the entire point of the GNOME Mobile Platform. Sure, you’re unlikely to need a GUI in your industrial refrigeration system… So you’re not going to be looking in our direction anyway.
Are you talking about “this”, or “simple embedded device”? I was talking about simple embedded device.
🙂
Don’t be fatuous. Clearly I was referring to any simple embedded device that requires a GUI, considering the context of the discussion – a user experience framework for mobile and embedded devices.
You were referring to an empty set. A “simple embedded device” never requires a GUI. Once you reach the complexity where you have a GUI you’ve gone beyond simple.
Pointless drivel semantics.
“””
You were referring to an empty set. A “simple embedded device” never requires a GUI. Once you reach the complexity where you have a GUI you’ve gone beyond simple.
“””
I hate arguments like this! 😉
Define your terms unambiguously and the “argument” will almost certainly evaporate.
If “simple” implies “no GUI” that’s cool as long as everyone agree that is what the term means in the context of the discussion.
On the other hand, “simple” could mean that the gui needs to act as a simple menu system to launch a simple chronograph app with start/stop/lap/and reset functions. No OpenOffice.org or anything like that.
“Simple” is a wildcard term that needs to be operationally defined before the discussion can even begin.
(I think that the post I am responding to does a good job of clarifying Cloudy’s definition of “simple”.)
Edited 2007-04-20 19:03
> For a simple embedded device, there’s no reason to
> have more than 32MB RAM for the GNOME Mobile
> Platform, X and your application.
Umm… 32MB of RAM is a *LOT* for an embedded device. A simple embedded device – even one that needs a GUI – is still far below that.
Also, I consider X and GNOME to be overkill for embedded stuff, let alone for *simple* embedded stuff. The whole concept of a window manager, or a network-abstracted GUI, don’t make a lot of sense for embedded devices (special cases aside). I’d rather invest some effort into a device-specific GUI than port something that is encumbered by features I don’t need.
You don’t need a window manager at all to deliver a gtk+ app. And X is not large when the cruft is removed (limited fonts, single driver, etc.). I believe you can even put gtk+ directly on the framebuffer, but I’m not sure it is that advantageous.
Overkill? If you need wifi, tcpip, video and sound, and a graphic user interface with limited resources, you cannot do much better than choosing linux+gstreamer+gtk.
If it is overkill for your app, rest assured that the police won’t come to arrest you if you use something else. Surely there are simpler embedded GUIs for embedded devices, but they all tend look like shit and offer far less functionality (think of most cameras or mobile phones), so they are not quite in the same league. Plus, they are usually proprietary and very expensive, and you have to do a lot of work to implement them in your hardware.
For those apps that can afford it, it may be the best choice, and it keeps getting better all the time (memory reductions, non-FP optimizations, library consolidation etc). Qt is also there, of course, so you have other similar choices.
> You don’t need a window manager at all to deliver a
> gtk+ app. And X is not large when the cruft is
> removed (limited fonts, single driver, etc.). I
> believe you can even put gtk+ directly on the
> framebuffer, but I’m not sure it is that
> advantageous.
“not large” is relative. If you throw X out completely and let the application talk directly to the hardware, you can do a GUI in a few kilobytes of memory. The frame buffer itself would be the largest part. Streaming video is of course another beast, but then anything that does streaming video is most probably not a simple, lightweight embedded device.
> Overkill? If you need wifi, tcpip, video and sound,
> and a graphic user interface with limited resources,
> you cannot do much better than choosing
> linux+gstreamer+gtk.
As I said, streaming video has heavy demands anyway. I don’t know about Wifi. As for tcp/ip, uIP somes to my mind (the thingy used in Contiki), again with a few kb of RAM usage. That’s a bit too stripped-off, but you get my point. Sound depends on what you want – high quality media playback is in a similar category as streaming video, but simple sounds for UI feedback or alerts need almost nothing. Computing power can be similarly low.
> If it is overkill for your app, rest assured that
> the police won’t come to arrest you if you use
> something else.
Likewise, if you can handle the footprint of GNOME on an embedded device, go for it. You’ll certainly save yourself some headache. I just think that 32MB memory requirements are a bit too high for most devices.
What is your point? I don’t understand where are you trying to get.
I understand you are saying there are many systems where Gnome wont fit. OK, so what? In these cases, something leaner, with less functionality will have to be chosen. Are there such options available? Hell, yes! Do they offer similar functionality? Well… no.
What is important about this gnome embedded initiative is that it is very difficult to get the functionality and performance of linux-x-gtk-gnome from a software system that uses less resources. If you’ve got less resources than this stack needs, then you’re going to have to settle for less.
Again, Qt may be a good option, but this thread is about gtk and I don’t want to muddy the waters.
10×10 is possible, this is great day for GNOME
10×10 is possible, this is great day for GNOME
Hmmmm. I think we should all be over the buzzphrases by now ;-).
Seriously, what’s the point?? Embedded and mobile platforms implies low speed CPU and low memory capacity. If people are thinking about porting GNOME to those devices, they should start with the basics and rewrite the whole thing from scratch, because it is full of bloat and shoddy C code. When was the last time you tried running GNOME on a 64-bit big-endian architecture like UltraSPARC? You can’t, compiled as a 64-bit binary, Metacity dumps core with “Bus Error”. I wouldn’t run GNOME on my desktop, let alone a mobile device like my phone.
What do you think people running on Nokia 770 & N800, OpenMoko, OLPC and many others?
Even though feeding trolls is a bad idea…
http://www.maemo.org/nokia/contributions.html
http://gpe.handhelds.org/
http://openmoko.org/
http://o-hand.com/
Gnome proper wasn’t really designed for embedded devices, but gtk gets all kinds of use on cell phones and embedded hardware. The biggest problem was speed with Cairo, but that has been mostly solved with the new tesselator and some hardcore optimization work. Kudos to Carl Worth and the Cairo team.
Don’t tell this to Sun, GNOME is default desktop in their Solaris.
Yes, I agree Gnome is very modular, we used to have a project wherein we ported Gnome into a little device. This is a noobish question, but has anyone done any KDE embedded programming?
I’ve built KDE in a stripped down uclibc gentoo install, and it works. I got a kde desktop with konq, kword, kspread, kmail, amarok and a couple of other smaller kde apps built into a squashfs’d qemu image less than 120 mb, that when booted with a base kde desktop, konq and kword running, used about 80 megs of ram. Obviously as more tabs in konq were opened, the mem usage went up, but not much more. The only thing that I built that I couldn’t get to run was kmail. While it compiled cleanly, at run time it got hung up on uclibc’s file locking routine. I gave up on it due to lack of interest a few months ago, but it did work.
embedded devices
at least not in the traditional sense. The devices that are likely to run gnome or any other gui that complex are really just shrunken personal computers.
These devices tend to have faster processors, more memory, and more storage than typical workstations had 10 years ago. They’re 30-50 times slower than modern PCs, which is why it’s silly to put something like Gnome and modern X on them, rather than rolling a reasonable system from scratch.
¿Silly not rolling a new system from scratch? Wow, how insightful! Yeah, a couple programmers could surely whip up something great in a couple months, unlike all those silly hackers that have taken years of work to reach the unpolished current state of linux-gtk+qt.
You should really tell Motorola, Nokia, Palm, Access, NEC, Samsung, Sandisk, Intel, FIC etcetera. They probably haven’t noticed, and have made a horrible mistake! If they only had asked you first…