Re: XUL
-
At 8:15 AM -0500 1/25/01, Ryan J. McDonough wrote:> Rick Roe <rick...>
> ....
>> However, the platform-specific parts of Mozilla aren't all that big,
>> especially if you're talking about just the gecko engine and not the
>> terrible XUL UI. Embedding that in a Cocoa app wouldn't be a huge
>> undertaking, though you'd probably be better off doing in ObjC. (Especially
>> if you're doing it on Public Beta.
>
> Using Gecko is the only thing I'm interested in, XUL sucks! ;) Some of the
> embedded Mozilla apps on Linux, such as Gaelon and Nautilus, are actually
> very cool. It would be very nice to be able to do the same on OS X. But OjbC
> is a bit beyond me at this point so I'll anxiously be awaiting the GM if it
> every gets sent to ADC members. It'll also be interesting to see how the
> Fizilla/Mach project is shaping up as well. That is the version of Mozilla
> that will use a Carbon UI and BSD/Mach leveraged renderer.
What's with all the hostility towards XUL? I'm just curious as to
why you guys dislike it so strongly, reply to me off-list if you
think it's too off-topic. Do you mean the existing skins, or the
language itself?
pax ex machina,
<glenn...> -
On Thursday, January 25, 2001, at 08:22 PM, Glenn Carnagey wrote:> What's with all the hostility towards XUL? I'm just curious as to
> why you guys dislike it so strongly, reply to me off-list if you
> think it's too off-topic. Do you mean the existing skins, or the
> language itself?
I think the main problem is that the whole mozilla project didn't get the right combination of feature implementation and bugfixing. Moz is still very buggy after two years of development, but they didn't refuse to implement unnecessary things (for daily usage) like XUL and IRC.
btw I think Apple did just the same by not implementing Java applet support.
andy
--
We fucked up. We fucked up big time.
-- Steve Jobs -
At 9:05 PM +0100 1/25/01, Andreas Monitzer wrote:> On Thursday, January 25, 2001, at 08:22 PM, Glenn Carnagey wrote:
>
>> What's with all the hostility towards XUL? I'm just curious as to
>> why you guys dislike it so strongly, reply to me off-list if you
>> think it's too off-topic. Do you mean the existing skins, or the
>> language itself?
>
> I think the main problem is that the whole mozilla project didn't
> get the right combination of feature implementation and bugfixing.
> Moz is still very buggy after two years of development, but they
> didn't refuse to implement unnecessary things (for daily usage) like
> XUL and IRC.
Well, I agree with that. To be fair, those features are only there
because that's what 3rd party developers wanted to work on, IRC was
totally off-campus (obviously, AOL wants AIM). Mozilla can't very
well tell them what to work on. ;-) Strategically, XUL was thought
necessary to kill the platform dependencies and ensure it remained
cross-platform, given their dwindling resources and increasing
dependence on 3rd party developers. You can't do it after the fact,
had to be done when they did the XPFE. Perhaps just as important
tactically was maintaining good will with the outside developers, and
that's what they wanted. Which makes sense, Linux and Windows users
are heavy into skins, and there are hardly any outside Mac developers
active in Mozilla. However, the in-house Mozilla team has
concentrated on bug-fixing since they reached dog food stage around
release 13, when they got standards-compliant, so, most of last
year. But I'm just wondering specifically what people have against
XUL, I guess the strong degree of dislike there kind of surprised me.
pax ex machina,
<glenn...> -
On Thu, Jan 25, 2001 at 03:16:08PM -0600, Glenn Carnagey wrote:> But I'm just wondering specifically what people have against
> XUL, I guess the strong degree of dislike there kind of surprised me.
My guess would be that people blame XUL for Netscape's transion from an application that was at least sort-of Mac-like, to one that 'feels' foreign.
--
Daniel J. Luke
+========================================================+
| *---------------- <dluke...> ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+ -
"Daniel J. Luke" wrote:> On Thu, Jan 25, 2001 at 03:16:08PM -0600, Glenn Carnagey wrote:
>> But I'm just wondering specifically what people have against
>> XUL, I guess the strong degree of dislike there kind of surprised me.
>
> My guess would be that people blame XUL for Netscape's transion from an application that was at least sort-of Mac-like, to one that 'feels' foreign.
Which is of course not a problem of XUL. You could easily have a XUL
engine which translates the XUL tree into Cocoa widgets and I'm indeed
interested if somebody has done that or likes to do that.
Having a textual UI description has significant advantages (only to
mention 'diffability').
I'm also interested what people really dislike about XUL as a concept,
which is from my view quite fine !
Helge -
> Which is of course not a problem of XUL. You could easily have a XULNow THAT sounds like a real good Idea. Too bad that wasn't how it was
> engine which translates the XUL tree into Cocoa widgets and I'm indeed
> interested if somebody has done that or likes to do that.
> Having a textual UI description has significant advantages (only to
> mention 'diffability').
>
executed.
Ryan-
+-----------------------------------------+
Ryan J. McDonough
http://www.randomthought.org
mailto:<ryan...>
+-----------------------------------------+ -
Seeing how I apparently started started all of this, I'll share my opinion
on XUL. I first want to say that I have all the love in the world for the
Mozilla project but the XUL interface just doesn't do it for me.> Strategically, XUL was thought
> necessary to kill the platform dependencies and ensure it remained
> cross-platform, given their dwindling resources and increasing
> dependence on 3rd party developers. You can't do it after the fact,
> had to be done when they did the XPFE. Perhaps just as important
> tactically was maintaining good will with the outside developers, and
> that's what they wanted.
I agree with the developing a solution to the problem but I don't know if
XUL was the solution. I recognize that Mozilla is still under development
but the XUL UI is slow. Furthermore the UI is inconsistent with that of the
host OS. This is most apparent on the Mac where several elements, such as
forms widgets, make Netscape and Mozilla feel like a cheap Windows port.
Building on that, even the widgets that look like native controls don't
always react like the control they intend to mimic. I think the problem is
not XUL, but the fact that XUL is using CSS/HTML/JavaScript/XML to create
the UI. If XUL could have used native UI elements I think it would be MUCH
more successful.> Which makes sense, Linux and Windows users
> are heavy into skins, and there are hardly any outside Mac developers
> active in Mozilla. However, the in-house Mozilla team has
> concentrated on bug-fixing since they reached dog food stage around
> release 13, when they got standards-compliant, so, most of last
> year. But I'm just wondering specifically what people have against
> XUL, I guess the strong degree of dislike there kind of surprised me.
Yes, skins are big on Linux and Windows. Unfortunately though I think that
was the driving force in making XUL into what it is today. I thought the
idea of a HTML/CSS UI was a good idea until I realized how far the Mozilla
group was going to go with it. The idea of skinning the whole app has gone
way to far and every aspect of the OS now needs to be recreated in XUL. For
example:
- Fading menus in Mac OS X and Win 2k
- Transparent menus and windows in OS X
- Scroll bar tabs in Mac OS 9 and X
- Appearance support in OS 9. Mozilla knows nothing about what colors the
user has selected for scrollbars, etc.
- Won't pick up widgets from the currently selected Theme under Gnome or KDE
I could go on, and on but I think I've made my point. Sure, you can use a
PNG alpha channel to recreate the transparency effect, etc., ect.. But take
a look at what you are trying to do, recreate the host OS in CSS/HTML. And
by doing that, you'll never get Mozilla to a point where it feels like the
it plays with the OS and I suspect this also why we haven't yet seen Mozilla
1.0 yet. I am however, very pleased with Gecko.
Ryan-
+-----------------------------------------+
Ryan J. McDonough
http://www.randomthought.org
mailto:<ryan...>
+-----------------------------------------+ -
"Ryan J. McDonough" wrote:> I think the problem is
> not XUL, but the fact that XUL is using CSS/HTML/JavaScript/XML to create
> the UI. If XUL could have used native UI elements I think it would be MUCH
> more successful.
No, the basic problem is, that Mozilla currently has only a single
widget set (actually that is also a feature, since it also reduces
porting overhead significantly).
BTW: AFAIK OPENSTEP|WO/NT had|has exactly the same problem. Inside of
the OpenStep windows the widgets were drawn using DPS instead of using
the native widget set, thereby resulting in different L&F.
CSS/HTML/JavaScript/XML in a non-Mozilla browser almost always use the
native widget set and therefore provide host-look&feel.
This is another advantage of XUL (and HTML), it's by concept *not* bound
to a widget set (even though Mozilla currently doesn't take advantage of
that at all).> Yes, skins are big on Linux and Windows. Unfortunately though I think that
> was the driving force in making XUL into what it is today. I thought the
> idea of a HTML/CSS UI was a good idea until I realized how far the Mozilla
> group was going to go with it. The idea of skinning the whole app has gone
> way to far and every aspect of the OS now needs to be recreated in XUL.
Again: using CSS for skinning is IMHO a quite good idea and would work
with any XUL widget backend (though, as with HTML, different backends
will support different properties).
Greetings
Helge -
At 5:15 PM +0100 1/26/01, Helge Hess wrote:> "Ryan J. McDonough" wrote:
>> I think the problem is
>> not XUL, but the fact that XUL is using CSS/HTML/JavaScript/XML to create
>> the UI. If XUL could have used native UI elements I think it would be MUCH
>> more successful.
>
> No, the basic problem is, that Mozilla currently has only a single
> widget set (actually that is also a feature, since it also reduces
> porting overhead significantly).
It comes with three (classic, modern, blue) and there are dozens you
can download, the most popular is probably an external set called
"Aphrodite." There are even a few sites dedicated to themes. But
none of them are going to handle your basic complaint, which is that
they aren't native. There is one which emulates Aqua that I've seen
screenshots of, but they're still working on it. Right now the
Mozilla Mac guys are concentrating on completing the switch from
Classic to Carbon
(http://x60.deja.com/getdoc.xp?AN=713495045&CONTEXT=980534454.1833500759
&hitnum=13),
their goal is February 1st.> BTW: AFAIK OPENSTEP|WO/NT had|has exactly the same problem. Inside of
> the OpenStep windows the widgets were drawn using DPS instead of using
> the native widget set, thereby resulting in different L&F.
>
> CSS/HTML/JavaScript/XML in a non-Mozilla browser almost always use the
> native widget set and therefore provide host-look&feel.
> This is another advantage of XUL (and HTML), it's by concept *not* bound
> to a widget set (even though Mozilla currently doesn't take advantage of
> that at all).
Say what? That's the whole point. ;-) I think you were right the
first time, what's bothering you is that it doesn't use the native
widget set for forms and certain UI elements. But it'll use any
widget set you'd care to make. This is also the trend of the W3C,
exposing form elements to CSS and other styling, that's how we got
here.>> Yes, skins are big on Linux and Windows. Unfortunately though I think that
>> was the driving force in making XUL into what it is today. I thought the
>> idea of a HTML/CSS UI was a good idea until I realized how far the Mozilla
>> group was going to go with it. The idea of skinning the whole app has gone
>> way to far and every aspect of the OS now needs to be recreated in XUL.
>
> Again: using CSS for skinning is IMHO a quite good idea and would work
> with any XUL widget backend (though, as with HTML, different backends
> will support different properties).
Yeah, but your point is taken that what a given OS does with its
widget set, and Mozilla does on every OS it supports, are not going
to be the same (e.g., menu animation, fading, transparency and so
forth). That may work out to be insoluble for the UI purist, but
there are bugs filed in Bugzilla to make it more Appearance-savvy on
Mac, and there are a few guys working on it. But, like I said,
there are hardly any outside Mac developers working on anything,
that's the main problem. Anything that is a pure Mac concern is
likely to take longer than general concerns. Shame, really, but
that's the reality.
pax ex machina,
<glenn...> -
Glenn Carnagey wrote:>> No, the basic problem is, that Mozilla currently has only a single
>> widget set (actually that is also a feature, since it also reduces
>> porting overhead significantly).
>
> It comes with three (classic, modern, blue) and there are dozens you
> can download, the most popular is probably an external set called
> "Aphrodite."
One widgetset, three default themes which operate on the same widgets
(and only change their appearance). Theme!=widgetset, don't mix them up.
In an ideal XUL configuration you would have a XUL backend which is done
using the native widgetset and a basically empty CSS (so that default
colors, icons, ... are retained).
Since writing a XUL backend is much more difficult than writing a CSS
file, it's much easier for Mozilla to fake the look of different widget
sets than to provide 'real' platform support.
Anyway, I guess the topic is already overdiscussed ;-)
Greetings
Helge
