Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Netscape The Internet

Mozilla as GTK Widget 95

AT writes "The new Mozilla Gecko display engine has been embedded into a GTK widget. This means that you can embed webpages into your application, just like you might with an ActiveX control under Windows. " Can I embed mozilla in mozilla yet?
This discussion has been archived. No new comments can be posted.

Mozilla as GTK Widget

Comments Filter:
  • by Anonymous Coward
    Why is this necessary? Well, off the top of my head:

    - Someone decided that this was an itch they wanted to scratch, so they wrote it.

    - Lots of applications need to display text in a window. Why shouldn't these applications also be able to handle HTML in a window? For that matter, why should they only display HTML when they can also win XML for relatively zero cost?

    - For a help file, HTML is a lot more accessible than anything else out there. Linux needs documentation, and the surest way to not get it is to smack potential doc writers in the face and say "We're sorry, but unless you learn nroff your help is not welcome."

    - And most importantly, useful feature parity with Windows. People are already using Windows HTML tool to author help files, and are using Internet Explorer for XML applications (though not on the accessible Web). It'd be a horrible shame if free software shrugged its collective shoulders and said unto the people who want to use Linux instead, "We're sorry, but your application is bloat to us. Continue making Microsoft rich."

  • by Anonymous Coward
    I'm glad someone actually did this. I had the same idea a bit ago. Another idea I had was to embed a file manager into Mozilla for any platform. Then maybe we can "integrate" it into gnome. How about it?
  • by Anonymous Coward
    Help me and my fellow clue depriveds. Is this specific to a window manager? What operating systems? help!
  • by Anonymous Coward
    This is nice, but shouldn't this all be done in CORBA, or something similar (ie like how KOffice is doing it)? By using widgets you're pretty much limiting it to gtk apps. Using something along the lines of CORBA should allow just about ANY app to use it (whether it be GTK, KDE, etc).
  • I downloaded the M5 release and tried it out. First I tried building from source, which succeeded, but they when I tried to run it I had an assertion failure in ld.so ("DYNAMIC LINKER BUG", etc) so that was out. I then downloaded the binary. Somebody had said M5 was way faster than previous versions. Well, not for me. I found it to be extremely slow. As in sit back and wait for the button bar to repaint sort of thing. What is being done for the speed? I ask because if they embed this thing inside something else with its own layer of slowness ontop the speed would be intolerable.
  • Posted by Moritz Moeller - Herrmann:

    Haha, listen to the ant-QT mafia finding excuses.
    Of course it is NOT legal to link GPL applications to NPL or QPL licenced libraries/widgets! At least if you believe the anti-KDE stories circulating.

    Of course nobody will care because it's open source after all and GPL isn't sacred.
  • Posted by Moritz Moeller - Herrmann:

    > Unfortunately QT has a license that restricts its
    > utilisation for commercial use (enterprises have
    > to pay TT) and only separated patchs are allowed by TT as source code modifications.

    NOOOOOOOO!

    QT impairs closed sourced applications. commercial closed source ones have to pay for developers licenses.

    GPL forbids closed sourced applications.
    LGPL imposes no limits on closed sourced applications.
  • by Jerky McNaughty ( 1391 ) on Thursday May 27, 1999 @04:30AM (#1877091)

    As long as it's quick, I'd be a great way to display online help in an application. If it's done well, it'll be very popular.

    XEmacs can be a widget in an application, too, but I've never actually seen anyone use it for that, presumably because of incredibly extreme bloat. (It's great as an app, but as a widget!?)

    There are a couple of other really nice new gtk widgets: GtkSheet (a spreadsheet with inplace editing, widgets inside the sheet, etc.) and GtkPlot (a really nice plotting widget). You can see them right here [ifir.edu.ar]

    .
  • I want a TeX engine on my desktop! Ok, maybe merge in the hypertext stuff..
  • CORBA is a specification that allows objects to communicate seamlessly in a distributed system. It's seems to me that it would be overly complicated (and with performance issues) using CORBA within the presentation logic. How would it work? I guess that the UI component would be some sort of "local" CORBA service. Surely that would mean passing UI client areas around as CORBA::Any's so that the component could draw itself correctly in its container.

    Has anybody done this? Am I barking up the wrong tree? If so, how is it down, and what is the performance like?
  • Sounds like Internet Exploder with the desktop enhancement, or the KDE disk navigator
  • by Amphigory ( 2375 ) on Thursday May 27, 1999 @04:56AM (#1877096) Homepage
    The "right" way to do this would be to make the gecko widget into a bonobo/baboon control that could be embedded in Gnome apps. I would assume that something similar could be done in the KDE world.

    This widget approach is not really directly comparable (as I understand) to the IE CaptiveX control. There is not going to be the kind of insulation between mozilla changes and this widget that a true component environment would provide.

    However, this could be a straw man kind of problem -- I haven't read the source.

    Very cool regardless!
  • by tgd ( 2822 ) on Thursday May 27, 1999 @04:29AM (#1877097)
    Its a good idea. Too bad the current tree has been pretty well horked for the last day or two, and like a bonehead I forgot to check the tinderbox status before I pulled it.

    On another note though, for those who don't watch the mozilla status daily, M6 is probably going to hit the ftp site tommorrow they're saying...

    Its already been pulled into a new branch, and I think the general trouble (particularly with Linux builds) in the tree are on the main branch leading to M7.

    Hmmmm... maybe I'll pull the M6 branch and check this out. :)
  • Yeah, I guess you're right, every server needs a web browser to view a man page or helpfile. I'll throw out 'less' once Netscape 5 comes out.

    It's thin... for a webbrowser. But who needs five or ten megs of code soaking up another ten megs of ram just to view a helpfile? Even if it is only two megs of ram, it is still two completely wasted megs of ram.

    It's neat, but I hope it comes with an off switch.

  • It would be nice to have the option of which bloated HTML/XML engine to use for displaying your help files.

    I opt for 'less'. I'll save a few megabytes of ram and just parse it all in my head.

    I love the idea regardless, I just fear that this may push the system requirements up for very simple applications... I guess it's the way of the future though.

  • I'm a bit concerned about this, actually. Mozilla is unusable on my high-end PII. Even with lots of profiling and removing the debugging code, I'm not sure how much of an improvement they can make.

    But that's Mozilla. It's my understanding that the layout engine is very fast, and I assume the gtk+ component would just wrap the layout engine and not all of Mozilla.

    Jason.
  • An embeded web browser IS a bad thing! Especially if you don't want to use it. Why would a 486 Linux fileserver (for example) need to have all that bloat. You could say don't start X, but that is beside the point. The web browser SHOULD be seperate and be able to be turned off if you don't want it.

    What are you talking about? For normal operation, Windows 9X/NT requires a shell to be running that implements a certain COM interface; MS supplies IE4 as the default shell and there are few alternatives. No such requirement exists for X; so I don't see why you think that we are suddenly going to be forced into loading web browsers we don't use.

  • "pretty well"? It's darn great!
  • some have mentioned using this for html help files. That's nice. email and newsreaders with html? even nicer. But the full potential of gtkmozilla is using it in css authoring tools. A simple html 3.2 widget isn't enough. You need a browser component that's meant for the real world if you want to design for the web
  • helpbrowser news://news.mozilla.org/374B247B.D508670D%40netsca pe.com?part=1.2 and simplebrowser news://news.mozilla.org/374B247B.D508670D%40netsca pe.com?part=1.3
  • this is gecko. Now this is one step closer for real-world web ability in linux apps such as web authoring tools (like homesite or hot dog), multimedia hypertext presentations using dynamic html, your own custom non-netscape browsers that renders websites the same way as Netscape, etc
  • by itp ( 6424 ) on Thursday May 27, 1999 @05:43AM (#1877108)
    GNOME will be using the GtkMozilla widget, embedded as a Bonobo object (work progresses as we speak). All will be well. And the licenses aren't a problem, with the way the widget is embedded rather than linked.

    --
    Ian Peters
  • by itp ( 6424 ) on Thursday May 27, 1999 @05:45AM (#1877109)
    Besides being the "right" way, this is also, coincidentally, exactly the way it is being done. Have no fear, little one. :)

    --
    Ian Peters
  • Gecko promises to be anything but bloated... where have you been?

  • Well, I'm running Gnome on a M2-166 with 40MB of RAM, and it doesn't seem desperately slow to me.

    I would guess that the WM you use with it will make a very great difference - something like FVWM or similar is much faster than E, purely because it is more mature and has a slimmer featureset. Yes, Gnome is bigger than other "user environments", although X itself is less than a model of efficiency, so to speak, but;

    a) If you want slimness and speed above all else, use wm2. Features will slow your computer down, in the same way running lots of apps at the same time will - there is only so much RAM, and there are only so many clock cycles to go round.

    It's a tradeoff - networking built-into the windowing system, as in X, could be regarded as bloat. I regard it as an invaluable feature.

    Furthermore;

    b) Use whatever suits your needs best. Me, I like the integrated desktop, as I use my Linux box primarily as a personal workstation. It may not be suited to your needs.

    As for bugginess, Netscrape wins that award hands down. Crashes are not exactly rare for Netscape, let us remember (and I would be amazed if you do not use it) and Gnome does not crash nearly as much as Windows does. Given it is not designed for use on servers and other such mission-critical boxes, I'd say it's at least tolerably stable, and will get better.

    As for idiot-proofing, I will agree that it is desirable, but Linux tends to act as a moron-filter at present - you still need a certain degree of technical ability in order to use it. Thus it is more important, I suspect, for the developers to concentrate on the feature set whilst it is a higl techy audience using it - the handholding can come later.

  • Xemacs was able to be an Xt widget at one point, but the ability has been broken for years. jwz occasionally kvetches about that, but few people want to deal with Xt who might be inclined to embed emacs.
  • kfm's really useless in some ways.

    1. It doesn't do POST. Not correctly anyhow.

    2. Doesn't do any auth at all.

    3. Dragging randomly alternates between hilighting text and dragging out rubberbands, with no apparent way to switch behaviors.

    4. Poor control over fonts. A case where integration is not what I want, I prefer larger fonts in my web browser than in my file manager.

    5. Doesn't use the mousewheel. I can make netscape use it (oddly, it seems to have lost the ability just now though).
  • Actually, there's been some discussion on the Gnome mailing lists about doing just this. Apparently it wouldn't be that difficult, either, so in time we may have an embeddable Gecko component for Gnome.
  • Actually with Chrome, Mozilla can take any interface you want. All that you have to do is click on a hyperlink, wait ten seconds and your interface will be updated. Its a very easy way to add new buttons and such. You can add a button and a function in 15 minutes (the function with Mozilla modularity) for all platforms. Its been said that to add a single button to a single platform takes an engineer roughly an entire day. So, I suppose if you really want that 'go' button you can add it.
  • An embeded web browser IS a bad thing! Especially if you don't want to use it. Why would a 486 Linux fileserver (for example) need to have all that bloat. You could say don't start X, but that is beside the point. The web browser SHOULD be seperate and be able to be turned off if you don't want it.

    Lets just do some quick logical thought. You are saying that in certain implementations it is a GOOD thing to have a program sitting in memory that you don't need. Am I confused or are you just INSANE?

    It is utter bullshit to say that you should have to get more RAM for a embedded program that you don't need. Why is it that we should upgrade computers every other year to accomidate the software that does little more than add more bulk into memory. The last time I checked on one of my Win98 systems, that was idling, with only two processes running 'Explorer and Systray' it was still eating 60 megs of memory! Win95 would idle at 15 megs. Yes, Einstein, this is the browser that you have at your beck and call. And since IE 4.0 memory leaked like mad, this was another GOOD thing. How do you fix a program that is leaking like mad that is embedded into the OS and that you can't kill. The only answer is reboot. If this were Linux it would mean kill X.

    I agree with you on the point that it is a good thing if you want it. But there is no reason that you can't have it having embedded functionality yet still vulnerable to be killed.
  • Maybe Rob's anti-KDE actions are becoming a bit more blunt, but I really don't see how this is news. KDE has had a HTML widget since pre 1.0 days (someone's even hacked up java support forit too). For that matter even Gnome has had a HTML widget somewhere, right? Hmm.
  • Blow me. I'll knock whatever I fucking choose to knock.

    PICS support doesn't belong in an HTML widget, period. It's an HTTP (that can easily be abstracted to become HTTP independant) thing.

    KHTML already has some JS stubs (read: JavaScript is probably not far off), and some CSS support. Not modern? Try something OO and GUI written in C.

    Despite popular FUD, GPL is *not* opensource, it's strangulation of source. Incidentally, khtml is closer to the GPL than the NPL is. Thank you :)

    Uh yeah scores of developers can use Linux and Win32. Whoopie. Mozilla is currently a bitch to compile out of the box, and for that matter so is Gnome. I'd rather just stick with KDE which is thankfully quite easy to build out of the box on my FreeBSD box.
  • Whoop de do. That's all that's important is that it's gecko? *yawn*. Get a life.
  • Comments like this really get me going. I am no Microsoft fan, but I am intelligent enough to recognize that, yes, Microsoft has done *some* nice things with Windows. Having a browser at your beck and call whenever you need one is a *feature*, not a hindrance.

    People also seem to forget that SGI had a web-enabled desktop in IRIX before Microsoft was able to embed IE in Explorer. Perhaps it was Microsoft making Windows more like IRIX.

    The simple fact is that it is natural evolution. If SGI hadn't done it first, Microsoft would have. If Microsoft hadn't, perhaps GNOME would have. No matter who did it "first", the point is, someone would have done it, and it's a benefit to mankind, regardless of its inventor.

    There are *no* disadvantages to having a web browser embedded in your desktop (at least, not in GNOME--having Explorer crash when you view a Java page is not a Good Thing, but that's Microsoft's fault.) If you don't want to use it, don't navigate to an HTTP address. There, now you don't even know it's there. "Bloat" you say? Get more RAM. The 80s are gone, and so is the 640k limit. A 128M PC100 DIMM is currently ~$80 on PriceWatch, so there's no excuse for not having enough RAM to support the needs of modern software.

    Saying adding a browser to GNOME is making is MORE like Windows is like saying that adding wheels to a wheelbarrow is making it MORE like a car, in some derrogatory sense. Bullsh*t. It rolls, now, and helps you get your work done faster. You can carry your boulders all day, for all I care, but I want to wheel mine, thank you. I have better things to do with the time I save.
  • If bloat is your concern, and text is your desire, doesn't it make as much sense to have a way to embed lynx as your HTML help file viewer?

    What's the footprint on Lynx anyway?
  • Well, if Mozilla can act as a GTK+ container, I don't see any reason why you couldn't do that.

    The Gecko inside IE screenshots were really cool... I wouldn't mind browsing that way, if it means I get the best engine available.
  • by SuperDee ( 14231 ) on Thursday May 27, 1999 @05:39AM (#1877125)
    From what I've read in the public.netscape.mozilla.gtk newsgroup, it looks like GtkMozilla is also soon going to be put into the main tree, possibly under /mozilla/webshell/embed/gtk. The ActiveX wrapper is in /mozilla/webshell/embed/ActiveX.

    Offhand, I'd say that this GTK widget *will* allow embedding like the ActiveX control. After all, even if GTK itself changed in the future, what then? I should think all it would mean was some "tweaking" of the GtkMozilla code to work with the newer GTK. Likewise if the Mozilla code changed. Same goes for the ActiveX control, if Micro$oft one day decided (heaven forbid) to change the ActiveX standards slightly. In fact, I wonder if this isn't already coming--I understand they are working on COM+ as we speak.

    Incidently, I also know that the GNOME Project has been trying for some time to find a way of embedding browser-like functionality into things like the file manager and the help system... And so far, all they have really are things like the Express browser, which is not very far beyond the planning stage.

    My hope is that GtkMozilla will finally bridge this gap... I wonder, does anybody know if the NPL/MPL would allow this? I am assuming it would, if they are already going to allow people to embed the ActiveX control in their programs. But does anyone here more knowledgeable about licenses than me want to confirm this?
  • by SuperDee ( 14231 ) on Thursday May 27, 1999 @05:53AM (#1877126)
    The UI is certainly slow. But look at the rendering of pages--that is FAST. The reason for the UI slowness is because of some well-known bugs which the Mozilla team has been wrestling with for over 3 milestones now.

    Basically, the problem is that incremental reflow causes the entire window to get repainted, often times more than once. You can probably imagine that this would slow it down. They are working on this, but it isn't easy... It is particularly a problem under Linux, with GTK (Windows doesn't notice it as much, from what I've heard). They need more GTK experts to help them.

    So please, HELP MOZILLA!! And feel free to give it another try. Don't be scared. It's only a lizard. :-)
  • by Industrial Disease ( 16177 ) on Thursday May 27, 1999 @04:33AM (#1877127) Homepage
    One of the most amusing things I've seen out of Mozilla was the screenshot of Gecko running as an ActiveX control in IE. Probably the only way IE is ever going to render Box Acid worth a damn.
  • a score of -2 should only be visible to moderators. That way, if something was unfairly scored down that far, a moderator could fix it, but otherwise, the 99% of the time that it DESERVED a -2, nobody would ever see it again.


  • I don't know if KDE does it the same way as the gtk/mozilla thing, but there is a khtml widget in the KDE library. It's used in a similar way to the rich text widgets. A lot of KDE applications use it for displaying help. I don't believe that it's 100% HTML4.0 like gecko eventually will be, but it's close enough to HTML3.2 that it's suitable for real world surfing, and more than enough for help files.

    I also believe that this will be used as the basic for a KOM/OP component.
  • If this widget is nothing more than a wrapper for gecko, meaning that you can replace gecko with something else, then it should be fine. It just can't be packaged together with gecko.

    If it's bound too tightly with gecko, then it will probably need to be released under the NPL.
  • by AT ( 21754 ) on Thursday May 27, 1999 @07:16AM (#1877132)
    Widget: generic user interface component. e.g. button, text field, menu, etc. Windows calls them controls. The term originates with the original Xt toolkit, and Motif which is layered on top of Xt.

    GTK: aka GTK+. The {Generic|GNU|GIMP} toolkit. A specific GUI toolkit that sits on top of X11. An alternative to Motif and Qt. Unlike Motif, it is not layered on Xt. Started as part of the GIMP project when Motif was dropped because of functionality/availability/licence concerns.
  • Well, in fact, my box at home is a 486DX2-66, with 32 MB RAM and I am running X, E & Netscape on it. Works for me, although I am considering one of the new lightweight WM's with Gnome support instead of E.
  • Hmm. If Mozilla can act as a container... Anyone want to use the IE5 ActiveX control in Mozilla? It would be interesting to see if this would work. It would be a whole difference in competition between the two browsers. If Mozilla has more compliant renderer and IE has a better interface (complete with a go button)...

    Okay. Im just theorizing here.

    --

  • An Active X component is really just a library. You must specifically reference an Active X component in the code of the calling program. There is no standalone entry point that allows execution of an Active X component (no main() ).

    I can _possibly_ see an Active X Gecko component being released under an LGPL. I suspect, though, that the Gecko Active X component is the Gecko code with the required Active X entry points added. If the internal Gecko code is already GPL, I don't think you can release such a component under LGPL.

    FWIW, I think a Gecko component is one of the coolest ideas I've heard in a while.
  • Dying breed? I don't think so, but then again, I don't care. Look, "making your life easier and faster" and "cutting your learning curve" are all nice and dandy, but those are the same things that have made the net a slow swamp of clueless people clogging the wires with "multimedia" and "active content" and whatever you want to call that stuff.

    Now, this is not necessarily evil. It was unavoidable, and yes I think that is very nice that most of my family can email me now, and my secretary don't have to cope with clumsy and noisy typewriters anymore. But you should try to understand why some of us sometimes loose our patience when trying to explain to some AOLer the deep concept of "current working directory", or close our eyes and sigh every time someone releases a new kind of "streaming multimedia gadget" or whatever.

    And now, just to avoid been marked as offtopic: this GTK widget is a heaven-sent answer for a project I'm cooking right now. Actually, since the thing not only renders HTML, but XML, and has that cool XUL thing for building UIs, I'm starting to think that this could entirely change the way I build applications for X. One thing is for sure: this stuff is not only for showing help files. You'll see.

    And I can't wait for this thing to reach beta...

  • I guess that allowing mozilla to embed GTK widgets, or (more probably) XPCOM components like mozilla itself, in a document, should be a feature really easy to add right now.

    But I also think they won't going to do it. It would be a non-standard extension, hence as evil as the ActiveX extension that Micros~1 tried to force down our throats (and succeeded in some places -you should see some intranet projects I've seen in some banks here in México).

  • first Mozilla spits out debugging info so yea it is slow loading etc...
    but try some of the tests ie. Debug / ViewerDemos.
    now resize mozilla see how fast it is at rendering tables? also try some more tests. [mozilla.org]
    arent the css tests kewl? wouldnt it be nice to write webpages to spec. in that you would know they are rendered right.


    nmarshall
    #include "standard_disclaimer.h"
    R.U. SIRIUS: THE ONLY POSSIBLE RESPONSE
  • by jpc ( 33615 )
    As the NPL is not compatible with the GPL, is
    this allowable? I wondered about this a while back
    and decided that it is not.
  • IBM has a plugin for TeX/LaTeX for IE and Netscape(WIN, IRIX, Solaris, Linux, AIX) that seems to work pretty well.
    http://www.software.ibm.com/network/techexplorer /
  • It is a GTK widget, so you need to have GTK. GTK is a widget set designed for Unix/X. So at least for the moment this particular thingy is tied to Unix (and only those Unices that have a working Mozilla port). Some people are porting GTK to Windows, so at some point it might be possible to use this widget in a win32 program. However, Mozilla has an implementation as Active X control (if that's the right way to phrase it), so embedding Mozilla in Windows applications should already be possible.

    And no, this is not specific to any window manager.
  • I don't know too much about licenses...
    But an ActiveX control might be considered to be an independent program, so that no GPL restrictions apply. Just like I can use Unix pipes to make the output of a GPL'd program the input of another program with incompatible license. (On the other hand, I guess the GPL might apply if the resulting application can't run without the ActiveX Mozilla control. And that could be solved by implementing a rather trivial ActiveX plain text viewer and distributing it with the application.)

    Hmmm.. I should add I don't know anything about ActiveX :). And I think it's time to reread the GPL.
  • Could anyone tell me how this message is offtopic? (It is currently moderated down.)
  • The internal Gecko code is NPL, not GPL, and I'm not sure how that relates to LGPL. But it's apparently fine to use it as Active X component in IE, so I don't think the problem (with embedding Gecko in a GPL app) lies with Gecko... it's just that the GPL (as it stands) doesn't allow it. Of course the copyright holder could make a special exception, but only he can do that.
  • Sounds very reasonable. And gecko can be almost trivially replaced by a simple text viewer, so that doesn't sound like a problem.

    Of course 'packaged together' can mean a lot of things.. not in one rpm, or not on one CD...
  • Apparently this widget is distributed under the NPL. That's ok with me, but it does make me curious. For example, could I use this widget to embed Mozilla in a GPL'd program?
  • Gecko is just a bunch of shared libraries. If you already have mozilla or netscape-5.0 running, using Gecko as a help browser for a solitaire game wouldn't cost you any extra memory nor diskspace. In fact, having all those little solitaire-like games include their own simple help viewer would really give unnecessary bloat.
  • Should make writing mail clients that deal with text/enriched or HTML easier...maybe we'll get some good functionality out of this

  • I think the author made a mistake, he probably meant to use MPL and not NPL. As NPL gives special rights to netscape.
  • Other then the "wow that's kinda cool" factor, why would anyone want this?
    Hmmm, a solitare game with a web browser for viewing help files... that is REAL necessary!
    Bloatware at its finest.
  • This widget is not for viewing HTML as
    help files, but we can write E-Mail and NEWS-Clients which can deal well with HTML.

    That`s the fact !!!

In the future, you're going to get computers as prizes in breakfast cereals. You'll throw them out because your house will be littered with them.

Working...