ar1000 wrote:Windows is more popular to ââ¬â why don't we just use that. The challenge is to find the better web engine not the most popular, I think the better one is KHTML. It is streamlined and more standard compliant.
Philosophically, I think it’s a bad idea to challenge too many standards at once. As you point out, Windows is more popular – which means that we are already breaking a standard, as it were, by doing something different. That’s a tough enough hurdle all by itself. Any additional standard-breaking means that we’re just piling more hurdles on top of each other.
Consider productivity suites, for example: I love Gobe Productive dearly, and it will always, always, always be my first choice of productivity software. I dearly hope that Gobe gets going again, or the source code is released, or some other Haiku-like group of coding gods decides to reverse-engineer the thing. It’s just a beautiful program. I like it infinitely better than Microsoft Office, and vastly better than OpenOffice.
HOWEVER, it’s also completley alien to most people, who are stuck with Microsoft office. Some of them, inexplicably, even like it. Now imagine that you’re trying to convince one of them to use Haiku. Here’s your pitch: "Hey, check out this fabulous new operating system: it’ll feel kind of weird for a while, but once you get used to it, you’ll find that it does everything faster and easier and better than Windows does."
You’ll lose some people right away, and, well, those ones who are beyond help. But for the ones who remain, you’ve now got another pitch to make: "Oh, you’ll have to also learn this new productivity suite, which is vastly better but also totally different than your old productivity suite. And as for all your old documents… well, most of them should… kinda… import…" That’s a much bigger hurdle, and you’ll lose most of the rest of them at that point. And that is Haiku’s loss, not just Productive’s.
This is why, even if I don’t like OpenOffice very much, it is essential that it be ported over to Haiku. That way, your second pitch can be: "here’s this Office Suite which is 100% compatible with all of your old documents, and has nearly the same interface and workflow and everything!" That’s a much, much easier sales job. Of course Productive will still be around, and the ones who are smart can catch onto it later. Gotta fight your battles one at a time. I think in the above example, it’s quite obvious why.
Now, when it comes to a HTML layout engine, it’s a much more subtle thing, but this dynamic is still at work. I don’t know anything about how it is to work with KHTML vs. Gecko on the backend of a system, so I can’t address that issue. And I can say that, from the consumer’s point of view, as long as they produce the same output, it doesn’t really make that much of a difference. However, from the perspective of a web designer, I can say that KHTML makes me a little nervous, simply because I’ve never validated any of my pages against it. It isn’t enough of a factor in the market to worry about. So that’s one consideration. Particularly if we’re aiming for Haiku to be accepted in a business environment – and I think there’s no reason not to aim that high – it’s very important that the business be assured that it is seeing exactly what everybody else is seeing.
Another consideration is: how many developers are used to working with Gecko? How many are used to working with KHTML? If one has a much larger number of developers, then that is the one that Haiku should almost certainly use. That gives us a larger base of programmers to recruit from. We can say: "hey, why don’t you develop web applications for this cool new operating system? And look! You can use the same HTML layout engine that you always use! There’s hardly anything new to learn!" See how that’s a much easier argument to make?
Once Haiku has enough users and developers and overall momentum to start throwing some of it’s own weight around, it’ll be another matter. From the beginning, a program should request the particular HTML engine that it’ll be using. If it becomes obvious that a home-grown HTML layout engine would be superior, that can be added on later. You can go ahead and break compatibility, because new and updated applications will have to request the native engine directly, while old applications still use the old engine. That’s a little bit crufty, admittedly, but there’s no reason why it needs to be that way for long. The great thing about free and open-source operating systems and software is that there is never a disincentive to upgrade, so (unlike, say, Windows) there’s no need to keep kruft hanging around forever (except perhaps to support legacy hardware). After a Moore’s generation, the older engine can thus be removed from the default Haiku installation.
