I don't know. Since you and biesi are the experts here, you're input is welcome. I certainly want to make it possible for embedding apps (camino) to override the provided XUL UI if they have something else,
Sure. It's just instantiated by contract id.
but I guess it makes sense to provide a default UI (and perhaps share the helper-app settings between all toolkit apps, in the future?).
I'm not sure on this one; app authors would have to be polled on this, perhaps.
Will XULRunner supply a functioning window.find() implementation (not that this currently doesn't really work well in Firefox).
For reference, I mis-spelled "note" as "not" there....
What does that do?
It should provide the user with UI to search the current page. In Firefox, it should probably open the find toolbar; in toolkit apps in general, that's a good question.
What it _does_ right now is always open up the find dialog (which is then busted in Firefox, of course).
Again, I don't know. This is certainly something embedders need to be able to override
Of course. All of these should be overridable by embeddors, if only because not all embeddors will use XULRunner.
but providing a default implementation might be smart.
Right. That's the question -- which of these components should we provide default impls for?
One other issue -- if we decide that some dialog needs to be in XULRunner but it, by design, basically depends on other Firefox (say) UI, what do we do? Do we do some UI redesign, do we leave the dialog out, or do we decide when we get to that point? This isn't a completely idle question, since I fully expect the helper app dialog to be in this situation.
-Boris _______________________________________________ mozilla-embedding mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-embedding
