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