Mozilla - From Browser to Desktop Environment?
An anonymous reader asks: "A while ago OEone released a thingy called Penzilla which was basically a Mozilla desktop environment like GNOME or KDE. Everything was written in either DHTML or XUL and ran within the Gecko engine. Recently a new project, Robin was released that is basically a desktop running within Mozilla using XUL as well. There is NetWindows that attempts something similar for more interactive web applications. What advantages would a 100% Mozilla engine desktop hold and what are the disadvantages compared to much more complex environments such as GNOME or KDE? Is a Mozilla desktop possibly more elegant or efficient for the typical user? Is the XUL runtime environment more robust than troublesome C/C++ widgets? It seems like most applications could make the transition as the growing collection of Firebird extensions like ChatZilla and Gnusto and have shown."
I like Mozilla as a browser and as an email application. Desktop....hmmm I don't mind using C/C++ widgets. Once you learn how to do it, it isn't that hard. I thought tha people didn't like when a browser became the desktop environment. IE anybody?
More than enough BS
Microsoft doesn't need to explain why it's system is better with the browser integrated into everything, everyone takes it as fact(or debunks it at myth)
Why treat mozilla differently?
No seriously, I imagine the goal is that since mozilla is cross-platform and has a bunch of nifty features, a full-blown desktop written in it would be able to compete with java's desktop system for thin clients and similar ideas(probably with great success, as while Mozilla itself is fairly large, it's also quite a capable system, and fairly self-contained).
It has many features modern thin clients would need or at the very least, like to have(software updates downloaded from the web, ssl/tls based security, multiple user profiles), it supports most "thin clients" activities except for document production(by itself: the ibm-related announcement on slashdot today, about a web-available office suite makes that a non-issue) With the proper XUL environment available, you have almost an os-toolkit, themable/skinnable for those so enclined... What more could you want? (Yes you need an OS under it, but at least, you're not limited to the choice of any particular one)
This is exactly what's wrong with the Mozilla project. Whatever happened to "make each tool do one thing and do it well?"
Does anyone know why the robin homepage is like a tiedyed tshirt?
Seems to be that this whole XUL/XAML/DHTML craze is all about creating more interactive web applications, not about rewriting the destkop system.
After all, the C++ code that implements the scrollbar, or button, or whatever isn't going away, it's just being described in a standard manner. I guess that gives the application more portability, in theory.
To switch gears with some thoughts on XUL (and XUL like technologies)... The other day I was reading how interesting XUL was on phpPatterns and using it to build a web-based desktop-like application. The one example people like to point to is that AmazonBrowser. Perhaps the greatest potential for these XUL like languages is for those web features we have a tough time building today.
Whoever thought of HTML frames probably wanted XUL, but knew that nothing like it could be done right now, so frames were a cheap navigational system that could provide a semi-familiar GUI to end users in that only the "content pane" gets updated.
HTML interfaces will still be around. Not only because they're still a great mechanism for internet information display, but because people are used to them. They're used to website design, they like the way it is. XUL-like apps will probably be most used as embedded application interfaces for managing devices... at least in the beginning.
--------
Free your mind.
Integrating a web browser into a desktop environment seems like a bad plan. Surely there are certain specific uses, such as for dedicated internet cafes or something, but this would be moving towards a Windows-like platform.
People here on slashdot are always complaining about the integration of internet explorer with windows for two primary reasons. The first is that you have no choice regarding whether or not you want to use the windows GUI with IE if you want to use windows. The second reason, which is relevant here, is that there's really no good reason why _any_ web browser should be integrated with the desktop environment. Completely apart from the lack of choice aspect, it's simply bad software design.
Mozilla is primarily intended as a web-browser (and mail/news client, etc.), so use it as a web-browser. Add enhancments that help it do a better job of web-browsing, reading news, or things of the like. If you make Mozilla into a desktop environment, you turn a nice piece of software into a block that's larger than most people want/need.
While it was a guideline and not a hard rule, we'd do well to remember the unix philosophy of making small tools that do one thing well.
Alphanos
However, it could possibly be saved by a talking paperclip, or maybe a talking gecko that doesn't complain about car insurance.
I thought tha people didn't like when a browser became the desktop environment.
I think there is a slight difference. With MS, the desktop became the browser. Which allowed many bugs into the system. The reason is probably the origional desktop was never ment to be seen on an open network.
With Mozilla, the gecko engine and XUL and such is a sturdy platform (same as gtk or qt). So adding a module that creates a start button that runs 'xterm -e mozilla-firefox' when you click on it, doesn't seem the same as MS's integrated gui.
At least that's how i see it.
Mozilla - the new Emacs. Bloated, and lacking a decent text editor!
How many times do people like you have to be corrected before you get it?
There's nothing wrong with integrating your browser with your desktop. It's when you do so in a way that can't be undone to leverage your monopoly position to kill off a competitor that it becomes bad.
Who the hell modded that insightful?
In Soviet Russia, the desktop... is integrated into... the browser... or something. Well it seemed funny when I started writing it. It's bacwards, you see? Oh never mind, just mod me down.
i hope not for the sake of his health...
That man tried to kill mah Daddy
Mozilla is already so bloated and slow that the Mozilla group has been splitting out applications and rewriting the engine(Firebird/fox/foo). Yet as bloated as it is, it does not come close to having the feature set that a full desktop requires. Adding those features will only add to the bloat and further slow it down.
Additionally, there is the issue of stability. Not to knock Mozilla but, it isn't perfect. It's good but, not perfect. Speed is subjective but, I doubt that anyone would claim that Mozilla is afast. There are times that it crashes and there are times that it hogs the CPU and of course there is the question of whether it even does its job of rendering web pages as well as it should. Putting your desktop within such a framework is only asking for trouble.
I believe that it is better to have the Desktop Environment as a separate application that is specifically built for that task. One that is written in a language that is fast fast fast. Did I mention that the DE should be fast?
Finally, one must ask if there is a need (read market) for such a desktop environment. OEone has not exactly taken the world by storm, why? In fact I was suprised to hear that they were still alive. I'd bet that there are a lot more users of Blackbox or Xfce (completely ignoring KDE/Gnome) than OEone, why? If a desktop environment inside a browser is better or more desireable, why haven't more people switched? Even Windows simply integrates the browser into the OS, the browser is not the DE.
In the sense that your Windows desktop is just an explorer window that doesn't have a bar at the top, you already have a browser as your interface in that the windows are all capable of hosting HTML.
I think with Win95 OSR2, a lot of the UI was rewritten. I remember hearing that help was redone as HTML, and at least some of those extended views we see in 2000 and XP is done in HTML. Anyone remember Active Desktop? My take on it was it was just one or more MSHTML controls hosted in the explorer window. Neat idea, didn't really serve a purpose... That was always my take on the can't seperate ie and windows arguement - they used the MSHTML control in a lot of different things...
This article discusses a new browser-based spreadsheet application in testing, just announced today on the OSCom mailing list. It also discusses browser-based open source applicaton alternatives in general.
...SLICK! It's like a whole computar inside a web page that inside your..computar on the web...uhh, IT'S NEAT THOUGH!
what else could you do with this? it's just so.... interesting, write a web page that becomes a virtual computer. Much coolness el grande. Hmm, a super proxy. hey! I'm gonna use moxula to goto robin to goto moxula then post back, see if it works....
Having Mozilla as a platform means talking to a well-defined API. Is the platform Windows or UNIX? Doesn't matter; use the Mozilla API. Want MFC/DirectX as your widget rendering engine or GTK+? Doesn't matter; use the Mozilla API.
Just STDIN et al., eh? What about libssl? What about libc? What about libgthread? You are comparing apples and oranges. When you use an component in Mozilla that's written in C++ (for example), it's like using the functions in a shared library. When you use JavaScript to pass values to and from those components, it's like using perl/csh/sh and calling utility programs. Well...almost. The difference being that the UNIX method of "scripting processes" model is far more loose and prone to failure when given bad input. For a closed system used only by a sysadmin, this is fine. For the masses with myriad variations, the model easily breaks with a lot of loud frustration and venting soon to follow.
Not to mention of course that piping data from process to process is just a hop, skip, and a jump from rudimentary programming. Not everyone is a programmer. Programmers aren't the only ones who need to use programs. And most folks -- even many programmers -- like to use graphical widgets.
If you're on the command line, Mozilla isn't an issue. STDIN and STDOUT kick ass. But then again, the "desktop" becomes immaterial at that point as well. Mozilla was made for graphical work. Adding copy, paste, drag and drop, etc. to the list of requirements by definition breaks the UNIX paradigm.
Repeat after me: GUI environments are not compatible with the traditional UNIX "one tool/one task" model.
Or were you suggesting that drag and drop be implemented somehow with stdio redirects?
- I don't need to go outside, my CRT tan'll do me just fine.
Because I was using FireFox on Mac OS X and it kept blowing up. It's a shame because I preferred it. Now I'm using Safari, and I notice the slower performance, but it isn't crashing twice a day like FireFox was. I understand it's a 0.8, but it still kinda sucks that it crashes. It works find on Gentoo for me. Guess I'm stuck with Safari for now.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
I can get as far as my own desktop running moz -> robin ->moxua ->robin -> moxula -> slashdot main page, but it won't go past there for me,it's hanging, can't get to reply to myself, had to go back. It might be my antique box is bogging down though.
it is very nice though, shows some cool thinking.
"To switch gears with some thoughts on XUL (and XUL like technologies)... The other day I was reading how interesting XUL was on phpPatterns and using it to build a web-based desktop-like application. The one example people like to point to is that AmazonBrowser. Perhaps the greatest potential for these XUL like languages is for those web features we have a tough time building today. "
Try this, and yes it's THAT easy to create a nice front-end. The only downside is the server-side is written in Java, and I need a beefier machine. The rest of my links are already posted all over the place.
You have no idea how close to the bullseye you are. The above is "partially" why I don't think we need MONO this, or MONO that with all the attendent problems. The above (don't forget the other Mozilla parts i.e.RDF) combined with some of the other technologies, in the OSS stable should curb our "grass is always greener" urge that Miguel started.
So either we can follow MS, or leapfrog MS, and come up with a solution that'll work for us and windows users. We have about four years to do so. An eternity in internet time.
Enter the web and something like Mozilla. In a corperate environment database apps are all the rage. Web programming neatly fits the design models of something like Cobol or RPG. We've come full circle so we might as well enjoy it! Most internal apps at most companies aren't worth being "professionally done" What matters more is that the data is pulled/dumped to a centeral server, it can be created quickly, and it can be modified quickly and rolled back out again the same day. That's why there's so much Cobol and RPG still out there...not because it's best, but it gets stuff done right now...and is really easy to version control. Like I said before, a Mozilla "application" would work much the same way only prettier!
As far as design rules that has nothing to do with being in mozilla or not...Old, new it really doesn't matter when it comes to making horrible design...that's another problem entirely!!
...all it needs is a good web browser.
Firebird, last I checked, can do anything "Mozilla" can do as far as XUL is concerned and is amazingly faster. So long as your computer is above a certain bar it loads almost instantly ( 1 sec @ 933 mhz). On some slower machines for some reason it is slower than others, though.
You get:
Both share the following:
Additionally, they have a qt-only port which is new, and they will be coming out with a win32 version. This means that you can now right x-platform javascript applications that use Qt. Essentially what mozilla is, but a la Qt.
Also it is important to noet that KJSEmbed serves the function of making parts of your program scriptible, with seamlessness. C++ and Javascript can act on the same objects, and call functions no mattter who (JS or C++) defines them.
Also, a XUL interpreter is not far off, I am told.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.