I just want to clarify that up front to head off efforts to use the embedding APIs in XUL in places where it does not make sense to do so. A XUL application will never use all of the embedding APIs. It will only use a subset.
dave
([EMAIL PROTECTED])
Judson Valeski wrote:
[EMAIL PROTECTED]"> If the mozilla standalone client is ever going to become a true "embedding API" customer, we need to sort out the cross-over between the embedding implementation, and the "main" implementation of various sub-systems.
There are a few pieces I can enumerate off of the top of my head (with varying degrees of depth. please add/modify as necessary) that we have duplicate (different) implementations in the embedding and mozilla app cases:
sub-system
Mozilla
Embedding
"windows"
nsXULWindow
nsGlobalWindow
save-as
proprietary
nsWebBrowserPersist
printing
proprietary
nsIWebBrowserPrint
command handling
proprietary
nsICommandHandler
To what degree the two worlds collide is up for debate, but at a minimum, we need to remove the redundancy because it leads to duplicate debugging efforts and fixes, as well as inconsistent semantics which dilute our embedding story.
Jud
