<Marshall> |
To what extent will xbl be
implemented by the final? What will it allow us to do? |
<hyatt> |
XBL is brand new, so it's difficult to answer
the question. |
|
I believe that the events portion of XBL bindings
will need to be implemented by 5.0 |
|
But the content and interface portions of bindings
will not. |
<hyatt> |
It will allow you to do extend
an XML element in three ways. |
|
(1) You'll be able to define
the "internal content" of an element, e.g., if you wanted to choose
how to implement a composite color picker or scrollbar. |
|
(2) You'll be able to add
new methods and properties to an element. |
|
(3) You'll be able to define
event handlers on the element. |
<chrisn> |
ok, on to simeon |
<simeon> |
what needs to be finished
before skin switching, via the prefs panel, is implemented? ie, what
should I be looking for in bonsai? ;) |
<hyatt> |
(1) The master RDF files that contain the listings
of all packages, skins, and locales need to be added. |
|
(2) Installation APIS need to be added so that
those files can be modified by the installer. |
|
(3) The installer needs to be written. |
|
(4) The UI in the XUL has to use the chrome
registry APIs to actually enumerate the installed themes and components,
etc. |
|
(It's just a mockup right now.) |
|
(5) Skin switching is still buggy and needs
to be fixed. |
|
(6) We need JAR support. |
|
(7) Even once skin switching is in place, the
XUL itself will not skin easily, since it is in violation of many of
the skinnability guidelines. |
<chrisn> |
so, just a few things! :-)
simeon, followup? |
<simeon> |
has there been resolution on that sticky issue
of modifying the current xul to allow for skins? |
<hyatt> |
Simeon, I just gave up on
that. |
|
:) |
<chrisn> |
ok, I've got the next question... |
|
could you fill us in on what kind of customization
ability you're hoping skin developers will have by first release? |
|
There have been a lot of ideas getting thrown
about in the .ui newsgroup, and from what little I know it seems like
few of them would fit into the current skin-switching scheme (altered
XUL, etc). |
|
I mean, the ideas require altered XUL.... |
<hyatt> |
Well, people can write XPI
files that will overwrite the XUL, but those technically won't be skins. |
|
So this will be possible. |
|
Skins, however, involve only
CSS (and eventually XBL). |
|
So you won't be able to modify
the XUL for a given package without making a new package and overlaying
that into the original package. |
|
And again, that isn't a skin.
That's more content. |
|
So, in terms of skins only,
no you can't change the XUL. |
|
And as far as the prefs panel
UI, no you can't switch to a skin that would change the XUL for Navigator
in any way. |
<chrisn> |
you said that people could write XPI files
that will overwrite the XUL - how would the installer handle these files?
are they a security risk? |
|
or would the user have to manually install them? |
<JeffC> |
Uh oh. :> |
<dveditz> |
yes, they are. you can ask me about XPI ("zippy")
install files |
<hyatt> |
Let dveditz answer that one. |
<chrisn> |
ok |
<dveditz> |
um |
<Kovu> |
good answer ;) |
<hyatt> |
Heh. |
<dveditz> |
XPInstall lets you put files on disk. That,
basically means you can do anything, which is a huge security risk |
<hyatt> |
It's really a generic XPInstall,
so it depends on what we do for XPInstall security. |
<dveditz> |
but it could be used to overwrite XUL to get
the "skin" you want if the user is happy with the risk |
<hyatt> |
I would discourage this,
although we technically can't disallow it. |
|
IMO alterations to XUL mean
you're making a new kind of UI package. |
|
e.g., IE isn't the same as
NeoPlanet, and that isn't the same as navigator. |
<dveditz> |
Hyatt and I are hoping to create an install
subset for skins that would not have the security problems |
<hyatt> |
They all have a similar UI
with similar controls, but they're different packages. |
|
I think you'll see (rather
than overwrites) a proliferation of different browser packages. |
<chrisn> |
ok, next questioner is lemming |
<lemming> |
I think most of this was
just answered, but here goes. I have been working on an Internet Explorer
skin recently (see http://www.lemnet.com/ieskin/index.html ) but to
work properly it requires the XUL to be changed (including locked-down
files if that is relevant). You said earlier this wouldn't be possible,
but then you said something about XPI files. What can these do (skin
wise) and where can I get more info? (BTW I am thelem, I crashed |
<hyatt> |
You have two options, both of which involve
making XPI files. |
|
(1) You overwrite Navigator (the option I dislike) |
|
(2) You make a new package and put your files
there. |
|
I defer to dveditz as far as info on XPI files
themselves |
<chrisn> |
lemming: followup? |
<dveditz> |
I have no posted docs for XPInstall. I suggest
starting a thread on mozilla.general and I'll answer there |
<lemming> |
Thanks dvedits. What are
the chances on the XUL rules changing and my effort being wasted? |
<hyatt> |
What do you mean by XUL rules? |
<lemming> |
The oncommand calls and dtd
names |
<hyatt> |
Unlikely at this point. |
|
But I can't make any guarantees. |
|
:) |
<lemming> |
Great. Thanks. :-) |
<chrisn> |
ok, next questioner is zero |
<zero> |
umm i know its a mockup and
all but will any skins other than default ship with mozilla? |
|
that 70's chrome still makes
me laugh :) |
<hyatt> |
With Mozilla, absolutely. |
|
With Netscape, hopefully. |
<chrisn> |
hehehe |
<Kovu> |
but it matches netcenter... |
<zero> |
hyatt: will something like
Omniweb ever be able to be emulated? |
|
or skinned |
<hyatt> |
Sorry, I'm not familiar with Omniweb. |
|
So I don't know. :) |
<pinkerton> |
xp_mac is set in DefinesMac.h |
|
sorry |
<chrisn> |
ok, then we're on to kerz next... |
<kerz> |
ok |
|
Can we actually expect skin
switching at release? |
<hyatt> |
At release yes. |
<kerz> |
Which one? |
<dveditz> |
:-) |
<chrisn> |
heh |
<hyatt> |
Ok, I do not believe skin will make it into
beta 1 |
|
Unless beta 1 slips. |
|
If by release you mean a shipping 5.0, then
yes, i think they'll make it into that. |
<kerz> |
OK |
<chrisn> |
kerz: followup? |
<kerz> |
Followup: Is there a hyatt
skin? Something cool you are working on? |
<hyatt> |
You've seen my graphical design skills. |
|
No. |
|
:) |
<chrisn> |
ok, dveditz has the next
question... |
<kerz> |
I liked kidskin! |
<dveditz> |
You mentioned what XBL could
do, and that you considered it part of "skins". Isn't there some risk
there? |
|
(i.e. skins were supposed
to be "safe") |
<hyatt> |
dveditz, yes. |
<dveditz> |
m, |
<hyatt> |
That's why XBL is still in a draft and needs
to be thought through some more. |
|
For example, anonymous content is safe since
it doesn't have access to XpConnect. |
|
But explicit content would. That would be decidedly
unsafe. |
|
The event handlers arguably need to have access
to XPConnect, so there's another problem there. |
|
One possibility is to split out the content
and behavior into two different files. |
|
Still doesn't really wash though. |
|
In the end, CSS is heading in an unsafe direction. |
<chrisn> |
dveditz: followup? |
<dveditz> |
followup: what's explicit vs anonymous content |
<hyatt> |
Anonymous content is content
that points back to its parent, but that the parent doesn't know about. |
|
It's insulated and hidden
from the parent DOM document. |
|
But explicit content is actually
put right into the DOM document. |
|
So it becomes part of the
chrome in effect. |
|
Most XUL widgets have anonymous
content. |
|
e.g., menu items build themselves
out of four titledbuttons |
|
scrollbars consist of two
buttons and a slider. |
|
But you can't see those child
objects. They're hidden. |
<dveditz> |
thx |
<hyatt> |
Right now that's hard-coded
in the frame code. |
<chrisn> |
I have one quick followup: you mean CSS by
itself might become unsafe? or CSS and XBL together? |
<hyatt> |
But XBL hopes to make that
configurable. |
|
CSS by itself is heading
in an unsafe direction. |
|
i.e., a proposal is afoot
to let you say something like: |
|
treecell { |
|
onclick: blah; |
|
} |
<chrisn> |
and perform Javascript functions? |
<hyatt> |
And you'll be able to use
a @script instruction in the CSS file to include JS in the CSS file. |
<chrisn> |
ack! |
<hyatt> |
This is a draft though, so
this may not fly in the end. |
* FrodoB |
is impressed, though. :) |
* simeon |
remembers 'action sheets' |
<chrisn> |
ok, simeon's the next questioner |
<simeon> |
there has been a lot of discussion
recently on the newsgroups about native widgets. But enough about that.
How are your hands feeling? |
<hyatt> |
they hurt a little, but overall they're better. |
|
:) |
<JeffC> |
That's good. :> |
<chrisn> |
simeon: followup? |
<simeon> |
no followup |
<chrisn> |
ok, my question's next: |
|
it relates back to my original question.... |
|
a number of people in the .ui newsgroup have
had ideas regarding the default Mozilla ui. Some are interesting, others
sorta lame... |
|
how much help in shaping the default Mozilla
ui do you think outside forces should have? |
<hyatt> |
This is a difficult question.
:) |
<JeffC> |
:> |
<chrisn> |
outside meaning outside of
the core development team |
|
(third party people, etc) |
<hyatt> |
Obviously we need help, don't we? |
|
:) |
<JeffC> |
brb |
<hyatt> |
Anyway, I believe that people outside should
have just as much say as people inside. |
<Pavlov> |
I am currently in the process
of working on a machine to clone hyatt |
<hyatt> |
However, I also believe that Netscape has the
right to dictate the entire UI of the Navigator browser. |
|
So here's where you run into a fundamental
problem. |
|
If you fork the UI, IMO everybody loses. |
|
Because the Ui everybody is going to see will
be the Navigator UI. |
|
So it's in everyone's best interests to work
together so that forking doesn't occur. |
<desgn4use> |
agree! |
<hyatt> |
However, if Netscape ends up being unreasonable
enough not to entertain constructive suggestions from the Mozilla community,
then I think Mozilla will have no option but to fork. |
|
So far, things have been pretty reasonable. |
|
The main point of contention has really been
limited to three inches of space in one window (the Navigator window). |
<Kovu> |
you're saying moz should
use the Navigator UI? |
* FrodoB |
certainly wouldn't mind seeing Ben_Goodger's
and Jeff Campbell/Pete Collins's UIs included in CVS as options, at
the least. :) |
<Darchmare> |
Thanks, Frodo. :> |
<hyatt> |
I'm saying that moz could use its own UI, but
you wouldn't get that UI QA'ed by Netscape engineers. |
|
If you fork, all of us at Netscape are going
to be required to spend all our time on the Navigator UI. |
|
Fixing XUL bugs, fixing CSS bugs, polishing,
tweaking, testing. |
|
The Mozilla UI would end up being neglected
by Netscape, and at this early stage, I think that would be a very bad
thing. |
<chrisn> |
followup: do you have any
ideas on how Netscape and the Mozilla community can better work together? |
<hyatt> |
Yeah. |
|
(1) people have to realize that, whether they
like it or not, there will be one set of XUL that defines Navigator. |
|
We should work together to make that XUL the
best it can be. |
|
A proliferation of many different XUL files,
although cool, is too overwhelming at this point. |
|
We need to be able to focus on one set of XUL,
putting it into usability testing, polishing it so that it can be skinned,
etc. etc. |
|
So I would suggest that we focus on one UI. |
|
Rather than many. |
|
I had a (2), but I'm going senile. |
|
So I guess I'm done. :) |
<chrisn> |
ok, I think dveditz had another
question... |
<dveditz> |
Right now when you launch mozilla the navigator.xul
magically shows up. If someone defines an /alternate/ navigator and
installs it is there any way for them to get their nav to occupy that
magic position |
|
(if not that will encourage overwriting navigator.xul) |
<hyatt> |
Not right now. |
|
We should do that. |
|
That could be a pref. |
* kerz |
liked the way mozclassic did skins... |
<hyatt> |
Let's do it. |
<dveditz> |
no followup |
<chrisn> |
ok, JeffC is next |
<JeffC> |
What 'official' plans are there for handling
the differences between platforms, in appearance and in functionality
subtlties? How will native widgets be handled (or not)? Is there a certain
way, in your opinion, that Mozilla should be heading? |
<hyatt> |
Native widgets are out. |
|
As far as XUL is ocncerned. |
|
Someone could embed Gecko
and make their own FE if they want native widgets. |
|
But we have no plans to support
them in XUL any time soon. |
<chrisn> |
JeffC: followup? |
<hyatt> |
As for other platform differences,
skins and XBL. |
<chrisn> |
oops |
<hyatt> |
We also are varying the XUL
slightly from platform to platform already. |
<JeffC> |
To what degree will Mozilla 'mimic' native
widgets in order to provide a seamless appearance? Any strategies? |
|
ie. menubars, scrollers, etc. |
<hyatt> |
JeffC, CSS2 supports native
system colors and fonts. |
|
(System fonts aren't implemented
yet though.) |
|
This can get you pretty close
appearance wise. |
<JeffC> |
ie. diagonal rules for selecting submenus,
etc. |
|
Basically, more the feel than look. |
<hyatt> |
The XP menus are just broken
regarding diagonal movement anyway. |
|
:) |
|
I need to fix that. |
|
XBL would help out feel a
bit. |
|
In several ways. |
|
e.g., you could make sure
a scrollbar had up/down arrow pairs above and below a scrollbar on the
BEOS. |
|
or you could define platform-specific
key bindings. |
<JeffC> |
Would it detect platform-specific prefs? |
<pinkerton> |
some mac geeks might slip
in tweaks to the gfx scrollbars to make them like the mac ones near
the end. |
<JeffC> |
(ie. in BeOS, you can turn that off) |
<hyatt> |
JeffC, if someone wants to
do that work, that would be nice. |
<JeffC> |
Okay, thanks. :> |
<hyatt> |
But we don't have the resources
to really devote the attention to it. |
* FrodoB |
cheers for pink, and wants to make note that
he asked this a few months back. :) |
<hyatt> |
I'm certainly for it though. |
<pinkerton> |
i said "might" |
<hyatt> |
Heck, we could hack the C++ code for scrollbars
with a few #ifdefs |
<hyatt> |
And get the right looks. |
<chrisn> |
ok, Ben_Goodger is next. |
|
Ben? |
<Ben_Goodger> |
a question in two (small) parts, a) do you
agree that the best XUL structure is the simplest (not introducing frames
that ease the creation of one skin but impede creation of others) and
b) do you think cloning native widget *appearances* in the current timeframe
is possible? |
<hyatt> |
(a) Absolutely. The current
Mozilla skin contains hacks to achieve a certain visual look. |
|
We should hopefully be able
to remove those however. |
|
We already have one good
fix. |
|
The rounded corners have
been implemented. |
|
So that we can remove the
GIFs. |
<Ben_Goodger> |
on specific corners (rather than all..?) |
<hyatt> |
Yes, on specific corners. |
|
This is the only real big
problem with the XUL right now. |
|
So fixing that will help
a lot. |
|
And german and I are working
on making the toolbars re-orderable |
<Ben_Goodger> |
cool. |
<hyatt> |
While still maintaining the
rounded corners. |
<Tekhir> |
cool |
<hyatt> |
(b) I would love to see a
native skin. |
|
I think that we can use native
system colors. |
|
I'm not sure about system
fonts though. |
<chrisn> |
Ben_Goodger: followup? |
<Ben_Goodger> |
right, but do you think it
is technically possible to achieve a perfect clone, given our technology,
without introducing new frames, or using XBL? |
<hyatt> |
A perfect clone? No. |
<Ben_Goodger> |
thanks. |
<hyatt> |
A reasonable enough fascimile that should satisfy
all but the most die-hard zealots? |
|
Win32: yes, Linux: yes, Mac: never. |
<chrisn> |
hehehe! |
<Ben_Goodger> |
hehe. German's native widgets are good. |
<Kovu> |
poor macians |
<Ben_Goodger> |
German's widgets sorry. |
<chrisn> |
ok, simeon's got the next
question... |
<hyatt> |
German is sitting over my shoulder if you have
any question for him as well. |
<simeon> |
there are some prefs that
effect the look, such as link color, bg color, etc. will these be edittable
like 4? if so, would that allow a skin editor to be integrated with
the app? |
<hyatt> |
Thats more a question for Gecko. |
|
Those prefs apply to HTML and not to XUL. |
|
Skins will be the preferred way of changing
the chrome look. |
<simeon> |
ok, i'll take it to the newsgroups...thanks. |
<chrisn> |
ok, next questioner's kerz |
<kerz> |
hang on |
|
I know you are only one man,
but, can we expect ideas being considered and possiblely added into
the default skin? It seems that Netscape has a pretty good idea what
it wants to use. |
<hyatt> |
Sure. |
|
A lot of ideas have already been incorporated. |
|
Ben's menus for example I think we want to
incorporate into the menu bar. |
|
Sans rounded corners, since the menus can't
handle that. |
<Ben_Goodger> |
hehe |
<chrisn> |
what's novel about ben's menus? I forget... |
<hyatt> |
Ben has done stuff on wallet,
on profile manager, etc. |
|
People have contributed to
editor's UI. |
|
Pete Collins among others |
|
When it comes down to it,
there does have to be a notion of module ownership. |
|
And that means someone does
approve or deny changes. |
|
We have to have that kind
of organization, or there would be chaos. |
|
You can't design a UI by
committee. :) |
<kerz> |
ok |
<chrisn> |
kerz: followup? |
<kerz> |
so i guess my follow up is, who is on the committee? |
<hyatt> |
I believe anyone can contribute
ideas. |
|
But they do ultimately have
to be approved or denied by someone. |
|
That's the same scheme of
ownership we have for code, and i think it carries over to UI as well. |
<chrisn> |
ok, next questioner's gerbil |
<gerbil> |
This is a completely selfish,
impatient, and unenlightening question, but I just wanna know what significant
things can we expect soon (as in 2 weeks or so) |
<hyatt> |
I can tell you what I'm working on. |
|
Improving tree widget performance for mail/news. |
|
And maybe doing the beginnings of XBL. |
<chrisn> |
YAAAAAAAAAAAAAAY! |
<Kovu> |
:) |
<chrisn> |
tree widgets! |
* FrodoB |
reiterates chrisn's outburst, but referring
to XBL. :) |
* gerbil |
is willing to cheer for almost
anything right now |
<chrisn> |
gerbil: followup? |
<gerbil> |
nope :) |
<chrisn> |
ok, that brings us to the final questioner:
me |
|
and this question relates to something hyatt
said earlier in response to a dveditz question... |
|
dveditz asked about someone writing a new navigator.xul,
and wanting it to be made default without having to overwrite the current
navigator.xul... |
|
and you mentioned creating a pref for it |
|
so, my question is: |
|
could this create a situation where people
could create skins for different XUL bases? |
|
so, wouldn't it be better to integrate the
XUL bases and the skins into the same pref? |
|
because some skins wouldn't work with some
XUL structures.... |
<hyatt> |
No. |
|
The pref would point to a
package, e.g., "messenger". |
|
Then when you ran, messenger.xul
would be loaded. |
|
Someone who writes a skin
for messenger would still install themselves as a messenger skin. |
|
So I don't see a need for
anything other than a pref dictating which package is the "primary"
package. |
|
e.g., navigator vs. neoplanet.
vs. mailnews, etc. |
<chrisn> |
oh - I thought dveditz was talking about someone
who wanted to create an alternate navigator skin... |
|
oops |
|
an alternate navigator XUL file |
<hyatt> |
Right, you can't allow that. |
|
because then skins and locales
start breaking since they don;t work with the new XUL |
|
That's why we can't allow
you to start altering the XUL out from under the user. |
<dveditz> |
navigator-replacement I meant. a new package |
<hyatt> |
Minor changes should be done
with add-in packages using overlays. |
<chrisn> |
ok, I guess I'm confused then. What's the difference
between what I had understood and what dveditz was saying? |
<hyatt> |
But major changes involve
making a new package. |
<chrisn> |
what's a "package" in those terms, then? |
<hyatt> |
chrome://package/provider/package.xul |
|
So sample packages include
navigator, aim, messenger, composer, etc. |
<chrisn> |
oh, ok - the whole enchilada... |
|
ok, and hopefully you haven't lost me - how
would skin switching be handled in the new package? I assume it'd require
different skins, no? Or am I still missing something? |
<hyatt> |
So someone would make a whole
new package, e.g., the winamp package. |
<dveditz> |
My question was about someone making drastic
changes to navigator.xul -- we want them to create a new mybrowser package.
But they are going to want their package to come up when they launch
mozilla |
<hyatt> |
And we'd have a pref that
could point to winamp, so that winamp is what launched when you double-clicked
mozilla. |
|
We could even do what we
did in 4.x, and just have startup prefs for all packages. |
<dveditz> |
If you had installed a navigator skin it won't
be applicable to "mybrowser" |
<hyatt> |
So you could have multiple
things launch at once. |
|
dveditz, right. |
<chrisn> |
oh, I see |
|
so, you're saying that there'd essentially
be a whole different browser... |
<hyatt> |
Yes. |
<chrisn> |
ah - cool |
<Ben_Goodger> |
dveditz: so people would
create skins for "mybrowser" rather than mozilla |
<hyatt> |
Yes. |
<Ben_Goodger> |
makes sense |
<chrisn> |
hyatt: ok, that's something I'll have to think
about, then. |
|
so, the package list in prefs would be dynamically
created, based on the installed packages, correct? |
<hyatt> |
could be. |
<chrisn> |
ok |
|
very interesting. I like that idea |
<hyatt> |
We could even put the info
in the chrome registry rather than prefs |
|
If we wanted to. |
<chrisn> |
ah |
<Kovu> |
ah yes glasshoppa |
<chrisn> |
ok, well that was the final question... |
<Ben_Goodger> |
I think that's best actually...
allows people to create their own unique browsers, and you wouldnt risk
mozilla trying to second-guess what was going on when skinning it. |
<chrisn> |
I'd like to thank Dave Hyatt for stopping by |