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