Have you ever considered adapting code from Netscape Communicator 4.x for stuff like bookmarks, history, and other common browser features which K-Meleon currently doesn't have ?

Nope. I don't think there would be any way to integrate it into K-Meleon. Mozilla and Communicator don't share common code. Mozilla was rewritten from the ground up.

And the reason why they did that was because Netscape v4 was so poorly written in the first place. Talk about very poor if not non-existent web-standards handling.

I wasn't talking about using any of the Netscape 4.x rendering code, only interface stuff if it were possible. Don't forget that while Gecko may be good, having a slow bloated interpretive UI (XUL) was a really BAD idea.

Watcher,

Generally speaking, we don't use XUL. Most of the interface is done with native Windows code. Any interface we have has to be built from the ground up to interact with the existing Mozilla code.

Yes I know K-Meleon doesn't use XUL which is why it is so much faster than Mozilla. Mozilla/Netscape 7 is likely a lost cause simply because they wasted so much time on an ill-conceived idea and have no concern for users with older system who definitely notice the painful UI sluggishness.

A question - is all of the stuff in the chrome directories (one under K-Meleon and one under Profiles) needed ?

> A question - is all of the stuff in the chrome directories (one under K-Meleon and one under Profiles) needed ?

For whatever it's worth, i periodically comb through the embed.jar (zip) file and delete things i'm pretty sure that i *personally* don't need - which isn't to say that they aren't there for a reason - and when i get it stripped back enough, i guess i'll A/B the startup times with mine vs. the original, and see if there was any gain... just for fun.

> Mozilla/Netscape 7 is likely a lost cause simply because they wasted so much time on an ill-conceived idea and have no concern for users with older system who definitely notice the painful UI sluggishness.

But the more time passes... the faster the "low end in use" will be.
And the XUL idea btw in general is a greate idea since it's esentially an entire crossOS application platform.

BTW, Microsoft just intruduced their own version of XUL the other week...

Definitly something for the future.

No it is not a good idea, XUL is an absolutely stupid idea and if M$ is doing something similar then it is definitely a bad idea. The user interface is something you want to be fast with no noticeable performance lags. Having a UI written in an interpretive language is a major performance lag and attempts to cache the XUL pseudo code in a huge 2-3 megabyte file certainly isn't the answer. Interpretive languages are great for batch files, macros, or document markup languages but not for a UI. Also programs should be coded for computers in the here and now, not the future. The Mozilla people wasted a lot of time on XUL, time that could've been better spent working on the Gecko rendering engine and making Mozilla a better product which could at least attempt to compete with IE. Mozilla/Netscape 7 is without a doubt the slowest browser out there and it is because of XUL. A browser application platform ? HA ! Mozilla is slow, it can't check email without mailnews being open, it has NS 4.x parity issues, it has rendering issues, but you can play a hacky version of Pac-Man (PAGMAN) on it, who cares ? Most people just want a good standards-compliant browser. At least the K-Meleon and Galeon devs realize that XUL is crap and have dumped it.

> The user interface is something you want to be fast with no noticeable performance lags.

Well, I don't have any performance lags with XUL on a 450MHz Celeron so I guess your point is moot for the mayority of systems today

> Interpretive languages are great for batch files, macros, or document markup languages but not for a UI.

If you don't want to use it, then that's ok. But there is definitly a lot of people that find it highly useful when developing crossOS tools

> Also programs should be coded for computers in the here and now, not the future.

Here and now you can buy 2GHz+ computers... how much lag do you think XUL will have on those TODAY?

> The Mozilla people wasted a lot of time on XUL, time that could've been better spent working on the Gecko rendering engine and making Mozilla a better product

Well, mozilla is an open source project. Where is YOUR effort into improving gecko? (no, whing on a forum doesn't count)

> A browser application platform ? HA !

No, an application platform (leave out the browser part, that is just 1 thing you can do with it).

> Most people just want a good standards-compliant browser.

Guess why Mozilla is a development platform, not an enduser browser...
For enduser utils look into K-Mel, Phoenix, Chimera, Galeon, Skipstone...

I suggest you look on the newsgroup netscape.public.mozilla.performance, there have been many complaints regarding the noticeable sluggishness of XUL.

Intel is releasing a 3.06 Ghz P4 with hyperthreading support next week, so what ? There are still people who have older systems which do what they need and aren't going to replace them just to run somebody's bloat. I was surprised to find that some people still have Pentiums (no suffix). The attitude of you and the Mozilla crew is to heck with them which is not a good attitude to have.

I'm a BIOS engineer and I'm not interested in object-oriented programming, I do Assembly and C. Frankly I think OO is a big part of why most programs are bloated and so full of bugs today. Anyway what's you contribution besides being a self-appointed defender of bloat ?

Finally this is a K-Meleon forum, why come here to attempt to extol to virtues of XUL ? Most people who use K-Meleon, Galeon, or Chimera are doing so because XUL is SLOW and they want a browser without that crap. Also the whole point of these 3 projects is to have a browser with a native OS UI and NOT XUL. If XUL is so good as you say then why do you think the devs of these projects felt the need to make them in the first place and why do you think people are using them ?

> Intel is releasing a 3.06 Ghz P4 with hyperthreading support next week, so what ?

You stated that XUL was not usable at all today. I'm glad to see that you realize how silly that stament was with 3GHz CPUs just around the corner.

> There are still people who have older systems which do what they need and aren't going to replace them just to run somebody's bloat.

Well, that is exactly why software like K-Meleon exsists. No solution is the optimal for every user.

> The attitude of you and the Mozilla crew is to heck with them which is not a good attitude to have.

That attitude only exists in your own imagination. Mozilla provides their Gecko engine BOTH together with XUL and as a standalone embedding product. The reson for this is that people DO in fact realize that not all systems have the hardware resources to spare for XUL.

> I'm a BIOS engineer and I'm not interested in object-oriented programming, I do Assembly and C.

OK, but why do you assume that an crossOS easy to use scripting language can't be good for anyone else even if it doesn't suite you?
There are very many things in the world I have absolutely no use for. That doesn't mean I can't imagine it can be usfull for some else with different conditions/preferences.

> Anyway what's you contribution besides being a self-appointed defender of bloat ?

I'm not a defender of bloat, but a defender of options.
Just as noone is arguing that lowlevel coding for system/OS specific is the best option in regard to performance, you can't either argue that porting such a util to several OS is a very time (=money) consuming option.
It will take a whole team of experienced Assembly & C coders to make an app that works in Win/*nix/Mac while a XUL design will work on all platforms with next to 0 extra effort and additonally be very easy to port to even more OSs.

If you are sitting on an "alternative OS" with a 3GHz CPU and your option is to
A) Use a relativly bloated XUL program
Twiddle your thumbs (becuse the program is not availabe at all on your OS)

most people will choose option A even if it uses 2% of their system resources when a (non exsisting) lowlevel coded option would take only 0.5% system resources.

> Finally this is a K-Meleon forum, why come here to attempt to extol to virtues of XUL ?

Actually I should ask YOU the same thing:
If this is the K-Meleon forum, why are you even bringing up XUL and dump @!#$ all over it just becuase you havn't understood what it's about?

I didn't bring XUL into this discussion, I'm just countering blatantly ignorant statments about it that appeard in this thread.
XUL i's not a universal solution for everything, but it definitly has virtues in several areas (of which performance is NOT one, but cross OS funtionality and simplicity are).

> Most people who use K-Meleon, Galeon, or Chimera are doing so because XUL is SLOW and they want a browser without that crap.

Precisly, so what is your problem?
As I already said in a previous post, if you don't like XUL noone is forcing you or anyopne else to use it.

> If XUL is so good as you say then why do you think the devs of these projects felt the need to make them in the first place and why do you think people are using them ?

*plonk*
Becuse it uses more resources then a native UI and not all systems have those to spare.
It is called OPTIONS and leaving it up to the USER which version he prefers.
Surprizing that this would be such a novel concept for a programer.

Listen stupid, you mentioned XUL and I'll quote you, bad spelling intact:

---
But the more time passes... the faster the "low end in use" will be.

And the XUL idea btw in general is a greate idea since it's esentially an entire crossOS application platform.

BTW, Microsoft just intruduced their own version of XUL the other week...
---

Just because faster computers are coming out doesn't mean everyone is going to go out and immediately buy them unless you and the Mozilla team intend on starting a "everyone run our bloat" fund. Since I seriously doubt it, shut up about this.

Writing inefficient code is and not caring about it is inexcusable and also just plain lazy and stupid.

The UI stuff already existed in Netscape Communicator 4.x for four platforms (win32, Linux/Unix, Mac, OS/2), it could have been adapted even though the rendering engine needed replacing.

Also I seriously doubt you even understand what hyperthreading is, in fact I doubt you even understand what real programming is. I've been a programmer for almost 20 years and have worked on several platforms and I know exactly what I'm talking about. You certainly don't understand the conecpt of optimization and neither do the Mozilla hacks. You're using circular reasoning, you're not a good debater, some of what you write is fairly incoherent, AND you need to learn proper grammar and spelling. Now please shut up.

> Listen stupid, you mentioned XUL and I'll quote you, bad spelling intact:
> ... shut up about this.

Congratulations, you just proved that you are not a BIOS engineer but a 14 year old brat. The things that give you away are:

* Namecalling just becuse people don't agree with you
* Bringing in non relevant issues like spelling to the discussion
* Stating others are not alowed to post counter arguments in a topic you are discussing yourself.

These are all typical 14-year-oldish debating techniques which unfortunately doesn't work at grownups.
Try to stay on topic and discuss things in a more mature way please.

> Just because faster computers are coming out doesn't mean everyone is going to go out and immediately buy them

I recomend that you actually READ my posts before you reply to them.
I've stated several times that XUL requires more resources then a more native method for creating UIs. That means it's not ideal in all circumstances. That doesn't make it the technique itself bad in all other possible areas.

BEFORE you program something you start with looking at your target market and make your designdesions according to that.
If a sleak UI is required XUL is not a good option.
However if the vast mayority of users won't be limited by CPU (which is the case for a webbrowser TODAY, since the vast majority of systems today are 450MHz+ and XUL is plent fast on my 450 Celeron) then things like portability and simplicity (to lower development costs) is of highest consideration.

> Writing inefficient code is and not caring about it is inexcusable and also just plain lazy and stupid.

This btw is a further proof that you are not a BIOS engineer, as that requires a higher education which implies a less narrowness of outlook and a better understanding of the reality around you.

Optimizing code on a low level cost money and time. If the optimization has almost no effect in real world performance on the target audience you are just waisting money doing the system/OS specific optimization.

> Also I seriously doubt you even understand what hyperthreading is

I know what hyperthreading is, but now you are just thowing in new tech terms in the deabate that are not mentioned before and is also irrelevant. This again falls in the 14-year-oldish debating technique cathegory.

Again, try to stick on topic if you are looking for a meaning full discussion.

Now-now, stop calling each other names.

XUL is not utter crap. I have hard time imagining that bunch of talented proffessionals (mozilla devteam) have been busy producing crap for last 4 years. XUL has its uses. It is relatively easy way to go crossplatform. With XUL you just have to port the engine, not UI, which reduces the workload immensely. You don't really appreciate this unless you yourself have been trying to re-create existing UI from scratch with other tools. It's hard. And some things (UI look'n'feel consistency) may be downright impossible. Lets start with look - checkboxes in unix version of NS4 used to depend on what widget set you were currently using. This was not what Mozilla team wanted. They wanted their checkboxes, radiobuttons, menus, selects, progress-bars etc etc look the same on every platform. It is questionable whether this is/was good idea but for that particular idea XUL was the best solution.

So give mozilla devteam some credit here.

I use KM daily on 1,8GHz system. Yes, it is some milliseconds faster than Mozilla in responsiveness but that's not the reason I use it. It's flexibility is something that I like. And many people love Mozilla because it has predictable look and behaviour on multiple platforms. No use of fighting over preferences.

I love K-Meleon, but there is one feature I would require in any browser. That is at the very least, website email, ala Pegasus's excellent MAPI.DLL addon that worked with IE 3.03 and Netscape 4.xx.

N

Hey! Think about me - I'm sitting on a 600 MHz, 128 MB SD-RAM computer over here!!!!


I've never experienced any problems with it though....