K-Meleon was mentioned on MozillaZine yesterday (regarding the updated favorites plugin) but in the responses to this posting one of the Mozilla developers (Asa) said the following about K-Meleon and Chimera (and presumably Galeon too) -

"But if they really did care about footprint and performance they would be hacking on the rendering engine becuase it's the most heavy-weight component there is."

What an idiot !! He's probably jealous because the very existence of K-Meleon, Galeon, and Chimera prove that XUL is resource hogging, poor performing, bloat. Like it or not, XUL is without a doubt the primary reason that Mozilla is so big and so slow. XUL gives new meaning to "heavy-weight" and bloat. What a dumb and lazy idea to have a user interface written in an interpretive language and have to process a huge "fastload" file and many many other files, some zipped in .jar files. If Mozilla had used a native OS interface for each of its primary OSes (just like Netscape 4.x did) then it would be much further along than it is, more stable, much faster, much smaller, and have a larger market share than it does now. The Mozilla developers such take a page from the K-Meleon, Galeon, and Chimera developers book and scrap XUL instead of bashing them. No they're not making Gecko lighter and faster per se but they're certainly making a lighter and faster Gecko browser for their respective OS.

Here's Asa response, Asa you suck.
http://www.mozillazine.org/talkback.html?article=2846&message=4#4

asmpgmr,

I didn't interpret his comments as directed at K-Meleon. Asa has generally been supportive of spin-off projects so I don't think he intentionally bashed K-Meleon. He occasionally posts here too. Maybe he can respond for himself.

Andrew,

I get the distinct impression based on various comments from them that the Mozilla devs don't like any of the lightweight browser projects (K-Meleon, Galeon, Chimera) because they show what a bunch of bloated ill-conceived crap XUL really is and that they put a whole LOT of effort into a really bad UI design.

I've tried Mozilla 1.1 and 1.2 and was underwhelmed by both. Mozilla is the slowest and most inefficient piece of software I've ever seen and I've been in the field since the 80s.

You may be right and he's just mad over Apple going with the KHTML engine but to imply that the other project devs don't really care about footprint and performance is ridiculous and hypocritical. If the Mozilla devs actually cared about footprint and performance then they wouldn't have created XUL and the rest of the "Mozilla X Files" now would they ?? They should just admit that their XUL-based UI sucks and dump it in the bit bucket where it belongs and go with native OS interfaces for Mozilla 2.0 and maybe Mozilla will actually capture more than 0.8% of the browser market.

> I get the distinct impression based on various comments from them that the Mozilla devs don't like any of the lightweight browser projects (K-Meleon, Galeon, Chimera) because they show what a bunch of bloated ill-conceived crap XUL really is and that they put a whole LOT of effort into a really bad UI design.

That is a very "interesting" point of view you got there, especially since one of the guys working with XUL based Mozilla & Phoenix, David Hyatt, also happens to be one of the guys that started Chimera.
Please explain why you think someone that hates eg Chimera can also be one of the driving forces behind it actually exsiting in the first place...

> XUL is without a doubt the primary reason that Mozilla is so big and so slow.

I disagree. While a nonnative layoutengine can never be as fast as a native, XUL itself isn't all that taxing as you seem to belive. It uses the exact same syntax and engine rendering functions as a webpage (becuse the UI literally is a webpage). Thus to show a webpage you need to implement all that code in the engine anyway. The slowing down is just from having to "load an extra webpage", and that in itself really doesn't make such a huge difference as you make it out as.

No, the reason Mozilla is big and slow in general, is becuse it's generally bloated, not simply becuse it uses XUL. The Moz devs also knows this, that is why you are seeing side projects like Phoenix and GRE poping out of the ground.

> You may be right and he's just mad over Apple going with the KHTML engine

I don't think he is mad about that. And if he would have been mad, then I'm sure he wouldn't still be mad after such a very long time (remember that Asa probably knew about Apple going with KHTML about a year ago).

> but to imply that the other project devs don't really care about footprint and performance is ridiculous and hypocritical.

I don't know the facts in the matter, but did you consider that he might be right?
Does anybody know how many speedincreasing patches for the gecko engine that the K-Mel devs have contributed to the Mozilla Trunk?
Or how many speed improving changes have been made to the default gecko embed engine?

But i guess, since your very strong opionion is that Asa is wrong, you might be able to educate me by providing the links to these paches and changes?

> maybe Mozilla will actually capture more than 0.8% of the browser market.

Gecko based browsers passed 0.8% a long time ago.

I think it's safe to say that there was some confusion on Asa's part. The discussion was about KTHML and it sounds like Asa is saying that KHTML is gecko based, which it's not. KHTML has no relationship to Gecko, or KMeleon. KHTML is a rendering engine that Apple's new browser, Safari uses.

Joseph Elwell.

Joe,

No there was no confusion on Asa's part. If you read the entire thread someone asked how K-Meleon compares to KHTML (which is a separate rendering engine) and that's a valid question. Someone else responded that K-Meleon uses a native OS UI like Chimera instead of XUL and that Phoenix is waning. They also said that KHTML appears to focus on performance and footprint over standards compliance. Asa then responded with his crap which sounded kinda bashy and hypocritical to me.

Stefan,

As for Mozilla, yes XUL is the main reason why Mozilla is so big and so bloody SLOW. I've tried Mozilla 1.1 and 1.2 on my system and both sucked and got deleted due to extreme lack of performance. K-Meleon is MUCH faster and since it uses the same Gecko rendering engine and Necko networking code but a native OS UI that proves that XUL sucks since that's the primary difference between the two. In fact every browser I've tried is faster than Mozilla - K-Meleon, Netscape Communicator 4.x, Opera, even piece of crap IE, they all use a native OS UI. Mozilla is SLOW loading, it's SLOW opening menus, it's SLOW opening windows, Mozilla is just plain SLOW. Disregarding performance is stupid.

Also there's far more processing in their sucky UI then is done to render a web page (which is HTML and CSS, not XML), have you looked at all of the files involved in their stupid Mozilla X-Files interface ?

I agree that Mozilla has other bloat issues besides XUL but that accounts for the majority of them. Frankly ALL programs written in object-oriented languages are bloated to some degree just as a function of OO (another poor concept).

The Mozilla X-Files - The bloat is out there.

youre mistaken. XUL is not where the bloat is. There is some bloat, but the phoenix project shows that XUL can be very efficient. the problem stems from Gecko, which was created to run on EVERYTHING. it has huge amounts of platform-specific code it in. and since this project only runs on windows, much of that code can be thrown away. that is what asa was refering to. and it's quite obvious too, but you chose to quote only part of his message, changing the whole meaning.

> that proves that XUL sucks since that's the primary difference between the two.

Um, I can make a list a mile long of things that is not available in K-Mel but that is available in Mozilla.
If you are to compare native vs XUL the at least compare 2 browser only solutions (K-Mel and Phoenix).

K-Mel is still much faster then Phoenix, but Phoenix is already in itself much faster then Mozilla. The speedincrease comes almost entirely from the work of 3 people spending some freetime ripping out general bloat from Mozilla.

How could that make such a huge difference if it really is XUL that makes Mozilla slow? And it's not like there isn't still loads of stuff to rip out off Phoenix to speed it up.

> Mozilla is SLOW loading, it's SLOW opening menus, it's SLOW opening windows

That is a YMMV thing. On my old 450Mhz comp K-Mel loads up lightning quick, but once Phoenix and even Mozilla loads up, opening menus & windows is basicly just as fast in all 3.
OTOH I've heard about people with 1GHz comps that take 30+ seconds to even start up Mozilla, and when my 450 does it in 10 you know that something is wrong somewhere, but that is not nessecarily Mozillas fault. And even if it is, it still might not be the fault of XUL.

A 5 minute assessment is not enough to determine the reason for the browser beeing slow. You need to dig into the engine code and make testcase and benchmarks. Until you do that you don't have facts, only an opionon. And opionons is like assholes, everybody got one

> Also there's far more processing in their sucky UI then is done to render a web page (which is HTML and CSS, not XML)

Due to it's well formedness, XML is actually less resource requireing then HTML, becuse the engine doesn't have to spend time with general error-correction and guessing what/if an optional tag was left out or not.

> have you looked at all of the files involved in their stupid Mozilla X-Files interface ?

No, and I don't think anyone have actually looked at ALL the files.
But why does the number of files bother you at all? They are all packed togheter in jarfiles and read into memory in one fell swoop, not one by one.

> I agree that Mozilla has other bloat issues besides XUL but that accounts for the majority of them.

I would say that Phoenix have already proven that most of the slowdown does NOT come from the XUL.

> Frankly ALL programs written in object-oriented languages are bloated to some degree just as a function of OO

I guess this last section means that you have now changed your mind and agree with Asa that the real attention to speed up Gecko should be put into cleaning up the engine (it's written with C++, an OO language) ?

but the phoenix project shows that XUL can be very efficient.

On my system(celeron 433) there is virtually no difference in load, menu, & window speed between Phoenix & Mozilla. And I'm not exaggerating. Maybe a 3 second load diff between the two but they both take too long to load. And menu and window speed is very sluggish.

asmpgmr ,

I've tried Mozilla 1.1 and 1.2 on my system and both sucked and got deleted due to extreme lack of performance. K-Meleon is MUCH faster and since it uses the same Gecko rendering engine and Necko networking code but a native OS UI that proves that XUL sucks since that's the primary difference between the two. In fact every browser I've tried is faster than Mozilla - K-Meleon, Netscape Communicator 4.x, Opera, even piece of crap IE, they all use a native OS UI. Mozilla is SLOW loading, it's SLOW opening menus, it's SLOW opening windows, Mozilla is just plain SLOW. Disregarding performance is stupid.

You really should try Phoenix. I had the exact same experience with Moz1.x as you, but found Phoenix *much* better (0.4 at the time). The latest release (0.5) makes it even better. I see that "jsnj" claims equal sluggishness for the two on his Celery433, but I can say that certainly isn't the case for my Athlon700.

No, it still isn't as responsive as km - but it's approaching Opera7 fast.

One thing that drives me nuts about Mozilla and Phoenix is that whenever they do something--I've no clue what...but, something--everything thats alpha blended on my whole screen twitches really fast for like 15 seconds (taskbars, gkrellm, et al), then is back to normal...Opera (6 & 7) does it sometimes when it loads java applets, but not for as long, only like 3 secs... browser epilepsia... whatever it is, I haven't had it yet in K-M


Shelumi`El
Jordan

S.D.G

No I shouldn't try Phoenix and I'm not going to, there's no absolutely point considering I'm content using K-Meleon. Phoenix may have less XUL than Mozilla but it still has a lot. Also I'm not saying K-Meleon is perfect but it certainly has a far better and vastly more efficient UI, it's easily configurable and the macro facility is innovative for a browser.

What many don't seem to understand is that XUL is CPU intensive AND disk intensive. Even if you have a fairly fast CPU, if you have a slower hard disk, slower chipset limiting hard disk transfer speed, or the OS IDE drivers are not set to use the fastest transfer method (DMA instead of PIO) then there will be a noticable performance degradation. Also having to load many files leads to more memory usage which leads to the OS having to swap sooner.

Stefan, no I haven't changed my mind and agree with Asa, the real attention in Mozilla should be fixing bugs in the near term (1.x) and switching to native OS UIs in the long term (2.x). I suspect you're a Phoenix fan trolling the lightweight browser forums. If you like Phoenix then fine that's you but don't try to tout it here. I'm not on the Phoenix forums touting K-Meleon (or the other lightweight browsers) or saying what I think about XUL since it obviously would be rejected there.

One thing that really bugs me is that the Mozilla devs and defenders seem to have a blind spot regarding XUL and won't even consider that Mozilla would be MUCH better without it despite the fact that MANY users have complained about its poor performance.

> Phoenix may have less XUL than Mozilla but it still has a lot.

?? What do you mean with less XUL?
An app can either implement XUL or don't implement XUL, there is no inbetween.

> Also I'm not saying K-Meleon is perfect but it certainly has a far better .. UI

Opinions differ. I myself certanly prefer Phoenix's UI over K-Mel's

> the macro facility is innovative for a browser.

Can you please provide an example that makes it so innovative?
Ei what can you do with macros that you can't do in other Geckobrowsers using Bookmarklets?
Even IE can have fav/book-marklets.

> what many don't seem to understand is that XUL is CPU intensive AND disk intensive. Even if you have a fairly fast CPU, if you have a slower hard disk, slower chipset limiting hard disk transfer speed, or the OS IDE drivers are not set to use the fastest transfer method (DMA instead of PIO) then there will be a noticable performance degradation.

When you first load up the app, yes there will be some added diskaccess. After you have it in memory the HD subsystem doesn't matter (that is the state you are in about 99.99% of the time you use a browser).
As I said, you are loading up an extra webpage (from HD) when you start the app. Once it's loaded it's loaded.

> Also having to load many files leads to more memory usage which leads to the OS having to swap sooner.

Yes, IIRC Phoenix will take about 2MB more in memory at startup.
If you have little memory on your system that might make a difference.
On a lowend system, K-Mel will always have an edge vs the XUL Gecko browsers. I havn't seen anyone ever disagreeing on that.

> Stefan, no I haven't changed my mind and agree with Asa

You said all OO coding is bloated and should be avoided. Isn't that exactly the same as saying that you should spend more time with optimizing performance in the Gecko engine (which was what Asa said)?
Since Gecko is C++, which is OO, it certainly needs some attention IYO doesn't it?
At least you wrote in this very thread "Frankly ALL programs written in object-oriented languages are bloated to some degree just as a function of OO (another poor concept)."
Moving Gecko over C from C++ would be nessecary to solve the bloat problem wouldn't it?

> I suspect you're a Phoenix fan trolling the lightweight browser forums.

Yes, it's already been determined on these forums that I'm supertroll #1, simply becuse I stand up to people that spread missinformation and ignorance all over the place.

> I'm not on the Phoenix forums touting K-Meleon

Perhaps you should?
I certainly recomend people on Phoenix forums to try out K-Mel (especially those that have problems with Phoenix or needs functionallity that is available in K-mel but not Phoenix).

> saying what I think about XUL

You are allowed to say anything you like about XUL, but when it's based on ignorance and fiction you are likely to bump into people pointing out all the inaccuracies in your statements.
If you can't handle people pointing out where you are wrong, why do you use an open forum to shares your thoughts and ideas?
Wouldn't pivate e-mails be a better way for you to express your views if you can't handle openness?

> One thing that really bugs me is that the Mozilla devs and defenders seem to have a blind spot regarding XUL and won't even consider that Mozilla would be MUCH better without it despite the fact that MANY users have complained about its poor performance.

Mozilla have for a VERY long time now provided Gecko as an embedding engine so people could easily integrate it into other projects eg K-meleon, using whatever UI system they like.
However what the rabiant anti XUL people constantly keep missing is that mozilla.org is not just about creating a browser. It's about creating an entire cross OS UI programing language that uses open webstandards free to everybody to use.

If you think too little attention is put on optimizing the browser itself, fine, it's open source, add your own code. You can even make a compleate break and take only the bits and pieces you like and make a new browser engine from scratch.

However just complaining about what others do (often on their freetime) will get you nowhere.

When I said K-Meleon has a better UI than Phoenix you know exactly what I'm talking about, stop being so blindly devoted to XUL. If something is bad then recognize it and move on to something better. Blind devotion is a sign of ignorance.

As for macros go search the forums and the website for yourself to see what macros have been written.

Saying that OO is bloated means that all parts of all programs written in it could benefit by being written in a procedural language like C. Your trying to deflect attention to Gecko is again a sign of your blind devotion to XUL. Wake up and realize that XUL is a resource hog, it uses a lot of CPU processing power to parse all of its crap, it uses a lot of memory, and it uses a lot of disk space for files and its "fastload" cache.

What the Mozilla devs and witless defenders don't realize is that almost no one wants anything but a browser suite (browser, mail, news, web page editor). As writing funky "apps" to the browser well we already have an application platform - it's called an OPERATING SYSTEM. Also making a UI which greatly sacrifices performance for cross platform support is simply bad. It makes sense for many types of apps to be cross platform and that is certainly true for the core of a browser but not its UI. There are certainly ways to make a UI that's easily portable between platforms without resorting to ill-conceived interpreted language bloat. Funny I recall a browser suite which used native OS UIs on Win32, Linux/Unix, Mac, and OS/2, it was called Netscape Communicator.

Since you admit you're a troll, please go troll elsewhere.

Hey all,

As a newbie to this forum, I'm not sure if there is some kind of long history that I just haven't read up on but it seems that asmpgmr's interpretation of this Asa guy's comments were a bit off. Asa was referring to KHTML not K-Meleon.

That said, I do agree with asmpgmr that the native approach is best. From what I've observed (and keep in mind I'm still new to all this), Mozilla is trying to be the Swiss army knife/everything in one bucket/Walmart of browsers, just like Netscape and IE before it. Something in Mozilla is slowing down Gecko. Maybe its XUL, maybe its Xenu. It still performs extremely well in standards compliant rendering, better than IE and even Netscape. However, what the K-Meleon expression of the Gecko engine brings, and where it kicks Mozilla in the beanbag, is the fastest (at least according to my crude stopwatch tests) displays of standards compliant rendering for the Win32 platform. Isn't it okay to just want a fast browser?

I'm a recovering ignorant end user and I don't need to go cross platform. XUL makes no difference to me. Phoenix is nice but K-Meleon is sweetest for Win32 and makes the best argument against the all in one packaging that M$ pushes and the Mozilla browser approach seems to emulate. This is not a troll, just an opinion. Please try not to mock me to angrily. >:]

> When I said K-Meleon has a better UI than Phoenix you know exactly what I'm talking about,

Yes, you are expressiong your own personal view. Though I'm not sure why you feel I'm not allowed to have a different view.

Or are you refering to something else? It's a bit hard to tell becuse you don't quote the sections you are refering to.

> As for macros go search the forums and the website for yourself to see what macros have been written.

YOU are basicly stating that macros are a great thing that is not available in other browsers.
All I'm asking for is that you provide 1 single example showing what macros can do that is not possible in eg Phoenix using a bookmarklet.
This is backing up your statements with facts and I'm not about to do that work for you. You, as every body else, have to back up your own statments.
Anybody can say anything, but if you can't back it up with facts it's just empty words in the wind.

You might be right that macros is indeed a clear advantge, but right now even you don't know if this is the case or not, becuse you didn't check the facts.

> Saying that OO is bloated means that all parts of all programs written in it could benefit by being written in a procedural language like C. Your trying to deflect attention to Gecko is again a sign of your blind devotion to XUL.

YOU started this thread in an angry assault against Asa becuse he said Gecko could be improved upon (escpecially for a single OS port with no XUL). How can I be trying to "deflect attention to gecko" then Asa's comment about eg K-Mels use of Gecko IS WHAT YOU STARTED THIS TOPIC ABOUT.

> Also making a UI which greatly sacrifices performance for cross platform support is simply bad.

I agree. Where we don't agree is that XUL is such a great sacrifice in performance. It works just fine for me on 450Mhz Celery and with 3Ghz computers beeing sold today cross OS functionallity and ease of use (to create applications in) matters much more in the real world the a few percent increased resource vs a native UI making a browser sluggish on a 200MHz comp.

> we already have an application platform - it's called an OPERATING SYSTEM.

Of which there are several. That is why you need something like XUL using open standards for cross OS UIs...

> and it uses a lot of disk space for files and its "fastload" cache.

Please tell me you are joking...
K-Mel download 5.0MB
Phoenix download 6.1MB (and ever dropping as bloat gets ripped out)

How is 1MB going to make a difference on a Multi GB drive?

> It makes sense for many types of apps to be cross platform and that is certainly true for the core of a browser but not its UI.

That is your opinion and it's definitly not shared by everybody.
Eg I'm sure many users on OSs other then the big 3 are absolutely extatic about XUL, which allows them to use the latest and greatest software imediately on release instead of waiting for a possible port arriving 6-months later.
We can also look at the big 3, Win, Lin, Mac. Apart from Mozilla and XUL, is there any other frequently updated software imediately available on all these 3 OSs?
Please name it if you happen to know of any.

> Funny I recall a browser suite which used native OS UIs on Win32, Linux/Unix, Mac, and OS/2, it was called Netscape Communicator.

And the guys that used to do Netscape Comunicator is the same guys that made XUL. Dont' you think THEY from experience knows which way is the better in the longrun...

> Since you admit you're a troll

No, I was saying that you are not the first religious browser fanatic that have called me a troll for standing up against their ignorace.
For some reason ignorance, swearing and verbal assault of others is typical for persons that are quick to call others a troll. You fit into that cathegory quite nicely

Rendering speeds should be virtually identical for all Gecko-based browsers. The big difference talked about above is the User Interface.

-fyo

> From what I've observed (and keep in mind I'm still new to all this), Mozilla is trying to be the Swiss army knife/everything in one bucket/Walmart of browsers

Yes, that is the real problem. Too much integration and you end up bloated.
They are trying to do something about it though, eg with Phoenix and Minutaur (stand alone versions of Mozilla browser and mail respectivly).

> This is not a troll, just an opinion.

And a sencible opinion based on facts and your needs and preferences. Nothing there to mock
You've tried Moz, Pnx & K-Mel and decided that K-Mel is the best for you.

It's the rampant fanatical "there can only be one, the rest must perish" attitude of eg asmpgmr that is a problem around here some times

Stefan you stupid troll, I never said there can be only one. I think it's good that there are lightweight Gecko browsers for each of the major OSes. I'm saying that writing a UI in an interpretive language with no regard for performance is stupid and trying to make a browser simply to justify a bad idea is even stupider.

All code should be optimized, I never said otherwise troll. I don't like Asa's implication that the K-Meleon, Galeon, and Chimera devs don't care about performance because they're not optimizing Gecko but instead have replaced the UI. Isn't it the Mozilla's devs job to do that ? Also it's hypocritical since they have the slowest UI of all browsers and it's because of something that the lightweight guys have addressed.

I tried Mozilla three times (pre 1.0, 1.1, and 1.2) and it was SLOW in all three cases so I tried K-Meleon and it's not. Since the DLLs are the same between the two then what do you think the difference is troll ??

Frequently updated software is generally very buggy software. It's better to take time and fix as much as possible between releases than to keep adding features and cranking stuff out, how about a testing cycle ?

I'm not a religious browser fanatic, I'm not even religious. If something is good then I'll say it's good, if something sucks then I'll say it sucks. In the case of Mozilla, Gecko is good and XUL sucks.

Also the guys doing Mozilla are generally NOT the same people who did Netscape Communicator, most of the Communicator people moved on long ago when Netscape Communications Corp. couldn't survive against M$ and was bought by AOL/TW. Mozilla and Netscape 4.x are completely different codebases.

I'm tired of discussing this with you troll, you're obviously a XUL lover so go off and play with your XUL-based browser and we'll use a lightweight browser.

You managed to call me stupid and a troll 4-5 times. You should beat yourself on the chest for such a great accomplishment

> I never said there can be only one... ...I think it's good that there are lightweight Gecko browsers for each of the major OSes.

I think so too. However I don't agree with your point that that nessesitates scrapping XUL. You apparently do, that is why you ARE saying "there can only be one" even if you didn't use those exact words.

> I don't like Asa's implication that the K-Meleon, Galeon, and Chimera devs don't care about performance because they're not optimizing Gecko but instead have replaced the UI.

What Asa is saying is that there are much larger gains possible by optimizing the engine then by (just) optimizing the UI, and that that has been an area that to a large degree has been ignored by the single OS devs.

Some of such optimizations changes could surely be ported back into Mozilla trunk and some possibly even ported to other OSes.
That would benefit all geckobased browsers.

> Isn't it the Mozilla's devs job to do that ?

1) Mozilla is cross OS. Obviously they can't optimize as agressivly as the single OS browsers could.
2) Mozilla is open source. Even you can start optimizing the code right away. Blaming others for unoptimized code is just whining. Make a difference yourself
Visit http://www.mozilla.org and start hacking...

> I tried Mozilla three times (pre 1.0, 1.1, and 1.2) and it was SLOW in all three cases so I tried K-Meleon and it's not. Since the DLLs are the same between the two then what do you think the difference is

I KNOW the difference is that Mozilla includes a huga ammount of other code that is NOT in K-Mel. I have said so before but obviously you are not able to comprehend this fact. Here is list of things to begin with
* An entire Mail&news app
* An entire Chat app
* An entire Adressbook app
* An entire WYSIWYG app
* Venkman Javascript Debugger
* DOM Inspector
etc...
That's an awfull lot of extra baggage included in Mozilla.
Thus (as I've also said before without you grasping it) if you want to do anything resembeling a fair comparison between XUL and a native UI Gecko browser then you need to look at Phoenix vs K-Mel, NOT Mozilla vs K-Mel.

> Frequently updated software is generally very buggy software. It's better to take time and fix as much as possible between releases than to keep adding features and cranking stuff out, how about a testing cycle ?

The best deployment method depends to a very large degree on the state of development as well as target audience. Eg Phoenix is still too young to have any real stable milestones. Mozilla is the main TESTING PLATFORM of Gecko (the "public" version of Mozilla is Netscape, currently at 7.01 = Moz 1.0.2. Moz trunk is at 1.4 now)
Just as Netscape, K-Mel is doing the smart thing and implementing the resonably stable builds from the TESTING PLATFORM Mozilla.
Mozilla is NOT an enduser product (even though many use it as such).

> I'm not a religious browser fanatic, I'm not even religious.

You ARE religious and fanatical about which browser you use and in your onesided narrowminded viewpoint where everything that is not exactly as you think it should be is automatically crap.
That has nothing to do with if you belive in God, Allah or something else.
The referance to religious that is fitting in your case is to the middeval darkages where people with a different opinion then the church were burned at the stakes, tortured or banished.

> In the case of Mozilla, Gecko is good and XUL sucks.

The problem is that your arguments you have presented for XUL sucking doesn't hold water.

> most of the Communicator people moved on long ago

That is not the information I have. You care to present any links to back that statement up, or are you just picking yet another statement from thin air?

> Mozilla and Netscape 4.x are completely different codebases.

Thank good for that...

What can I do with macros that I can't do with bookmarklets?

1. Add Menus to the **toolbar** (i.e., not add a new toolbar with menus, add a new menu to the main toolbar).

2. Execute external tasks / other internal macros on an event driven basis.

3. Interact with elements of the current document (e.g., $LinkURL), dynamically, while executing taks / other macros.

4. Interact with the user and respond conditionally to user input.

I've never seen a way to do in any other browser, what takes merely a few lines of macro code in K-M, namely highlight text in the document or text input windows, and click a right-click menu entry that will copy the word, look it up, and display the results in a bg layer:

define_text {
$dictionary = "http://dict.org/bin/Dict?Form=Dict2&Database=*&Query=";;
id(ID_EDIT_COPY);
$word = getclipboard();
$word == "" ? "" : pluginmsg(layers, "OpenURLBg", $dictionary . $word);
}

How do you do that with bookmarklets?

A: You don't.


Shelumi`El
Jordan

S.D.G

> 1. Add Menus to the **toolbar** (i.e., not add a new toolbar with menus, add a new menu to the main toolbar).

You can do the same in a XUL browser with JS. Remeber XUL = webpage after all...

> 2. Execute external tasks / other internal macros on an event driven basis

Well, javascript can be eventdriven. No advantage there.
External tasks could possibly be an advantage (JS is limited on that account for security reasons to prevent external webpages doing bad things).
I assume though that the external tasks is not just launch an app on the system?

> 3. Interact with elements of the current document (e.g., $LinkURL), dynamically, while executing taks / other macros.

Doesn't strike me as somthing you can't do with javascript.
Do you have an example?

> 4. Interact with the user and respond conditionally to user input.

And this is not possible with javascript? Since when?

> (5)

javascript:q=document.getSelection();if(!q)void(q=prompt('google:',''));
if(q)location.href='http://www.google.com/search?q='+escape(q)
+ couple that with the built in javascript to open a new tab and there you go...

If its possible to integrate scripts into the UI of Moz or Phoenix, without knowing XUL, I stand corrected.


Shelumi`El
Jordan

S.D.G

> without knowing XUL

Well XUL is JavaScript + CSS + "HTML" (ie XML)
If you know how to make a webpage (especially JS) you can do pretty much anything you want.
If you don't know how to make a webpage, then it's going to be difficoult if you want to make your own scripts.

But I assume most people will not write their own scripts, but instead just cut'n'paste those freely available made by others.

Here eg is one to turn of CSS on a page I've myself copied of a site that turns off all CSS on a page (greate for me to get a glips of how a page I'm making would look in a non CSS capable browser)

javascriptfunction(){function cE(a){var a2=[];for(var k=0;k<a.length;++k){a2.push(a[k]);}return a2;}function rS(dt){var u=cE(dt.getElementsByTagName("STYLE"));for(var k=0;k<u.length;++k){u[k].parentNode.removeChild(u[k]);}}function rSS(dt){var v=dt.styleSheets;for(var k=0;k<v.length;++k){v[k].disabled=true;}}function eD(dt){var t=dt.getElementsByTagName("*");for(var k=0;k<t.length;++k){t[k].removeAttribute("style");}rS(dt);rSS(dt);}function dI(dt,f){if(dt==null){return;}eD(dt,f);var fs=dt.getElementsByTagName("FRAME");for(var i=0;i<fs.length;++i){try {dI(fs.contentDocument,fs);}catch(e){}}}dI(document,null);})();

(I would assume this works also in K-Mel, but I havn't tried)

Stefan, just a question,
Since XUL is basically a web page, does it use the same Gecko engine *the one that renders web site* or it has its own renderer?

thanks.

StefanTroll, you are the fanatic. I'll use whatever browser I find to have the best functionality and performance. Mozilla is not it and it's not because of the other components like Mail/News, it is the XUL-based UI. Opening windows and pulling down menus has nothing to do with Mail or anything else but the UI. XUL is slow and a major performance hog and yes it should be thrown out to make Mozilla a better browser. If Mozilla used a native OS UI then I would almost certainly use it since it wouldn't have these performance problems. If someone makes a KHTML-based browser for win32 then I'll give it a try just out of curiosity so that's certainly not supporting you Highlanderish suggestion. In fact YOU are the one wanting to lop off the heads of everyone who isn't signing the flawed praises of XUL.
Refusing to accept the fact that a particular design is bad makes you the blind fanatic and coming to this forum constantly touting it makes you a stupid troll.

Another thing you don't realize (or refuse to) is that K-Meleon, Galeon, and Chimera very likely wouldn't exist if XUL didn't have major performance problems.

From the Galeon site (http://galeon.sourceforge.net/manifesto/)
"While Mozilla has an excellent rendering engine, its default XUL-based interface is considered to be overcrowded and bloated. Furthermore, on slower processors even trivial tasks such as pulling down a menu are less than responsive."

Well what do you have to say to that ? They're saying the same thing that I'm saying about XUL. Are you going to go trolling the Galeon forums now, that is if you're not already doing so. Might as well troll the Chimera forums too since they also don't use XUL. While you're at it you had better find some IE, Opera, Konqueror, and Safari forums to troll, they all use native OS UIs.

As for configurability, K-Meleon is far more configurable than any XUL nonsense, you can bind keys by editing a single file (accel.cfg), you can define ALL menus to your particular liking via menus.cfg, you can define the toolbar buttons via toolbars.cfg. Try doing any of that with XUL, a major effort is involved, you have to extract and change stuff in .jar files which will get overwritten when you upgrade. Also you can write macros to extend functionality. For example you can have search macro which can search different sites by specifying a 1- or 2-letter code before the search string, try doing that with a bookmarklet. You can also do things with a macro that would require a long messy javascript: line otherwise. The macro is cleaner and more maintainable.

Bottom line, most people here are here because they use win32 and want a standards-compliant browser which is fast and efficient so stop touting XUL-based browsers and go troll elsewhere. Most people here aren't interested.

> Since XUL is basically a web page, does it use the same Gecko engine *the one that renders web site* or it has its own renderer?

It's the one same engine.

The webpages you visit is sort of rendered in an "iframe" of the "browser UI webpage".

I see, That would explain the slowdowns in Mozilla because the UI is too bloated and it uses the same engine.

But since Pheonix is less bloated, The engine has more ressource to render the websites.

Having worked with K-Meleon and Phoenix's XUL interface, one area we beat them easily is in configuring the interface. Compare my tutorials on making K-Meleon a kiosk browser:

http://tln.lib.mi.us/~amutch/pro/kmeleon/

versus Phoenix:

http://tln.lib.mi.us/~amutch/pro/phoenix/kiosk.htm

Which would you rather do??

> In fact YOU are the one wanting to lop off the heads of everyone who isn't signing the flawed praises of XUL.

I have a fairly balanced view of XUL, being familear both with it's strenghts and it's flaws (mainly somewhat increased memoryusage & initial load times).

What I'm arguing against is your view that XUL greatly increases system requirements. That is simply not true. It does increase the requirements, but not nearly as much as you are trying to let on. Phoenix if noting else proves that you are outright wrong in this issue. It's considerally more lightweight then Mozilla and it still uses XUL.

From your infactual belife that XUL is such a resource hog you also draw the conclusions that XUL in any way or form is a bad thing that shouldn't exsist. Even if you would be right about it being such a resource hog, then that still wouldn't automatically invalidate the use of XUL in any way or form.
This is why you are a narrowminded browser fanatic. You are not able to see both good and bad sides of XUL, you are just blindly lashing out at a technology you do not understand.

Also I'm NOT calling YOU a troll, nor stupid, nor am I telling you that you should not post on this forum. All I'm doing is answering your ignorance with facts.

> Another thing you don't realize (or refuse to) is that K-Meleon, Galeon, and Chimera very likely wouldn't exist if XUL didn't have major performance problems.

The 3 native UI browser you mention exsists becuse Mozilla/Netscape as a whole has had and still have performance problems (and no XUL itself in not the problem here, but general bloat is).
For the 356th time, the Mozilla devs are aware of this problem, and IS doing something about it (GRE, Phoenix, Minutaur etc).

This development btw will help also enduser projects like eg K-Mel to add an optional lightweight e-mail client (with XUL or without it as the K-Mel devs see fit).

> "on slower processors even trivial tasks such as pulling down a menu are less than responsive." Well what do you have to say to that ?

On a slow CPU that is prefectly true. On such a slow CPU other JavaScript & CSS, imagerendering and anything else on the webpages they visit will also be slow.
The thing is that most people doen't have so slow systems nowdays that this is an issue.
On my 450 celeron all menus and opening new tabs and windows is basicly instantaneous in Phoenix. 450MHz today is pretty lowend.

> Are you going to go trolling the Galeon forums now,

I don't use Galleon, so I see no reason to visit it's forums. For me to make comparisons between Galeon and eg Phoenix on Linux would indeed be trolling, becuse I use neither of the two browsers (thus I'd be talking out of my *ss like you are in this forum)

> As for configurability, K-Meleon is far more configurable than any XUL nonsense

You are wrong. Obviosuly you don't have a clue about how XUL works. There is literally nothing you cannot change in a XUL browser.

> you can bind keys by editing a single file (accel.cfg),

You also just have to edit 1 file to change a key bind in a XUL browser.

> you can define ALL menus to your particular liking

same with XUL

> you can define the toolbar buttons

same with XUL

> a major effort is involved, you have to extract and change stuff in .jar files which will get overwritten when you upgrade.

That depends on what you do & how you do it.
If you just want to remove stuff you can do that with plain CSS {display:none} in your userChrome.css file.
If you want to add things you can do that by unpacking the zipfile (aka jar) and changing it there, or you can make a .xpi file (a zipfile with built in javascript functions to add/modify the XUL).

The .xpis can even be placed on a webpage allowing other users to simply click a link to install the change.

If I eg want to have a Chatclient added to Phoenix all I have to do is visit this page and click the installlink
http://www.hacksrus.com/~ginda/chatzilla/

Here is another link with a few example of such 1 click to install extensions
http://texturizer.net/phoenix/extensions.html

> For example you can have search macro which can search different sites by specifying a 1- or 2-letter code before the search string, try doing that with a bookmarklet.

Exactly what would be the difficoulty in implementing that with Javascript?
Looks pretty straight forward to me.

> The macro is cleaner and more maintainable.

The macros are calls for prescripted functions. If you don't like long very long JS snippets on a row you can always put the same functions in an external script and call for it. The built in macros are definitly convenient and a good addition to K-Mel, but their functionallity is far from unique.