Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Mozilla Operating Systems Software The Internet

Mozilla - From Browser to Desktop Environment? 68

Posted by Cliff from the gecko-promotion dept.
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."
This discussion has been archived. No new comments can be posted.

Mozilla - From Browser to Desktop Environment? More

Mozilla - From Browser to Desktop Environment?

Comments Filter:

  • Let's see... (Score:3, Interesting)

    by perlchild ( 582235 ) on Monday May 10, 2004 @03:57PM (#9109927)
    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)

  • unnecessary (Score:2, Insightful)

    by ratsnapple tea ( 686697 )
    This is exactly what's wrong with the Mozilla project. Whatever happened to "make each tool do one thing and do it well?"

    • XUL is an interface building language (much like GTK+ and Qt), and so "should we build interfaces in XUL?" is valid and does not violate the principle you mention. Apps with XUL interfaces would need a runtime, and this is no different from the GTK libs or the Qt libs being loaded when applications based on those frameworks are run.

      That said, I am not sure what the limitations of XUL are. How does it compare to Microsoft's XAML, for instance in terms of functionality?

    • Re:unnecessary (Score:5, Insightful)

      by Eneff ( 96967 ) on Monday May 10, 2004 @04:06PM (#9110040)
      Mozilla != the UNIX philosophy.

      The point behind Mozilla always was to have a platform from which people could create full fledged cross-platform applications using CSS, HTML, ECMAscript and XML.

      It just so happens that the first major application was a web browser.

      I'm starting to subtly push taking advantage of Mozilla's front end capibilities within my company's application, myself.
      • I've read this before and still don't quite understand. Why would someone intentionally design a rich user interface in CSS, HTML, ECMAscript and XML? Wouldn't it be much easier, more maintainable and just as cross-platform to implement the application in Java or Mono. For that matter, it might have been easier to port an existing C++ library to a bunch of platforms. What's the advantage?
      • That's so much bullshit it boggles the mind. What do you do with CSS, HTML, ECMAscript and XML? Write web pages! Duh! It's no coincidence that a web browser was the first major application to come out of Mozilla.

        The only advantage the C.H.E.X. architecture has is that it enables PHBs to terminate the employment of genuine software developers and replace them with web "developers".

        I'm currently having to work on a C.H.E.X. application and it is truly painful. Every software rule has been broken. Every usab
        • Basically traditional client-server is dead! Thank god! Writing apps like that is a complete waste of time from an IT department standpoint [hint: that's why VB remains so popular!] I come from an AS400 background and the only thing "ugly" about RPG is the unpretty green screen...if I could somehow replace those terminals with something "pretty"...

          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 someth

          • Basically traditional client-server is dead!

            As someone who doesn't do much client-server programming, I still fail to understand why moving to the C.H.E.X. client-server architecture adds anything.

            Like I said before, a Mozilla "application" would work much the same way only prettier!

            Is it any "prettier" than a native win32, Aqua, GTK+, or Qt application?

            While I can certainly understand moving a "green screen" Cobol application to a web interface, it still boggles my mind why people think C.H.E.X. is
            • Very simple...

              IT hates to deploy an application of dozens to thousands of computers over hundreds of offices.

              Much easier to have everything on the server rather than having to program self-updates.

              The alternative, of course, is to install X-Windows on every system so that they can all run clients off a central UNIX box. This has its own political challenges, especially in a unix-only setup.
      • I Agree. I've just started to use javascript(ECMAscript) because I had a simple application which would benefit from the UI of the web form, take some input and display the processed result in a window. I'm impressed with how simple it was ( 1 day ) of course I already knew HTML from perl/php programming. But with server-side programming, I had to send back to the server at every fork in the logic. Script can processes all the html objects and create new ones. It can work. But best of all, the UI is stan

    • Re:unnecessary (Score:5, Insightful)

      by Planesdragon ( 210349 ) <`slashdot' `at' `castlesteelstone.us'> on Monday May 10, 2004 @04:06PM (#9110041) Homepage Journal
      This is exactly what's wrong with the Mozilla project. Whatever happened to "make each tool do one thing and do it well?"

      It fell apart, because "each tool" has to work with every other tool in existance.

      Mozilla (and OpenOffice, Gnome, and KDE) are necessary corrections to the "one tool one thing" paradigm. Each project has multiple tools in it, and can be used to do many differnet things--but each tool was designed to be used with a specific set of other tools, and the tool authors are upfront and honest about this.

      And for those of us who AREN'T tool authors, getting a "thing" working is as simple as grabbing a toolbox from Sears.
      • GNOME seems to maintain the "one tool one thing" paradigm wherever possible, an example I think everyone else would do well to follow.

      • Re:unnecessary (Score:3, Interesting)

        by MacJedi ( 173 )

        It fell apart, because "each tool" has to work with every other tool in existance.

        You make it sound like this is impossible to achieve. All that you need is a well defined API. What do traditional unix command line tools all have in common and use to communicate with eachother with? STDIN, STDOUT and STDERR!

        Sure, for GUIs you need a bit more: copy and paste and drag and drop, and maybe something along the lines of Mac OS X's "Services" but I don't think the unix "each tool does one thing well" paradigm

        • You mean like DOM or SAX? What about XUL. Isn't a namespace (or rather the schema behind it) an API?

          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 writt

    • Re:unnecessary (Score:3, Insightful)

      by Coryoth ( 254751 )
      In some senses they actually did do that. They made a very impressive rendering engine, and a means of rending GUI widgets via that rendering engine. It seems to do that very well. The fact that other people have taken that and used it to build a wide variety of complex applications is hardly the fault of Gecko and XUL.

      What you are saying doesn't really make sense. It's like blaming QT or GTK+ for every app ever produced with them.

      Jedidiah

    • Re:unnecessary (Score:4, Insightful)

      by OmniVector ( 569062 ) <see my homepage> on Monday May 10, 2004 @04:09PM (#9110085) Homepage
      well, with mozilla it's hard to say much about doing one thing well, but firefox is quite good at just browsing the web. however they aren't talking about making mozilla a desktop environment, they are talking about building a desktop environment out of XUL. this would be just as separate from mozilla as firefox is from thunderbird.

    • Well, I think it has become more like "make each library do one thing and do it well".

      A a certain point in time, you will have to integrate those tools into an application. Now if you do this using separate programs and a script, or separate libraries and a program, what is the difference ?

  • Does anyone know why the robin homepage is like a tiedyed tshirt?

    • Re:Robin Homepage is trippy (Score:4, Informative)

      by ErisCalmsme ( 212887 ) on Monday May 10, 2004 @04:00PM (#9109959) Homepage Journal
      I tried to go to the homepage to look for screenshots and thought it was broken. Then I realized that it was a running version of Robin. It has a "start button" menu thing with some programs. Crazy stuff!
      • Aha! That does it. Also, try launching Moxula, then going to robin.sf.net and launching Moxula inside that. Now that's trippy ;)
        • I'm writing this replay from a Moxula window... Whee!
          • ...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....
            • 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.

  • HTML on Steroids (Score:5, Insightful)

    by Gortbusters.org ( 637314 ) on Monday May 10, 2004 @04:00PM (#9109961) Homepage Journal
    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 [phppatterns.com] 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.

    • Re:HTML on Steroids (Score:3, Informative)

      by costas ( 38724 )
      Let me just point out there are other ways to make more interactive web apps: JSRS [ashleyit.com] is a free JavaScript Remote Scripting library that lets client-side JS communicate with the server: think listboxes or menus that get populated based on button clicks or check-boxes in the web page, without re-loading the page. It works here and now, and on IE, Gecko, KHTML and Opera (not a plug, just a happy developer).

      You can see JSRS in action on my newsbot [memigo.com], where it lets you rate articles dynamically without re-loading
  • 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 i
    • Your first reason:
      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.

      Valid. If Mozilla = Windows. However it doesn't, and Choice remains. Don't want to use Mozilla's integrated Desktop/browser? Great! we have just the thing for you: KDE.

      Your second Point:
      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 f

  • Will never work... (Score:3, Funny)

    by Thng ( 457255 ) on Monday May 10, 2004 @04:10PM (#9110116)
    No, it is missing a substantial feature for the end user: you can't right click on a box in minesweeper and have it flag it as a mine. Without a full-featured Minesweeper and Solitare application, this will be doomed to failure.

    However, it could possibly be saved by a talking paperclip, or maybe a talking gecko that doesn't complain about car insurance.

    • Re:Will never work... (Score:4, Funny)

      by GeorgeH ( 5469 ) on Monday May 10, 2004 @04:40PM (#9110443) Homepage Journal
      Actually, there are Minesweeper [mozdev.org] and Solitaire [mozdev.org] clones for Mozilla, as well as plenty other games [mozdev.org].
      • Best extension I found is an RSS reader in mozilla. Try it out. You bookmark your RSS feeds in a folder of your choosing, and it puts them in a side-bar.

        http://www.google.com/search?q=mozilla+rss

        It's stuff like this that is making me realize that (many) things can be just "a part of the browser" ... *if* your browser is sufficiently advanced and you have 1+ ghz to spare. :^)

        --Robert
    • why, o why, did Microsoft have to so thuroughly ruin a viable idea...

      AI bot capable of running software and internet queries.... Could be done right.

      Image, a customized ALICE bot, with a highly modified AIML set to be very secretary/computer held desk-ish... Only talks when spoken too, period... Was capable of executing basic commands('Computer, ping google', would execute 'ping www.google.com')... Or do a safari/watson(mac users know this) type of internet browser that can retrieve and format airline inf

  • Mozilla (Score:5, Funny)

    by isorox ( 205688 ) on Monday May 10, 2004 @04:17PM (#9110221) Homepage Journal
    Mozilla - the new Emacs. Bloated, and lacking a decent text editor!

  • soviet russia (Score:1, Funny)

    by Anonymous Coward
    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...
  • 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
    • I call troll on this one, although possibly unwitting.
      Every release of Mozilla for quite some time (Since 1.1 I'd say) has had a faster load time and less bloat.. go read the changelogs if you don't believe me.

      The new Moz family applications are proving grounds for features which may be re-integrated into the main Mozilla tree, as well as being useful stand-alone apps.
  • 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

  • browser-based, opensrc, application alternatives (Score:3, Interesting)

    by dan_bethe ( 134253 ) <slashdot&smuckola,org> on Monday May 10, 2004 @08:24PM (#9112360)
    This article [tikiwiki.org] discusses a new browser-based spreadsheet application in testing, just announced today on the OSCom [oscom.org] mailing list. It also discusses browser-based open source applicaton alternatives in general.
  • 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.
  • KDE is not to be left out. 3.2 saw the introduction of KJSEmbed. This is a little different from the others, but here you go:
    You get:
    • kjscmd - a shebang script interpreter
    • KJSEmbed - a library to link with apps to add scripting functionality.

    Both share the following:

    • Javscript 1.2 (or is it .3?)
    • XML UI screens
    • Qt's Signals-slots


      • 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 tha

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Close