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."
Think about the memory usage. Firefox struggles enough, think about running a full desktop environment. I won't until some of the memory usage comes down quite a bit.
XUL is already blamed for a lot of the speed issues with Firefox, why would I want the DE to be even slower? And why would Mozilla do this other than to try and get more attention? Do they have any ideas that are different enough from the existing environments (like KDE and GNOME or even enlightenment and XFCE) that they need to make a NEW environment?
In all honesty, unless Mozilla Corporation/Foundation has an actually INCREDIBLY AMAZING NEW idea that CANT be done with any of the existing DEs this is probably the stupidest ideas I've heard in a LONG time.
What are the goals? How will it be different? Or are they doing it just to do it?
Libertarian Leaning Political Discussion Forum.
Ok, I'm no moz dev, though I loves me some Firefox, but didn't we learn not to mix our browser and desktop scripting languages before? What is there about this arrangement that would not be screaming for holes to be found and malware to creep across boundaries? It could be very cool, but it could really suck bigtime, too. Where do you want your file system to go today?
10 Create web browser and email client.
20 Merge applications into single suite.
30 Steadily add programs and functionality to suite until it does everything badly.
40 Announce innovative new project to create simple, lean apps that break up bloated suite.
50 GOTO 10
How can I believe you when you tell me what I don't want to hear?
Don't get me wrong - I like the idea, and think it could work really well for the environments that will support Firefox across its (potentially unlimited) lifetime, but it seems to greatly overlap with javascript/flash. Each is practically limited to either specialist uses, or else work as least-common-denominator products for the potential Firefox environments. That means a lot of sprite games with simple interactions, graph and UI effects in popularized widgets, web portal software, and even the occasional spyware exploit finding a way to mark a user's trail. There will be ports of simple software from other environments, but limited interaction with the outside environment (by design), being chained to a time-limited browser session, and lack of the easy ability to really exploit the running environment will severely limit what toys and tools can really be created.
That's why I've taken a liking to Eclipse recently - it takes a nice set of the fast-development architecture of java development, and allows them to be used by C/C++, Python, and others cross-platform. Has anyone started working on a really nice integration of Eclipse into a Firefox plugin?
Ryan Fenton
I thought the whole point of Firefox was to create a slimmed-down-yet-extensible browser that wouldn't suffer from the "kitchen sink" mentality that plagued the Netscape/Mozilla suite in the past. Sure, I guess it's possible to do a whole XUL based desktop environment . . . but why??
(and yeah, I know the same logic of Firefox --> d.e. bears similarities to the GIMP --> GNOME, it just seems odd to me to go through the massive effort required when there are so many simpler options to do mostly the same thing these days.)
Lets look at history so we don't repeat ourselves... Microsoft thought that embedding IE into windows (and when I say embedding I mean fusing together with no hope of separation) was a great idea but it turned into a disaster for security and to some extent usability. Now I do realize this is coming from a different angle, where a browser is going OS instead of an OS going browser, but in my mind, as far as security goes, local and non-local should be kept as separate as possible. Closely integrating the two is just asking for problems. You learn history so as not to repeat it.
KParts is an excellent example of what I'm talking about. KDE previously tried something like XPCOM, found it to be overkill and too complex for what they were doing, and came up with KParts instead, a much simpler, better solution. But it's not even close to doing what CORBA tries to do, (and that's a good thing).
Comparing XPCOM to KParts will give you an idea of the insanity of this proposal. Heck, just comparing the documentation for the two is evidence that the XUL desktop is a non-starter. From this page
When the KDE core-developers realised that Corba was becoming an unmanagable nightmare, they wrote in a few days a lightweight and efficient component technology to replace it: KPart.
KPart is based on Shared Libraries. This makes the component appears directly as a C++ object. There is no need to wrap its features with an IDL language, everything is accessible without extra effort.
What I'm guessing is happening is some guys started working with XUL, thought it was pretty cool, and said, "Hey! We could make a WHOLE desktop environment out of this if we wanted to!" But just because you can do something doesn't mean it's a good idea. There's plenty of history here to back that up, too.
It's also possible that XPCOM itself is a hindrance to the Mozilla project. Have they realized the assumed benefits of using a component architecture? Not when I can only write for their platform in maybe four languages, if we're being generous.
It wasn't that long ago that CORBA and DCOM were new and exciting, people were running around talking about how you could assemble standard applications like word processors that pulled components from "all over the Internet." It never happened, because quite frankly, it's a stupid idea for desktop apps. Not everything needs to be a distributed application.
XPCOM came along at about this time, and I'm afraid it's still around more because it's a holdover from that era than because it's a good idea. There are benefits to using a component architecture, but the much simpler KParts, QT, or wxWidgets approaches have those same benefits, are much more usable.
If moderation could change anything, it would be illegal.
This very much could be a step in the direction they already took.
Before they shipped browser, email client, calender, HTML editor, and all the core technologies to support it.
Now, instead of shipping a browser and the core technologies to support the browser, just ship the core technologies. The browser could simply be an extension you can install if you want it.
We've been through this already. Remember Mozilla, and how it turned into bloatware, then had to be slimmed down for Firefox? Rmember how XUL was going to be a "platform" that would make Netscape into a Microsoft competitor?
Then there was XPCOM, the Mozilla answer to Active-X, Microsoft's bad idea.
We don't need another stupid "platform". If you want to run programs in the client, we have Javascript and Flash for the simple stuff, and Java for more complex tasks. Cross-browser compatibility, even.
So is it a desktop environment? A Window Manager? A bloated shell on top of a bloated desktop environment? Why in the hell would I want a Mozilla desktop environment over Gnome, KDE, XFCE and others which have been doing a great job for a long time?
Here is what I want my browser to do: Browse the internet.
Here is what I want my email client to do: Handle email.
Here is what I want my FTP client to do: Transfer files.
Just make a good fucking browser and stop trying to branch out.
Why not? I'll tell you why not ... if the desktop environment is anything like developing Firefox extensions, it'll be a piece of crap.
1. Why, oh why, when I install an extension, it merges XML configuration with several other files? Do you know how hard it is to manually take all that crap out if the uninstall works (which it often does)? And still leave Firefox stable? Didn't they learn ANY lessons from Windows Registry Hell?
2. To make this "your configuration is scattered and merged with other VERY IMPORTANT FILES" phenomenon worse, why are they linked with GUIDs? GUIDs?!?! So now, if I want to uninstall "Craptastic Extension 0.7", instead of searching for "Craptasic", I have to find out what its GUID first and then hunt down instances of the GUID. Thanks a lot.
3. RDF. Ugh. Wouldn't a domain-specific XML schema have been better. I find RDF too abstract, not human readable, and contrarian to many of the design goals XML was supposed to bring in the first dang place.
4. Inconsistency of layout structure across extensions. How is this possible? The too-open-endedness of RDF. When I first tried to learn how to develop a Firefox extension, I decompressed the archives of four of my favorite popular extensions. To my dismay, the severe differences in project layout structure from extension to extension didn't allow me to see any pattern. Because the RDF can make anything point to anything, the individual developers could just layout all the directories however they damned pleased. Constrast this a Java project organized by Ant and you'll want to scream.
5. Look at Eclipse, ffs! Now THAT is how you build extensible software! Consistent. Clean install. Clean uninstall. No Registry Hell. No &$^#ing GUIDs. No RDF as obfuscated as a bad Perl or Lisp program.
"Love heals scars love left." -- Henry Rollins
Oh, wait, they went on to make dozens of other great products. My bad.
But did they integrate Tomcat with httpd? Of course not. GP is saying that they shouldn't integrate a browser with all the other things they're making.
I'm in the hole of the broadband donut.
I dunno. The protocol, far as I can tell is fine. The implementation, at least the standard X server, is a POS.
Meanwhile, some of the purpose-built X-servers do a good job. X-Glx with Beryl makes Aero look like ass. KDrive is light enough to fit on a floppy. X-Ming is a great tool for porting X apps to windows.
Also, your demands for an end to X-Windows based on a story about Mozilla Desktop Environment is kinda dumb; MDE would run atop XWin, just like any other DE.
'course, you're just trolling AC, so you don't care about things like facts; just so long as you get a rise out of people. Once again, normal human + anonymity = rabid idiot.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1