Frequently Asked Questions

What is MozGlade?

MozGlade is a project to add a simple, easy-to-configure user interface on top of web browser engines. It was conceived because I need the browsing capabilities of Mozilla, but detest its large, slow interface (this interface is improving in the latest versions of Mozilla, but there are still other issues). MozGlade is now undergoing some changes that will allow it to easily use web browser engines other than Mozilla.

Why the nutty name `MozGlade'?

The name `MozGlade' comes from its (original) constituent parts: Mozilla and libglade. Mozilla is the rendering engine behind it, libglade handles the user interface. `MozGlade' is the name I came up with when I started working on the project; I was more interested in the code than in a catchy name. When the time came to start up a project on SourceForge, I solicited ideas for names. People said they liked MozGlade. I kept it.

Why libglade? Isn't that Yet Another Library Dependency? Wouldn't it be easier to just build the interface with glade and compile it into the binary?

Libglade builds the user interface at runtime. It uses a file generated by Glade to determine how to build that interface. Glade is a simple, powerful GUI builder which can build almost any type of GTK+ interface but is easy enough to use that a non-technical person (i.e., a designer) can figure it out very quickly.

I know my limits. I am not an interface designer. I am not much of a designer at all. I am a programmer. I have been coding for twelve years now, and I have learned the meaning of `biting off more than you can chew'. So instead of putting everything on my shoulders, I take upon myself the responsibility to create good, solid code and make the program flexible enough that others -- such as designers -- who can't program can contribute in the way that best suits their skills. (seriously, folks, most programmers can't design worth crap. ;-)

Also, libglade builds gtk interfaces. It doesn't mimic gtk interfaces, it doesn't wrap gtk interfaces, it builds gtk interfaces. So all the advantages (and disadvantages) of gtk exist in whatever interface it builds. When libglade builds a scrollbar, you get a gtk scrollbar, including its support for wheeled mice. Not so for some other <cough> things I know.

Yes, it would be easier (in some ways) to just build a static interface. If I did that, I could stick values into various places in the interface file in Glade, and not have to worry about all the `autoconnect' mangling I'm doing. However, in so doing, flexibility would be lost. People couldn't easily create their own interface. They would be stuck with whatever I feel is the best interface, which would likely be the one I most easily hack. The end-user would lose out for the sake of the developer. That seems counterproductive to me.

But doesn't Mozilla already support 'skins'?

Yes, and that support has Issues. It can mimic gtk's look -- or any other look you want -- but that doesn't fix the problems.

First problem: there is no easy way to create a skin. How are you ever going to get people with design skills to design good skins if they can't build them? That stuff daunts me, and I'm an antiquated programmer. I would never ask any of my designer friends to do that, and none of them that I know would willingly take upon themselves yet another painful learning curve whose only value is to make an interface for Mozilla. Glade, on the other hand, is very easy to use.

Second problem: using skins swallows memory like a killer whale does food (discussed in more depth below). Why this is the case, I don't know, but I assume it has to do with Mozilla building widgets from its own overly-cross-platform interface toolkit. [But I grant that the toolkit fulfills its design]

Third problem: all the advantages of the underlying toolkit (gtk, qt, whatever) are lost. Mozilla may make a valiant grasp at a cross-platform toolkit, but the net effect is a toolkit which wastes whatever system it's on.

What's the memory footprint?

On my machine, an Alpha SX164 running Linux 2.2.15, it uses 25MB. That sounds like a lot, and it is a lot. But compare it to 40MB for Mozilla on this same machine. I'd say MozGlade wins.

And remember, it's using Mozilla's rendering engine.

You mentioned something earlier about other browser backends. What `other' backends do you mean?

One in the works is an interface based on GtkHTML. GtkHTML is at almost the other end of the spectrum from Mozilla -- its design philosophy is to be lightweight and simple. I actually have this backend working to view (and edit) files, but I haven't added the networking support yet.

Another is one I intend to build. It is only in planning stages now, but is based upon an editor I created years ago (whose development stalled... but an initial working version did exist). The widget I'm planning has a scope far beyond the web browser world -- it is intended to be a style-based wysiwig editor, with hooks to make it play nice in a desktop publisher -- but will be flexible enough to simply drop in here. It is intended to fulfill that gap between the intentionally-simple GtkHTML and the overly-bloated Mozilla.