Slashdot Mirror

Sorry if I've misunderstood what Jabber is all about; but if I've gotten it wrong, you should probably try and clarify this on the web site, because it's really hard to tell what your architecture and goals are, and why.

I also don't understand why anyone would use AIM instead of IRC, except for the reasons of ``my new computer came with AIM and not IRC'' or ``my friends all use AIM and not IRC.'' The latter of which a multi-protocol client solves nicely.

Does this mean Mozilla will not require GTK+?

From the Mozilla Xlib Project page:

"The fact of the matter is that there will always be more than one toolkit for Unix. Right now the big players include Motif, GTK+ and QT. Each of these toolkits unfortunately has its own look and feel for many things including menus and scrollbars.. None of these toolkits is going away anytime soon and it is inevitable that there will be ports of mozilla to each of these toolkits.

...

One of the goals of the Xlib toolkit project is to create a common base, written in Xlib, that will include all of the functionality that is common across the Unix toolkits. The majority of the code will include simple drawing and image handling in the gfx module. It will also include some of the widget side of the toolkit. Some candidates include the nsWindow class which is the simple drawing surface used by the html layout and the XP widgets.

One of the project goals should be to make it very easy to plug in your toolkit of choice. This means that you will be able to use Mozilla in your Motif, GTK+ or QT application. Until the world chooses the One True Toolkit or dies in the process, Mozilla should be able to run on all the toolkits without hardship to people writing applications.

...

It should also be possible to have a stand alone Mozilla browser that is based entirely in Xlib. While this compromises one of the primary goals of the many Desktop Projects for Unix and Unix-like systems, it allows for a lightweight browser implementation that could be used on a Kiosk system, or on very old hardware. The fact is that Mozilla contains most of the functionality of the modern Unix widget toolkits and it is a very small stretch to turn it into a complete toolkit system."

So the answer to your question is yes, altough I'm not sure if the Xlib port is that far along yet.

/Bergie

--

Modifications to NPL-covered code are themselves covered by the NPL.

However, independent work that is combined with NPL-covered work is not covered by the NPL or any other license (other than one you choose).

In order for Mozilla to use any code as part of the mozilla code base, it must either be licensed under the NPL or the MozPL.

A third party can license their original code under the MozPL for original (not-derived) work. (If you modify an NPL file, then those changes are subject to the NPL; however, code that is not a modification may be licensed under the MozPL). More info is at http://www.mozilla.org/NPL.

As an example of this in practice, take a look at the contribution of the expat XML parser by James Clark. It is licensed under the MPL. In this case, Netscape has no special rights.

One interesting aspect of the expat contribution is that Clark grants the option to alternatively (although not concurrently) use expat under the GPL.

I hope that's clear. (And thank god I am not a lawyer, and if I was, thank god I am Anonymous, and, by the way, I am not part of Mozilla.org, nor an employee of Netscape ... just a random reader/writer, etc. ...)

Modifications to NPL-covered code are themselves covered by the NPL.

However, independent work that is combined with NPL-covered work is not covered by the NPL or any other license (other than one you choose).

In order for Mozilla to use any code as part of the mozilla code base, it must either be licensed under the NPL or the MozPL.

A third party can license their original code under the MozPL for original (not-derived) work. (If you modify an NPL file, then those changes are subject to the NPL; however, code that is not a modification may be licensed under the MozPL). More info is at http://www.mozilla.org/NPL.

As an example of this in practice, take a look at the contribution of the expat XML parser by James Clark. It is licensed under the MPL. In this case, Netscape has no special rights.

One interesting aspect of the expat contribution is that Clark grants the option to alternatively (although not concurrently) use expat under the GPL.

I hope that's clear. (And thank god I am not a lawyer, and if I was, thank god I am Anonymous, and, by the way, I am not part of Mozilla.org, nor an employee of Netscape ... just a random reader/writer, etc. ...)

And when you find a bug -- or think you've found a bug -- check out the bug writing guidelines for more information on how to report a good bug.

To report a bug in the bug writing guidelines, mail the authors listed at the top of the page. =)

And when you find a bug -- or think you've found a bug -- check out the bug writing guidelines for more information on how to report a good bug.

To report a bug in the bug writing guidelines, mail the authors listed at the top of the page. =)

Shaver requested:

good, concrete suggestions on what would make you want to contribute are always welcome.

I'm not likely to even attempt to become a core Netscape/Mozilla/Gecko developer, since I've got too many other things on my plate. However, I (and I assume there are many many others like me) would be eager to contribute little things here and there, assuming certain things are the case.

First, it would need to be at the point where I can use the program regularly. As the milestones go by, this is becoming true for more and more people. This also explains why the number of contributors is increasing. So far, so good.

Second, the program would have to be imperfect in my eyes. Any contributions I (and people like me) are likely to make are the itch scratching type. Since perfection is essentially impossible in a large project, that one should be easy to cover.

Third, the code would have to be fairly easy to grok. If I have to spend a week narrowing down the location of the feature I want to tweak to be spread amongst twenty files of spaghetti code, I'm going to do something else instead. I have not looked closely at the Mozilla code, but if, as you say, a significant portion of bug reports come with patches, this is not likely to be a problem.

Lastly, there has to be an easy way for me to get contributions to the project. As long as bugzilla stays up and used, that's covered quite well.

So basically, it looks like the Mozilla project is doing all the right stuff from my viewpoint. It's just a matter of time, time to get it closer to feature complete, and time spent using Mozilla by busy but well-wishing programmers like me. I think you will see the number of auxilliary developers grow very quickly over the rest of the year, and even faster next year.

As for getting more core developers, someone else would have to answer that.

As far as I understand the license, yes, you can. From the Netscape Public Licence:

6.2. Effect of New Versions.
Once Covered Code has been published under a particular version of the License, You may always continue to use it under the terms of that version. You may also choose to use such Covered Code under the terms of any subsequent version of the License published by Netscape. No one other than Netscape has the right to modify the terms applicable to Covered Code created under this License.

This means, or should mean, that if AOL wants to pull the plug, they can do so by keeping for themselves all the code they develop from now on. But the code already released can always be used in the terms of NPL 1.0.

I believe that, if mozilla.org shuts down, the development of the browser can continue elsewhere. Sure, won't be the same code used by "Netscape Communicator 7.532", but I don't think anyone cares about that.

Oh, and IANAL etc.

The vast majority of the Mozilla code is cross-platform, with per-platform differences abstracted under NSPR, widget and gfx code. What were you trying to work on that was in platform-specific code?

If you have a patch that you want to put in, and you don't have the ability to test it on other platforms, please send it along. File a bug describing what you're fixing, and attach the patch to the bug. Look in the owners list and send your patch to the owners of the affected module(s). If you do that and aren't happy with the results, please mail me.

Lots of people manage to work successfully without direct access to the other platforms; I don't have Windows installed here either, and I do just fine. We can find you ``platform buddies'' to help you check your code on other platforms, if need be.

What open source projects do you contribute to? Which ones have a small enough codebase and narrow enough platform focus to suit you?

The vast majority of the Mozilla code is cross-platform, with per-platform differences abstracted under NSPR, widget and gfx code. What were you trying to work on that was in platform-specific code?

If you have a patch that you want to put in, and you don't have the ability to test it on other platforms, please send it along. File a bug describing what you're fixing, and attach the patch to the bug. Look in the owners list and send your patch to the owners of the affected module(s). If you do that and aren't happy with the results, please mail me.

Lots of people manage to work successfully without direct access to the other platforms; I don't have Windows installed here either, and I do just fine. We can find you ``platform buddies'' to help you check your code on other platforms, if need be.

What open source projects do you contribute to? Which ones have a small enough codebase and narrow enough platform focus to suit you?

The vast majority of the Mozilla code is cross-platform, with per-platform differences abstracted under NSPR, widget and gfx code. What were you trying to work on that was in platform-specific code?

If you have a patch that you want to put in, and you don't have the ability to test it on other platforms, please send it along. File a bug describing what you're fixing, and attach the patch to the bug. Look in the owners list and send your patch to the owners of the affected module(s). If you do that and aren't happy with the results, please mail me.

Lots of people manage to work successfully without direct access to the other platforms; I don't have Windows installed here either, and I do just fine. We can find you ``platform buddies'' to help you check your code on other platforms, if need be.

What open source projects do you contribute to? Which ones have a small enough codebase and narrow enough platform focus to suit you?

If you don't recall, Netscape purchased Gnuhoo/Newhoo/Open Directory ( directory.mozilla.org) a while back with the intent of tying it to Mozilla. Will OpenDir be dropped come Mozilla final in favor of google, or will the two establish some sort of relationship? For instance, would dmoz abandon its search backend in favor of Google?

Why not just grab it out of the CVS repository? I follow the CVS tree and compile a new version every few days; since around M5, the tree is usually always compileable without difficulty.

Proxy looks to still be broken. Take a look at Bug 8859 at bugzilla.

When it get fixed, just try adding user_pref("network.proxy.http", "localhost:8000"); to the file prefs50.js

Proxy looks to still be broken. Take a look at Bug 8859 at bugzilla.

When it get fixed, just try adding user_pref("network.proxy.http", "localhost:8000"); to the file prefs50.js

Check the bug database. If it's not in there, then add it. Bugzilla is too cool.

Not quite. At about M9, Mozilla will be about ready to go beta (see this page, where they describe all the "pre-beta work" that needs to be done for M9). It'll be more or less feature complete, but there are sure to be many bugs to fix in successive milestones.

Mozilla actually seems to be using a rather traditional development model, where the focus is on producing one version that's as perfect as possible before moving on to the next, as opposed to the continuous development, two-track model of, for example, the Linux kernel. IIRC, this is one of the things to which JWZ attributed the project's failure to attract many outside developers. If they'd gone with continuous development, they probably would have kicked a version based on the old layout engine out the door long ago, and started a parallel track to work on NGLayout. Perhaps this would've led to increased interest in the project and a stronger Mozilla today than they've managed to assemble by trying to get it perfect the first time. It also might have kept Netscape from having to divert resources to Communicator 4.5 and 4.6 while they waited for Mozilla to come together.

Of course, that's hindsight for you. In any case, a quality free software browser will be well worth the wait.

AC

Original AC here.

I'd be interested to know what kind of Mac you're using as well as which versions of the progams.

I've got an iMac rev. A (guess where I go to school... :) with OS 8.6, Communicator 4.6, and IE 4.5. I agree with many of your points about IE: it renders faster, has a prettier UI (I love its configurable toolbars), and has cookie management that's head-and-shoulders above anything else I've seen. I happily used Mac IE 4.0x as my regular browser for months, and I still use OE instead of BlitzMail for much of my e-mail. IE 4.5 simply does not play nicely on my system.

Of course, I could reload IE 4.0, but while I was troubleshooting 4.5, Communicator just grew on me. It's not as snappy at rendering, but it does a better job of it. It doesn't crash as often (for me) and when it does crash, it crashes cleanly and doesn't take my system down with it, unlike IE, which sometimes dies so horribly that a hard reset is needed. Your machine might well respond differently. I say, hooray for competition, so we can each use what works. :)

Now if we could only get stronger competition for Netscape on Linux. I have high hopes for Mozilla, but it's by no means ready for prime time (This is milestone 6 out of 16 planned milestones.) Netscape's the only Linux browser I know of that's all there today, but it's not very PowerPC architecture friendly: it takes nasty hacks to make it work with the new glibc (as on LinuxPPC R5 or Debian).

AC

According to the release notes, the Mac version is available on June 1.

One the one hand, this creates an extra layer between the browser core and what you see on the screen, if you will -- on the other, it means you can create new skins for Moz with a text editor. :-) XUL and RDF: The Implementation of the Application Object Model is a good starting point if you want to learn more about it.

You can copy your current bookmarks to your mozilla directory, like this:

cp ~/.netscape/bookmarks.html mozilla/package/res/rdf/bookmarks.html

That's discussed on the release notes.

Well, the website still doesn't say anything about it, but the ftp link just has a case-sensitive typo in it. Here's the real link.

M6
bob

M6 this link works bob

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.
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

Well folks, I would say this is not completely unwelcome--4.6 does seem a little more stable than 4.51 was, although even so, I still can't get it to run more than a few minutes without crashing. And worst of all, unlike the current Mozilla SeaMonkey project, 4.6 is still proprietary, so don't even think about trying to go into the code and trying to fix the bugs yourself... If you don't like the bugs, tough--you'll have to live with them. Personally, I think Netscape has got to be the most unstable, bloated piece of software I've seen for Linux yet. I think the Linux platform is desperately in need of a better browser. I say, while 4.6 is a nice interim measure, at the same time, I hope Netscape isn't spending too much in the way of resources on the 4.x line still, for as Jamie Zawinski said, Netscape sunk a huge amount of engineering effort into the 4.5 release in 1998, and that was a huge blow to Mozilla.

And on this front, I would say that Mozilla SeaMonkey is currently our best (and maybe our only) hope of getting a better browser for Linux... And what could be better? It is even open source! I therefore would like to call to all of you to help with the Mozilla project. Let us prove to Jamie Zawinski that all Mozilla needed was a little time.

I am one of the people who is contributing. Admittedly, I am not much of a coder--I only just completed some introductory C/C++ courses. But you do not even have to know C/C++ to do things like file bug reports, or even just give tips. For example, check this out. These open source tools were suggested to them by me.

Or, check out bug reports, like this. I submitted the patch that fixed that bug.

My point is, you don't have to know much about programming to help. And I think Mozilla deserves all the help it can get right now. So please, let us help Mozilla.

In case you people want to know what Mozilla is like... Let me say:

1) It is a radical departure from the old Netscape, and about time, too.
2) It is STANDARDS based. Example: ALL CSS1 properties are now supported.
3) It is truly cross-platform, unlike IE. Cross-platform UIs are built using a form of XML, in .XUL files. These are really cool.
4) It will support Skins (or Chrome), much like WinAmp. Skins anyone??
5) Also please check out MozillaZine. They have some chrome available there.

Well folks, I would say this is not completely unwelcome--4.6 does seem a little more stable than 4.51 was, although even so, I still can't get it to run more than a few minutes without crashing. And worst of all, unlike the current Mozilla SeaMonkey project, 4.6 is still proprietary, so don't even think about trying to go into the code and trying to fix the bugs yourself... If you don't like the bugs, tough--you'll have to live with them. Personally, I think Netscape has got to be the most unstable, bloated piece of software I've seen for Linux yet. I think the Linux platform is desperately in need of a better browser. I say, while 4.6 is a nice interim measure, at the same time, I hope Netscape isn't spending too much in the way of resources on the 4.x line still, for as Jamie Zawinski said, Netscape sunk a huge amount of engineering effort into the 4.5 release in 1998, and that was a huge blow to Mozilla.

And on this front, I would say that Mozilla SeaMonkey is currently our best (and maybe our only) hope of getting a better browser for Linux... And what could be better? It is even open source! I therefore would like to call to all of you to help with the Mozilla project. Let us prove to Jamie Zawinski that all Mozilla needed was a little time.

I am one of the people who is contributing. Admittedly, I am not much of a coder--I only just completed some introductory C/C++ courses. But you do not even have to know C/C++ to do things like file bug reports, or even just give tips. For example, check this out. These open source tools were suggested to them by me.

Or, check out bug reports, like this. I submitted the patch that fixed that bug.

My point is, you don't have to know much about programming to help. And I think Mozilla deserves all the help it can get right now. So please, let us help Mozilla.

In case you people want to know what Mozilla is like... Let me say:

1) It is a radical departure from the old Netscape, and about time, too.
2) It is STANDARDS based. Example: ALL CSS1 properties are now supported.
3) It is truly cross-platform, unlike IE. Cross-platform UIs are built using a form of XML, in .XUL files. These are really cool.
4) It will support Skins (or Chrome), much like WinAmp. Skins anyone??
5) Also please check out MozillaZine. They have some chrome available there.

The Mozilla project does indeed include Composer. However, the need for a more powerful graphical editor in the same realm as Dreamweaver is great, IMHO. Composer could possibly be extended to provide such functionality, but its greatest strength in most cases is its simplicity... I'd hate to see that compromised. I'm assisting in the creation of the curriculum for a high-school-level class in Linux. Tentatively, one section of the class is on building Apache and managing a small Web presence. I'd like to couple the Web serving unit with a unit on Web design, but I'm in need of a design tool comparable to Dreamweaver, I believe. So, in essence, is anyone working on one? If I can't find a suitable application, I'd settle for running Dreamweaver within WINE. Has anyone experimented with this? The reports on WineHQ are a bit sketchy.

Go to bugzilla.mozilla.org and file a bug report. I've reported a dozen rendering bugs and the Mozilla developers have been very keen about fixing these "minor" bugs. Rock on!

In fact, the switch to the expat parser found a pile of well-formedness errors in our XUL files, so I'm pretty sure they're correct. Maybe you need a newer version of expat?

• the well-formedness expat code
• Nisheeth Ranjan on well-formedness errors
• Nisheeth Ranjan on entities (kinda)

ftp://ftp.digiforest.com/mirrors/mozilla-m5/ ( link )

25 users because I've never mirrored something and posted the URL to slashdot before. If things go well and I don't get attacked I might mirror other things as well. It's a dedicated, Bay-compressed, PtP T3. Have fun.

And read the release notes!

R.

Please also note that posting complaints, or half formed bug reports do virtually no good in the Slashdot forum besides inflaming troll like feelings or pointing developers in directions that they should not be headed in.

More informed users would be better served by checking out the well written bug reporting documentation located here!

I want to die peacefully in my sleep as my grandfather did...

Please also note that posting complaints, or half formed bug reports do virtually no good in the Slashdot forum besides inflaming troll like feelings or pointing developers in directions that they should not be headed in.

More informed users would be better served by checking out the well written bug reporting documentation located here!

I want to die peacefully in my sleep as my grandfather did...

> I have no idea what milestone 5 means.

See: http://www.mozil la.org/projects/seamonkey/release-notes/index.html

Check under Project Sea Monkey. You probably want to see the milestone plan.

There are release notes, too.

Check under Project Sea Monkey. You probably want to see the milestone plan.

There are release notes, too.

Check under Project Sea Monkey. You probably want to see the milestone plan.

There are release notes, too.

Would you mind filing a bug on this?

Hi, there. I've been looking around for a bit, and I can't find a single ``open developer'' -- defined as someone who has contributed a single line of code or more -- who objected to the chat-in-mozilla stuff. Can you point me to one?

I think I know why I'm having trouble, though: those who actually contribute know enough about the architecture of mozilla to realize that this is an optional component that you can add or remove as desired, like mail/news.

Actually, I think that anyone who cared to click the link could figure that out as well, since it's clearly mentioned that it will always be possible to build the client without any chat support at all.

Mozilla work on all kinds of projects beyond the direct push towards the codebase for Netscape 5.0. All those handy development tools, for a start. Plus oddballs such as ElectricalFire and Grendel. This is just another idea that's being bounced around. I really don't expect it to take away programmer time from work on the main browser core. But on the otherhand, maybe some of us would like to hack on this.

Complaining won't do any good -- if you don't want to code, just sit back and wait for 5.0, then use it however you like. Or don't, if you prefer, it doesn't really matter. On the other hand, if you do want to take control then get coding, or documenting, or testing, or whatever takes your fancy. This can be your project just as much as it is AOL's. Get to it.

Mozilla work on all kinds of projects beyond the direct push towards the codebase for Netscape 5.0. All those handy development tools, for a start. Plus oddballs such as ElectricalFire and Grendel. This is just another idea that's being bounced around. I really don't expect it to take away programmer time from work on the main browser core. But on the otherhand, maybe some of us would like to hack on this.

Complaining won't do any good -- if you don't want to code, just sit back and wait for 5.0, then use it however you like. Or don't, if you prefer, it doesn't really matter. On the other hand, if you do want to take control then get coding, or documenting, or testing, or whatever takes your fancy. This can be your project just as much as it is AOL's. Get to it.

From what evidence I've seen, your accusation seems rather unfair - or at least, there's been no obvious sign yet that Netscape or AOL executives have been imposing their will on the Mozilla full-timers. (I certainly can't deny that they could if they decided to.) Quite the opposite: what seems to be delaying Mozilla most is the desire to redo nearly everything from scratch, which certainly suggests an engineer-driven rather than a manager-driven project to me.

"The whole IM/Chat module will be an separate module from the rest of the Mozilla client; it will be possible to build the client without any IM/Chat support at all."

Mozilla has a component model. Mozilla supports dynamically loadable components. It's not like it will be one huge binary.

And now we see why...

jwz has abandoned the project. Boy, the developers over there learned their lesson for all of a week. I had such high hopes for the project. Oh well.

Actually, this was jwz's idea, almost a year ago: see the mosaic of chat from Mozilla's "Blue Sky" pages, from almost a year ago now. As the page's title (Unity of Interface) suggests, he argues that a generic chat UI should be developed, encompassing the various chat protocols that exist on the net - which sounds quite a lot like this idea.

I note that if you actually read the page this story refers to, you'd have seen this link already.

FWIW, I didn't think I'd want to use an integrated IRC client then - his page notes the difficulties, such as IRC being line-based, while talk is character-based, for one thing - and I don't now. But I don't see how the implementation of a multiple-protocol instant messaging client as a bad thing - just not necessarily integrated with the browser.

.. one of his biggest disappointments was the failure to inspire a large community of developers to join up, and that having so many Netscape full-timers on the project may have violated the dynamics of a culture that thrives on volunteer programming ..

In my opinion full-timers are a great thing. I'd rather say that unusual methods of development make it hard to participate.

Please have a look at the Portability Guidelines on mozilla.org. Instead of porting our tools (egcs) to uncommon architectures developers are expected to spend additional time on writing the program. That's not globally efficient from my point of view.

It's nice that mozilla.org wants do have a port on every system, and I'm sure they're on the right way, but the typical hobby-developer works for his OS, and not for "planetwide" portability. Blaming the full-time-hackers doesn't help us.

I just wonder if you have bothered to RTFRN or to run Mozilla from the daily builds to see the progress? I have been trying them for a while already and there is progress.

A month ago almost no web pages were rendered correclty. Banners were here and there, text running in wrong places etc. But after each and every new version it started rendering better. That's progress.

Also I'd like to point out that apprunner is really pre-code. People really haven't been working on it for long. Most work has been done to create the rendering engine and not for the bells and whistles in the user interface. Also remember that they are creating cross-platform code so it required a lot of planning and programming to even get this far.

I usually use the viewer-program. It's the one that has been used to develop the rendering engine. No bookmarks or anything but it has been pretty stable and fast for me. To get an idea of Mozilla's speed, go visit sites with a lot of tables and resize the window. On my PII it's about ten times faster than Communicatore 4.51.

So if you don't mind it crashing 10 times a day, rendering pages wrong and not giving you everything a finished product does, go and try it. But if you don't understand what M4 is, do find out before whining.

I see someone pointed you at mozilla.org's ftp server already. But even if there's not an 'M4' source tarball, that only means it hasn't been packaged yet.

You can get the up-to-the-second source with CVS anytime you like. Afaik, there's an M4 branch you can use, if you don't want to get the code people is hacking at right now. Ask around in the mozilla newsgroups about this.

Release notes

A lot of tests out there (including more than a few real-world sites) fail on Gecko because they work around bugs in existing software. The test might just be broken by design, and Gecko is doing the Right Thing when the site looks broken. (Unlikely if you're using a W3C test suite, but still possible...)

Gates said there was clearly a market for free software but this was mainly confined to relatively simple applications such as word processing and spreadsheets
Uh... Its been a while since I would call Word or Excel "relatively simple" by any stretch of the phrase.

Modern browsers were far more sophisticated and could no longer be developed in a noncommercial environment.
Guess he hasn't seen mozilla in a while. Furthermore, doesn't it seem that most of the "complexity" [read: badly implimented features] in browsers are due to Internet Explorer.

Gates said, for example, that there were five different windowing systems that run on Linux.
Even if I agreed with him on his definition of "windowing systems", doesn't more = better?!

I guess the main thing we can garnish from comments from "The Man" like this one is that they are scared. Very scared. Now more than ever it is time to support GPLed projects for linux. If we can evolve quickly they won't even notice as we stride past them.