Re: [Fwd: Epiphany, I love it!]

[Havoc Pennington <hp redhat com>]

On Tue, 2005-01-04 at 19:39 -0500, Luis Villa wrote:
> 
> [1] RH and Novell are both working hard on getting Firefox to fake
> integration (like file chooser and even native icons), so the gap here
> is going in the wrong direction. Ephy must be creative and aggressive in
> widening the gap again.

I wouldn't say we're working very hard on this; my conclusion was that
if we're going to place a high priority on browser development,
Epiphany's is clearly the right architecture. It is all but impossible
to make Firefox work properly in the hundreds of details because it's
optimized for Windows (and continues to be designed for Windows first
and adapted to Linux as afterthought). In addition to details there are
"big picture" integration goals and enabling the evolution of the Linux
desktop platform.

Adding all the Linux-specific stuff would disrupt the "same platform
across Windows and Linux" vision for XUL and defeat one of the goals of
Firefox, so while in theory this could be done with XUL given enough
people and time, I don't think it makes sense to do it with XUL. Why
break XUL? Keep a clear vision for what XUL is, a web platform. If Nat
and others are right, that's the future anyway.

Anyway, given that, the choice of Firefox is essentially a choice to go
with the flow on browser for now, rather than invest a lot of
development time and mental energy fighting over direction with the
Mozilla foundation. Piling tons of Linux-specific hacks into XUL (beyond
the trivial low-hanging fruit) to me is silly. If you want good Linux
support, then either write the chrome in GTK+, or design XUL to clone
GTK+ and have it look inconsistent on Windows (but consistent with
itself across platforms).

I find it notable that Firefox and Epiphany share virtually all of their
code percentage-wise, and we should encourage that to continue.

I might suggest that we try to show Firefox a way to use native chrome
and dialogs, while still supporting cross-platform extensions, cross-
platform standalone XUL windows, and XUL within the web page.

Here are some details of that approach:

 - keep XUL behavior consistent across Linux/Windows; don't pile on
hundreds of behavior differences and so forth to adapt to the platform.
In fact we might make XUL look deliberately *unique* so users think of 
it more like a web page or flash, rather than a normal desktop app, and 
expect distinct behavior.

 - ensure that Epiphany supports opening standalone windows built
entirely with XUL, to support XUL as app development platform

 - create a well-defined extensions API for modifying things like the
menus, and have "embedding areas" where Epiphany can have XUL additions
to its chrome (applets for browsers? - this may be useful for something
like gnome-panel even, think how Apple Dashboard works).

 - ensure that Epiphany supports XUL inside web pages (no special effort
here AFAIK)

To me this strengthens what Firefox is doing because it means a better
experience on each platform, *and* a more consistent (and long-term
stable/robust) cross-platform XUL API for people building web apps and
extensions. It also means that all of us could get behind Firefox 100%.

The reason it's tough to get behind Firefox now is that there's really
no reason to create hundreds of usability bugs and limit evolution on
Linux only to support obscure extensions that want to do arbitrary
poking in the widget tree of the chrome. And that's the only Firefox
feature that precludes native chrome. XUL apps don't involve the native
chrome. XUL inside web pages doesn't involve native chrome. Extensions
that are doing sane things with the chrome (such as adding menu/toolbar
items, or a custom gadget/applet) could be supported with native chrome,
and extensions that only deal with the web page itself or that open new
windows could work with native chrome.

The other reason the Firefox team is against native chrome is that they
were burned by Netscape 4. But the reality is that the open source
situation is not the same as the proprietary Netscape situation, because
we have a lot of volunteers who are willing to maintain the (relatively
small vs. the whole codebase) native frontend, it isn't a zero-sum game
where the native frontend is all extra work. There's also a judgment
call here that I think they've gotten wrong, which is placing technical
goals ahead of end user experience on Linux. (There's no major usability
downside on Windows, because the browser is written for Windows.) The
native frontend is *worth* extra work, in other words, and in fact Red
Hat offered to donate that work if Mozilla would accept it.

Having a native frontend doesn't even keep customers from running the
XUL frontend on Linux, if they are in the kind of situation where they
aren't using the Linux desktop as a whole (e.g. fixed-function kiosk)
and so consistency with Windows is more important than consistency
between all the apps someone is using during their day. But in that case
you want the XUL frontend to be just like Windows, not adapted to Linux
as it sort-of is today.

Sorry for the troll, but I think it's a useful discussion on some
level. ;-)

Havoc