Dave Hyatt is working on a new tree widget for use in large trees (mail, bookmarks, etc) which is a leaf frame with no content model backing. A client creates a component that implements an interface that the widget talks to in order to paint its contents. The component is free to source its data from any medium it chooses. The tree only has to deal with matter onscreen, there is no lengthy content construction phase or RDF graph generation (unless your data store is RDF), so it is much faster. Demonstrations have shown it capable of scaling to over 5,000,000 items and appearing and scrolling quickly. Hopefully this will provide a means to solve the speed problems suffered by the mail client, and to an extent the bookmarks window. To see it in action, pull MailNews_Performance_20010208_BRANCH on Linux or Windows.
That's a XHTML webpage with XUL bound to a DIV using XBL. (use a nightly or N6 RTM candidate)
(You can use XBL to create your own composite widgets from primitives supplied by HTML and XUL, or other XBL widgets, as well as implementing node APIs and event handlers, see http://www.mozilla.org/projects/xbl/xbl.html.. e.g. you could create a nav bar that is shared across several pages without using frames or a server side include. this nav bar can expose methods and properties that you define that other parts of the page can interact with)
e.g.
var foopy = document.getElementById("foopy");
foopy.someMethod();
in the example above, produces an alert dialog 'someMethod called!'
(see sampleBindings.xml in the same directory as the above for the XBL widget implementation)
actually the functionality is there, via nsIFile and cousins. However access to XPConnect is blocked from non chrome* scripts. Try loading an XPConnect script in the content area from a non-chrome URL and you'll find your code fails.
*chrome = part of an installed chrome package in the chrome directory, e.g. Navigator.
I'm from Royal Oak, a suburb 20 minutes drive south of Downtown Auckland where this happened. I've been in Mountain View CA for the past few months but was in AK when this happened back at the start of '98. It wasn't "months", the bad blackout only lasted a week or so until people realised that yes, Mercury Energy had f*cked them that hard and that they should ease off on the electricity. The remaining time was rolling outages at scheduled times to maintain the limited supply while the overhead emergency corridor was built up the Southern Motorway and the main cables were repaired. It did cause the school year for the U of A to be delayed by a week though, and there were a couple of short incidents as things got back online, but only those living in a small zone in the CBD were hit hard. The large businesses that had their home in this area found other places to work out of and pretty much everything came back to life when the problems ended. Not an event you'd aspire your city to go through, but not something the people affected by it (in Auckland at any rate) weren't able to figure out and deal with for that period.
Note also that the Alphanumerica apps aren't themes or skins for Mozilla, they're completely different applications.
Once you modify XUL or JavaScript, you are no longer making a skin and are making a new app.
There will be two trust models for installed matter in Mozilla - 'trusted' (skin - meaning CSS and images) which can be downloaded and installed in a couple of clicks from any website, aided by a friendly dialog, e.g.
Install the theme 'Foo theme'? [x] Switch to this theme now [ OK ] [ Cancel ]
Whereas anything else will have to be installed via XPInstall or similar, basically putting up the scary dialogs associated with Java auth. or ActiveX controls. Why? Because chrome level JavaScript can access XPConnect, which means it can access your filesystem, your prefs, your mail, etc;) Skins, having no access to these things, are 'safe' (it is possible of course that someone could make a DoS skin with black-on-black, but we plan to have a timed evaluation period for skin application such that if something goes badly wrong, you will be yanked back into the previous state.)
Yes, you're right, the current theme wastes space terribly. This is something I hope to sort out in a 4.x-style skin. Expect to see one hot on the heels of skinnability and skin-switching.
I would personally like to reintegrate the task switcher into the status bar like 4.x and ditch the Taskbar.
This is something we would dearly like to support - customizable menus, toolbars etc. Mozilla Classic on Windows had draggable toolbar buttons, you could drag navigation buttons and bookmarks on personal toolbars into different toolbars and locations. In Mozilla Classic, this was all done using RDF. Theoretically this is possible today in Seamonkey using RDF, however you would want Balls of Steel to attempt it, and the solution would probably be annoyingly complex. Whenever he gets time (probably not for version 1.0) David Hyatt (hyatt@netscape.com) mentioned that he could implement dynamic XUL overlays (overlays that persist state, such as item order etc) which would make this sort of thing much easier to set up.
Skinnability is one of the high priorities for Netscape 6 PR2, and is my highest priority work assignment at present.
Here's what we are doing:
1) making the FE skinnable by scrubbing the XUL code that describes it 2) creating a skin switching UI for the preferences window 3) creating skin download and installation mechanisms 4) creating new skins!
We need to get 1 nailed before we can do 4, although 2 and 3 are currently also in progress. Stay tuned...
The current skin is far from being 'too simple' from a code point of view (regardless of whatever it looks like at the user level)
Here are some of the different types of buttons we have style rules for:
button32 - large round toolbar buttons in navigator button28 - round toolbar buttons for action items in second tier apps other28 - round toolbar buttons for less important items in second tier apps push - 3D outset dialog buttons dialog - padded/default buttons for dialogs toolbar-flat - personal toolbar and taskbar buttons and there are several more I forget the classnames for - the 'search' button, the editor toolbar button styles, etc.
Now compound this with styles for other widgets, masses of formatting and padding styles, and you end up with a heck of a lot of style rules!
With a 4.x style skin, the browser window would have only one kind of button - the kind with the outset border with the black outline. (look at a 4.x window on windows, that's the only button type there is...) The other type would be dialog buttons. Two kinds. One kind of menu, one kind of tree widget, etc
=> smaller number of rules, faster traversal.
The native container approach is not being considered by Netscape's contributors, however there has been interest in the past among others. With a compelling embedding story, this should be possible - look at the 'web browsers' that have grown around IE's Trident.
and its a/beta/. people installing this who are not prepared for nigh on anything to happen to their systems DESERVE WHAT THEY GET.
I've lost a 2 year mailbox to mozilla, but I'm an active developer so I don't care, I know that if we don't test and fix bugs, we get nowhere - we may as well give up and go home.
remember the IE4 betas? they were pieces of shit. One of them nearly took down my system. Did people claim MS was doomed and that their final release would suck?
MS did something dramatic with IE4 - even the final version of that browser wasn't perfect, but they'd built themselves a solid platform for ease of upgrade in future versions (5.0, 5.5 - both of which were very stable in beta). Mozilla and Netscape are at the IE4 stage - do something incredibly different.
The state of the sidebar isn't stored in prefs, its stored in your profile's localstore.rdf file.
Open the file in a text editor, (its 'localstore.rdf' in your profile folder) and find the lines:
182
The value within 'width' may not be the same as mine (this is the pixel width of the sidebar box). Add the line true between the tags. Make sure mozilla is not running while you do this as it writes to this file on shut down.
I don't know why your sidebar settings aren't being saved automatically... but maybe doing it manually like this might help.
You're right, some of the other application packages available that use Mozilla XPToolkit technology are faster (e.g. Aphrodite, Sullivan etc) because their style sheets are significantly simpler.
One of the problems with the current skin is that it is huge, style wise - many rules for the different components of the UI (grey menubar menus, blue personal toolbar menus, different types of buttons etc), all of which are read into one large soup of style rules, which must be traversed (looking for matches) when resolving style for elements as the content is built (or is changed). This style resolution is a contributor to some of the UI sluggishness you may have seen.
Once the foundations of skinnability are in place (which is one of my current tasks), we will work to produce a simpler skin that should see some subtle but noticable performance improvements!
There seems to be a lot of misapprehension as to what a skin is exactly. Hopefully this will clear up when skin switching UI is exposed shortly and people can start making skins.
Currently MozillaZine's ChromeZone offers only packages for download and installation. A package is different to a skin - (well, its a superset of content, locale and skin) Content is window layout (dialog structure, javascript glue, etc); locale is localisable text strings; and skin is visual formatting.
Because a package contains content - and because content (when installed into the chrome folder) has access to XPConnect (and therefore has access to your file system, preferences, etc) a package is like any other piece of software you install - you have to explicitly trust it. A skin on the other hand is simply CSS and images - formatting and graphical presentation that does not present the same security risks. Our goal is to present two different interaction models for installation of these things.
Skins will have a streamlined installation similar to the add sidebar panel process - a site puts a link or button to a skin, user clicks, a dialog appears asking if the user wants to download and (optionally) apply the skin immediately.
Package installation however will be more complex and will contain scary warnings similar to Java permission requests and ActiveX warnings currently used in Navigator and IE.
When you install a package you are trusting the author's code not to screw up your machine. The difference to many may be slight - especially when/packages/ like Aphrodite look like appearance upgrades to Mozilla/Netscape 6, but the distinction is very important.
As soon as installers/downloaders for this content becomes available, this distinction will be clear to end users.
Currently, the process of installing a new package is so involved (copying folders into the chrome folder, loading Mozilla/Netscape with command line parameters) that trust is expected. When things can happen in a couple of clicks, expect our UI to make more noise about it;)
For more information, please don't hesitate to contact me, I'm ben@netscape.com.
if you actually want to find out how standards compliant Netscape 6 or IE5 are, WRITE SOME TESTS. Or, run some of the ones that exist (independent tests have been created by people like David Baron and Ian Hickson). See for yourself. If Mozilla fails, file a bug. It will be fixed.
If you're not willing to do even that, then shut up and take what you're given. That's the Microsoft model.
the answer is to drop DHTML support for proprietary object models. Write one standards compliant script for IE5/N6. Degrade gracefully and display regular content for users of older browsers (which is what had to happen when the 4.x browsers came out and designers had to accomodate for 3.x browser users)
Slashdot Mirror
That should be an integral part of the new outliner widget.
Dave Hyatt is working on a new tree widget for use in large trees (mail, bookmarks, etc) which is a leaf frame with no content model backing. A client creates a component that implements an interface that the widget talks to in order to paint its contents. The component is free to source its data from any medium it chooses. The tree only has to deal with matter onscreen, there is no lengthy content construction phase or RDF graph generation (unless your data store is RDF), so it is much faster. Demonstrations have shown it capable of scaling to over 5,000,000 items and appearing and scrolling quickly. Hopefully this will provide a means to solve the speed problems suffered by the mail client, and to an extent the bookmarks window. To see it in action, pull MailNews_Performance_20010208_BRANCH on Linux or Windows.
-Ben Goodger
-Netscape Navigator
Hi Jason,
;)
I showed the linked article to a few of my co-workers and we found it hilarious. Take things less seriously
http://www.silverstone.net.nz/work
That's a XHTML webpage with XUL bound to a DIV using XBL. (use a nightly or N6 RTM candidate)
(You can use XBL to create your own composite widgets from primitives supplied by HTML and XUL, or other XBL widgets, as well as implementing node APIs and event handlers, see http://www.mozilla.org/projects/xbl/xbl.html
e.g.
in the example above, produces an alert dialog 'someMethod called!'
(see sampleBindings.xml in the same directory as the above for the XBL widget implementation)
actually the functionality is there, via nsIFile and cousins. However access to XPConnect is blocked from non chrome* scripts. Try loading an XPConnect script in the content area from a non-chrome URL and you'll find your code fails.
*chrome = part of an installed chrome package in the chrome directory, e.g. Navigator.
I'm from Royal Oak, a suburb 20 minutes drive south of Downtown Auckland where this happened. I've been in Mountain View CA for the past few months but was in AK when this happened back at the start of '98. It wasn't "months", the bad blackout only lasted a week or so until people realised that yes, Mercury Energy had f*cked them that hard and that they should ease off on the electricity. The remaining time was rolling outages at scheduled times to maintain the limited supply while the overhead emergency corridor was built up the Southern Motorway and the main cables were repaired. It did cause the school year for the U of A to be delayed by a week though, and there were a couple of short incidents as things got back online, but only those living in a small zone in the CBD were hit hard. The large businesses that had their home in this area found other places to work out of and pretty much everything came back to life when the problems ended. Not an event you'd aspire your city to go through, but not something the people affected by it (in Auckland at any rate) weren't able to figure out and deal with for that period.
add to mozilla prefs.js:
" noAccess");
user_pref("security.policy.strict.sites", "http://www.geocities.com");
user_pref("security.policy.strict.window.open",
bingo.
I'm working on a UI for this.
um, no.
This data is stored locally, not on a remote server.
Note also that the Alphanumerica apps aren't themes or skins for Mozilla, they're completely different applications.
;) Skins, having no access to these things, are 'safe' (it is possible of course that someone could make a DoS skin with black-on-black, but we plan to have a timed evaluation period for skin application such that if something goes badly wrong, you will be yanked back into the previous state.)
Once you modify XUL or JavaScript, you are no longer making a skin and are making a new app.
There will be two trust models for installed matter in Mozilla - 'trusted' (skin - meaning CSS and images) which can be downloaded and installed in a couple of clicks from any website, aided by a friendly dialog, e.g.
Install the theme 'Foo theme'?
[x] Switch to this theme now
[ OK ] [ Cancel ]
Whereas anything else will have to be installed via XPInstall or similar, basically putting up the scary dialogs associated with Java auth. or ActiveX controls. Why? Because chrome level JavaScript can access XPConnect, which means it can access your filesystem, your prefs, your mail, etc
Yes, you're right, the current theme wastes space terribly. This is something I hope to sort out in a 4.x-style skin. Expect to see one hot on the heels of skinnability and skin-switching.
I would personally like to reintegrate the task switcher into the status bar like 4.x and ditch the Taskbar.
This is something we would dearly like to support - customizable menus, toolbars etc. Mozilla Classic on Windows had draggable toolbar buttons, you could drag navigation buttons and bookmarks on personal toolbars into different toolbars and locations. In Mozilla Classic, this was all done using RDF. Theoretically this is possible today in Seamonkey using RDF, however you would want Balls of Steel to attempt it, and the solution would probably be annoyingly complex. Whenever he gets time (probably not for version 1.0) David Hyatt (hyatt@netscape.com) mentioned that he could implement dynamic XUL overlays (overlays that persist state, such as item order etc) which would make this sort of thing much easier to set up.
Skinnability is one of the high priorities for Netscape 6 PR2, and is my highest priority work assignment at present.
Here's what we are doing:
1) making the FE skinnable by scrubbing the XUL code that describes it
2) creating a skin switching UI for the preferences window
3) creating skin download and installation mechanisms
4) creating new skins!
We need to get 1 nailed before we can do 4, although 2 and 3 are currently also in progress. Stay tuned...
Ben Goodger
mozilla.org UI lead
The current skin is far from being 'too simple' from a code point of view (regardless of whatever it looks like at the user level)
Here are some of the different types of buttons we have style rules for:
button32 - large round toolbar buttons in navigator
button28 - round toolbar buttons for action items in second tier apps
other28 - round toolbar buttons for less important items in second tier apps
push - 3D outset dialog buttons
dialog - padded/default buttons for dialogs
toolbar-flat - personal toolbar and taskbar buttons
and there are several more I forget the classnames for - the 'search' button, the editor toolbar button styles, etc.
Now compound this with styles for other widgets, masses of formatting and padding styles, and you end up with a heck of a lot of style rules!
With a 4.x style skin, the browser window would have only one kind of button - the kind with the outset border with the black outline. (look at a 4.x window on windows, that's the only button type there is...) The other type would be dialog buttons. Two kinds. One kind of menu, one kind of tree widget, etc
=> smaller number of rules, faster traversal.
The native container approach is not being considered by Netscape's contributors, however there has been interest in the past among others. With a compelling embedding story, this should be possible - look at the 'web browsers' that have grown around IE's Trident.
and its a /beta/. people installing this who are not prepared for nigh on anything to happen to their systems DESERVE WHAT THEY GET.
I've lost a 2 year mailbox to mozilla, but I'm an active developer so I don't care, I know that if we don't test and fix bugs, we get nowhere - we may as well give up and go home.
remember the IE4 betas? they were pieces of shit. One of them nearly took down my system. Did people claim MS was doomed and that their final release would suck?
MS did something dramatic with IE4 - even the final version of that browser wasn't perfect, but they'd built themselves a solid platform for ease of upgrade in future versions (5.0, 5.5 - both of which were very stable in beta). Mozilla and Netscape are at the IE4 stage - do something incredibly different.
1) autocomplete is coming Real Soon Now (and not just in the urlbar!)
6 9
2) good idea! RFE bug filed against me:
http://bugzilla.mozilla.org/show_bug.cgi?id=362
that might be true if IE5.5 were trying to do something new and different...
...which it is of course not.
d'oh. the code snippet was:
i debar-box">
<RDF:Description about="chrome://navigator/content/navigator.xul#s
<width>182</width>
</RDF:Description>
and the line you should add is:
<hidden>true</hidden>
The state of the sidebar isn't stored in prefs, its stored in your profile's localstore.rdf file.
Open the file in a text editor, (its 'localstore.rdf' in your profile folder)
and find the lines:
182
The value within 'width' may not be the same as mine (this is the pixel width of the sidebar box). Add the line true between the tags. Make sure mozilla is not running while you do this as it writes to this file on shut down.
I don't know why your sidebar settings aren't being saved automatically... but maybe doing it manually like this might help.
You're right, some of the other application packages available that use Mozilla XPToolkit technology are faster (e.g. Aphrodite, Sullivan etc) because their style sheets are significantly simpler.
One of the problems with the current skin is that it is huge, style wise - many rules for the different components of the UI (grey menubar menus, blue personal toolbar menus, different types of buttons etc), all of which are read into one large soup of style rules, which must be traversed (looking for matches) when resolving style for elements as the content is built (or is changed). This style resolution is a contributor to some of the UI sluggishness you may have seen.
Once the foundations of skinnability are in place (which is one of my current tasks), we will work to produce a simpler skin that should see some subtle but noticable performance improvements!
Thanks,
Ben Goodger
mozilla.org UI lead
note that editor is required because mozilla text fields are actually based on editor.
eventually, web developers will be able to insert an or similar into webpages, to allow for formatted text to be submitted via forms etc.
Potentially very useful for webmail, etc.
There seems to be a lot of misapprehension as to what a skin is exactly. Hopefully this will clear up when skin switching UI is exposed shortly and people can start making skins.
/packages/ like Aphrodite look like appearance upgrades to Mozilla/Netscape 6, but the distinction is very important.
;)
Currently MozillaZine's ChromeZone offers only packages for download and installation. A package is different to a skin - (well, its a superset of content, locale and skin) Content is window layout (dialog structure, javascript glue, etc); locale is localisable text strings; and skin is visual formatting.
Because a package contains content - and because content (when installed into the chrome folder) has access to XPConnect (and therefore has access to your file system, preferences, etc) a package is like any other piece of software you install - you have to explicitly trust it. A skin on the other hand is simply CSS and images - formatting and graphical presentation that does not present the same security risks. Our goal is to present two different interaction models for installation of these things.
Skins will have a streamlined installation similar to the add sidebar panel process - a site puts a link or button to a skin, user clicks, a dialog appears asking if the user wants to download and (optionally) apply the skin immediately.
Package installation however will be more complex and will contain scary warnings similar to Java permission requests and ActiveX warnings currently used in Navigator and IE.
When you install a package you are trusting the author's code not to screw up your machine. The difference to many may be slight - especially when
As soon as installers/downloaders for this content becomes available, this distinction will be clear to end users.
Currently, the process of installing a new package is so involved (copying folders into the chrome folder, loading Mozilla/Netscape with command line parameters) that trust is expected. When things can happen in a couple of clicks, expect our UI to make more noise about it
For more information, please don't hesitate to contact me, I'm ben@netscape.com.
Thanks,
Ben Goodger
UI lead, mozilla.org
and in fact if you look at the user agent...
Mozilla/5.0 (Windows; N; en-US; m14) Netscape6/6.0b1
(for me)
wah wah wah.
if you actually want to find out how standards compliant Netscape 6 or IE5 are, WRITE SOME TESTS. Or, run some of the ones that exist (independent tests have been created by people like David Baron and Ian Hickson). See for yourself. If Mozilla fails, file a bug. It will be fixed.
If you're not willing to do even that, then shut up and take what you're given. That's the Microsoft model.
the about: redirection just doesnt work yet. Load the HTML document by typing this into the URL bar: chrome://global/content/mozilla.html
the answer is to drop DHTML support for proprietary object models. Write one standards compliant script for IE5/N6. Degrade gracefully and display regular content for users of older browsers (which is what had to happen when the 4.x browsers came out and designers had to accomodate for 3.x browser users)