Slashdot Mirror
A Mozilla Desktop Environment?
Andreas writes "A discussion at the mozilla.dev.planning list has given the birth to the idea of a Mozilla Desktop Environment. This sure sounds like a possibility for Mozilla as it already has many of the applications needed; and the company is thoroughly familiar with XUL, which is a more-than-potent language upon which to build a desktop environment. By building a desktop environment Mozilla wouldn't have to worry about drivers (and such) and could choose from a variety of kernels, and still be in the center of attention. Mozilla has to expand some of the applications for this to work, though, like adding local file management with Firefox."
To be fair, most of the memory issues in Firefox are because of the way it keeps previously visited pages stored so they can be quickly opened again. Unless their text editor/email client/whatever acted in the same manner then it shouldn't be too big an issue.
In my opinion, Mozilla should really leave this kind of idea to other developers. Songbird developed by itself just fine and I'm sure after this idea's been mentioned there will be other random developers toying around with the idea. Firefox and Thunderbird are good but attention should be focused on them before moving on to bigger, wilder ideas.
If we can hit that bull's-eye, the rest of the dominoes will fall like a house of cards... Checkmate.
It depends on where the bloat is coming from. Potentially using common components/shared libs could reduce bloat relative to having mozilla browser + kde + gnome apps, each of which need their own bloat libs.
Engineering is the art of compromise.
XUL is too slow to make an entire DE. Can you imagine a desktop environment WRITTEN IN JAVASCRIPT?!?!?! (or technically emca script?) My god, thats one freakishly scary (and slow, and memory intensive) desktop environment... I think it would make the people running XFCE and enlightenment scream, and the people running blackbox, rat poison, and other tiny WM head's explode.
And don't forget that on *nix XUL uses GTK's widgets... I can see the OOM Killer going wild already!
One of the main reasons why I'm using Mozilla for webbrowsing is that it does not integrate with my desktop (beyond calling helper applications). The webbrowser is "the internet" domain, my desktop is the local domain. Any program which is designed to cross this line is an unacceptable risk. A Mozilla desktop environment would be a serious design flaw (and a violation of the KISS principle that made Firefox more of a success than its "full-featured" predecessor).
I've done a bit of stuff with XUL.
It's great if you want to do things like, say, a custom web browser or write your own iTunes -- The kind of thing that you'd usually write as a web-based app but you need local file storage and maybe access to online content that cross-site scripting preventative rules would prevent you from accessing in a regular browser.
If you need to do more than that, it's quite a chore. You have to start writing your own XPCOM components, which you'll have to compile on each target platform separately. There goes your easy cross platform compatibility.
The documentation for XUL and XPCOM isn't very helpful or well organized, and that's putting it nicely.
Language support is thin. C++ and Javascript are pretty much your only choices, although Python support is coming soon, apparently.
The question is, if you were going to develop a desktop environment from scratch, would you start by writing XUL? Would you then extend that by embedding JavaScript? I don't think so. Both Gnome and KDE tried the whole component thing with CORBA and abandoned it for performance and complexity reasons. Cross-platform is nice, but Java, GTK+, QT, and even C# provide better cross platform benefits with greater support and language compatibility than the XUL suite of tools.
Not only that, but I'd wager a Java desktop environment would be a better performer than one based on XULRunner. Not to mention, it would support more languages through Jython, JNI, etc.
It's a shame, because XULrunner could be a great platform. I hope they focus more on documentation and supporting other languages than redundant pie-in-the-sky projects like this one.
If moderation could change anything, it would be illegal.
If you've got both Seamonkey and Konqueror installed on your system, browse the same set of sites with both. Make sure you disable caching for both, to prevent such caching from inflating each browser's memory usage. Also start from a raw X session, just to further eliminate any sources of inconsistency.
I just did that sort of a test on my Linux system, visiting a variety of sites (Slashdot, BBC, Tom's Hardware, FSF, Digg, etc.) with both Seamonkey 1.1.1 and Konquerur 3.5.5. I've also used Opera 9.01. Checking via top, I see that Seamonkey currently has a virtual memory image of 357 MB. Konqueror, on the other hand, is using a rather minimal 43 MB. Opera is just over Konqueror, at 45 MB. As this is the total size in virtual memory for each process, it also includes the overhead of any shared libraries.
So from those results, I think it's safe to say that there's a major problem with Seamonkey. Both Konqueror and Opera manage to keep their memory usage within reasonable bounds. As for the cause of Seamonkey's excessive memory usage, I can't say. It could be due to memory leaks. I'd guess it's partially due to their extreme overarchitecturing of their software. Regardless, it's a troublesome issue for them.
XUL seems like a decent enough idea to begin with, but in practice it's horrible. Anything more complex than your average browser extension, and it really starts showing its design weaknesses. It's buggy as hell too. That last point is particularly difficult to emphasise properly. It's buggy as hell. It seems like a natural step from the web to cross-platform desktop applications, but quite frankly, you are better off using your favourite scripting language and whatever bindings you can get to Qt/Gtk/whatever.
They keep pushing back XULRunner further and further - the first "stable developer preview" is a year old, there's no sign of the next version, and half the APIs available in the preview are obsolete. If it weren't for Firefox committing to it, everybody would have admitted it was dead already. Songbird? Democracy Player? Yeah, those projects are really zooming along development-wise *rolls eyes*. How about you build the simplest little MP3 player that actually works properly before thinking about anything as ambitious as a desktop environment.
I love the idea of XUL, I really do. But its only got one implementation, which totally sucks and is the kiss of death to almost everybody using it. I can't imagine the suckitude of an entire desktop environment built on top of it. I genuinely believe that if XULRunner doesn't get some gigantic improvements, it will eventually drag even Firefox down with it.
SymphonyOS is a Linux distribution which uses a special desktop based in a browser.
They wants to talk to GNOME people about GNOME 3
"Steve Jobs invented the world" -- Bill W. GATES
Let's look back in history. Dr Dos/Quarterdeck tried to create their own desktop environment, Desqview/X. Then Novell tried it with Dr Dos and WordPerfect. It didn't work because OS was not core to their business, and the desktop OS business is far more competitive than what they were used to. Overall this is a very bad idea. Mozilla makes middleware, not client OS components. If Mozilla does this, it may unfortunately be the iceberg that hit the Titanic.
I believe the project was called WebTop... it would have been a desktop environment that could run on top of any OS, and applications could be written for it using it's API... allowing the creation of totally portable applications and, if done right, making Windows essentially irrelevant. It was a revolutionary concept and was aimed right at the heart of Microsoft.
Unfortunately, Netscape was in the crosshairs of Microsoft already, and with the company losing money like crazy, WebTop never saw the light of day...
Until now!
Thanks,
Mike
This was already done a few years ago, there was a company that did a complete desktop environment based on Mozilla. I was sold as a kind of appliance PC for the living room.
Here's an article on it (from 2002).
If I remember correctly that was where the original calendar code came from.
No no and thrice no.
The OS should have one and only job IMHO (or not so HO): Manage and control access to resources.
The desktop layer and even the command shell should in an ideal world be divorced from the underlying OS core layer. And taking this one stage further if a common OS interface API (something akin to POSIX) existed I should be able to take core-OS and put whatever GUI or CLI (yes CLI is still better for some tasks) I like ontop of the base layer.
The base layer can then concentrate on running the hardware, preventing rogue programmes from compromising the rest of the system etc - ideally:
core-os --> [sandbox 1] --> [desktop gui] --> [sandbox for each app]
With the user/admins being able to define very tightly which files can be shared between sandboxes. Programmes which interact heavily with other programmes could run in their own sandboxes...
--- Users are like bacteria -> Each one causing a thousand tiny crises until the host finally gives up and dies.
It's very very different. A Firefox extending analogous to the Apache extending would mean to include a Mail client . But Firefox is an evolution (not a necessarily good one) of the Mozilla Suite, so it would be like going backwards.
Yes, they went on to make dozens of other products (some great, some not so great), but what they didn't do was make them all part of (or modules for) httpd. I can use Tomcat standalone, or with httpd, or IIS, or any other web server. I can use anything from Jakarta without having to install httpd; httpd isn't trying to manage my desktop as well as serve my files, and so on.
No-one is suggesting that Mozilla shouldn't create their own desktop environment if that's what they want to spend their time doing - I personally would question the sense of it, but that's up to them. However, they certainly shouldn't make it part of Mozilla (or Firefox) or even an extension to it, which is essentially what was being suggested.
It's official. Most of you are morons.