Is K-meleon kind of stalled at the moment, or has it been put to a kind of back-burner status to see if Firebird obviates the need for it? It seems like the native browsers in general (Galeon, Camino, and K-Meleon) have all hit a development lull since Firebird started getting wider releases, and it makes me wonder if the owners of the projects are either working on Firebird or are thinking that Firebird will obviate the need for the separate projects.

I'm a Firebird fan - I use Windows, Mac OS X, and Linux machines, and it's nice being able to use the same high performance browser on all of them - but I am still interested in the native browser projects.

So, is K-Meleon stalled out right now, or is it moving ahead?

It's moving ahead at a stalled pace...How about that?

I'm just guesing, but as far as I can tell, when Moz 1.4 final comes out, KM 0.8 will use that as its base. Figure some time after that to get a new KM 0.8 release out.

N

what happens after 1.4 when the suite is no longer being actively developed? is the KM team going to switch to the firebird codebase ("Mozilla Browser")?

how ironic that would be after all the petty flaming that goes on in this forum over firebird.

"The release of Safari has generated some discussion of Gecko's complexity and performance which bear addressing. Gecko is large and complex. We would like Gecko to be smaller and simpler and we're working on it. Elegance, like speed, is sexy. But simple and elegant must be weighed against the need to cope with web content as it exists today. And web content today is not simple, not elegant and not standards compliant. Today's web requires a rendering engine to do gymnastics to understand the wildly varying ways in which websites operate. Gecko performs these gymnastics with exceptional precision.

[...]

What is clear is that both Camino and Safari are wicked fast browsers. This is excellent news. In addition, Safari uses code and ideas from Gecko, and high quality ideas from the KHTML/Safari world will make their way back into Gecko. This brings benefits to both layout engines. The big picture question is the performance of open alternatives compared to that of the dominant Internet Explorer browser, and the open source community can share satisfaction as the open alternatives continue to improve."

From: http://www.mozilla.org/browser-innovation.html
(emphasis mine)


"WHAT DOES ALL THS MEAN

[...]

* We are not deprecating XUL in favor of front ends based on native GUI toolkits. Nor are we deprecating Camino, Mozilla's Gecko-based browser that has a native OS X front end. Both approaches have their wins, and their loyal fans. The Mozilla community has embraced both approaches (even producing a version of Phoenix for OS X that tests well).

[...]

* Several crucial tools integrated with the XPFE-based browser, the DOM inspector and Venkman (the JavaScript Debugger), must be supported in the new, standalone browser, as add-ons.

[...]

APPLICATION ARCHITECTURE

Let's begin the new application architecture proposal by recapitulating the relevant facts and defining some terms.

There are currently two major classes of applications being built using Mozilla's technology. The first class of applications are embedding applications. They use Mozilla's layout engine, but write their own code for user interface features that exists outside of the laid-out HTML or XML document view. The second class of applications are toolkit applications. They are built on top of Mozilla itself and designed to be cross-platform. The user interface elements are defined in XUL and rendered by Gecko itself.

Both classes of applications will be able to make use of the Gecko Runtime Environment (GRE) to enable the sharing of a single installation of Gecko. Applications may even share profiles, although the inter-process communication work to support sharing profiles among applications running in separate processes is not done yet (as of 1.4alpha).

[...]

In addition, we propose that certain toolkit applications should themselves be extensions, meaning that they can be built both as standalone applications and as add-ons installed into other applications. An example of such an application is Thunderbird, a.k.a. Mozilla Mail, which will be capable of either running as a standalone application or being installed directly into Mozilla Firebird, a.k.a. the Mozilla Browser, as an extension."

From: http://mozilla.org/roadmap.html
(emphasis mine)


Shelumi`El
Jordan

S.D.G

Just so there is no confusion, it should be understood that K-Meleon and Firebird both use the EXACT same rendering engine (Gecko) as does the old Mozilla suite; and the only difference between them is the User Interface (in K-M, win32api; in Firebird, Firebird Toolkit; in Mozilla, Cross-Platform Front End Toolkit).

Thus, as long as Firebird is developed, Gecko will be developed, and, I would assume, K-M will be developed.


Shelumi`El
Jordan

S.D.G

Yes, gecko (nglayout or whatever) is and always will be the core of the entire project, but the fact of the matter is, development is going to be guided by the focus of the project. for *years* that has been the entire application suite. Now it's going to be firebird (primarily) and thunderbird. I just find it ironic.

In addition to the quote you provided from the new roadmap I feel that it must be noted that the mozilla organization has many times before released statements about the status of gecko code quality in relation to KHTML. In essence, they've said that the KDE code is much tighter and cleaner, but that on the other hand the KHTML widget is sorely lacking in the portability and maturity departments (which makes it easy to understand why Apple chose KHTML: it's far cleaner and easier to adapt - Apple is the antithesis of hardware diversity - even if at the expense of gecko's maturity). I commend the mozilla team for how far they've come in the past few years, alas it goes greatly unnoticed as the significant improvements are on *nix. Mozilla still takes a year and a half to start on windows for me, but when I boot back into linux it loads up *extremely* quickly (without ever being preloaded into memory). That's where K-Meleon fits in, and does so well.

SO......... Development IS stalled?

Well the usual directive is to point somebody to the dev's mailing list for clarification that development is continuing, but admittedly it is getting very slow nowadays. Just heard that Mozilla 1.5 RC1 is out, which means that it's only a matter of time before the final version is. K-meleon v0.8 is supposed to be based upon Mozilla v1.4 final, so even when it does come out, the rendering engine will still be behind that of the current versions of both SeaMonkey and Firebird.

Though the rendering engine isn't really changing all that much right now (I think).

One major issue right now is that this project needs more people on the development team. There just aren't enough people to progress any faster.

Non-programmers can also be of great help. Some work has been done on a User's Guide for KM, but IIRC they need someone to take responsibility for maintaining it. I think Ulf made a request on the developer list about this fairly recently and there was no response. If more people don't step to help out, this project will likely die.

Is anyone here available to work on this aspect (the manual)? Or perhaps a few people working together? If several are willing to do a small part, it would not be a huge job.

Though the rendering engine isn't really changing all that much right now (I think).

I guess there aren't any huge changes, and just having a look at the release notes for Moz v1.5RC1, here are a couple:

>The '::' notation for CSS pseudo-elements is now supported. The old ':' notation is still supported for the various -moz-* pseudo-elements, but will NOT be supported in Mozilla 1.5. Themes should be updated to use the '::' notation for pseudo-elements.

>Unstyled XML display has been improved.

>Gecko now supports setting color for <HR>.

So maybe that's the only rendering engine changes, but still significant to note.

As for the manual, that would be a nice addition, but still it isn't what's slowing down the browser's development, lack of developers is. In much the same way that a lot of the documentation eventually came together on this website, so too will a manual in time.

Andy Korvemaker (---.ab.tac.net)
Date: 09-20-03 15:58

"Though the rendering engine isn't really changing all that much right now (I think).

One major issue right now is that this project needs more people on the development team. There just aren't enough people to progress any faster."


Anderson Che writes Avant Browser all by himself. The updates come out with great regularity , the features and ease of operattion as well as installation are superior.

Al: Good point about those few changes that are happening. For the manual, I was mostly pointing out that it is one part of the project that non-programmers could help out with. Definitely, it would be nice to have more programmers as well. Also, I believe that until recently one of the programmers was also handling the manual. If others took this over, it would be one less thing on his plate (though I think he has no plans to continue working on it himself).

bigbud3: I have heard a number of good things about Avant Browser's usability. It sounds like Anderson Che is doing a great job, but I consider is somewhat irrelevant. The K-Meleon devs are not Anderson Che. They do not have the time to put more into this project. If we want it do develop any quicker, we need to find more programmers willing to help out.

The other thing about Avant Browser is, the author doesn't have to worry about integrating a seperate rendering engine into the browser every time he brings out a new release, as Avant Browser is just utilising the IE rendering engine, which is already there in Windows. All he has to do is work on the shell, which Avant Browser is. Don't get me wrong, I'm not knocking these other browsers like Avant or MyIE2, it's just that there's not as much work involved bringing it all together.