Kevin Ollivier wrote:
were somehow worked around and removed. And it looks like nsProfileDirServiceProvider may already be fixed for Moz 1.8, so if
It is not frozen in any way, and it *will* break in the future. Profile handling for the new toolkit is much different than the current seamonkey code, and we are planning on embedders using the new toolkit in a consolidated "libxul" form.
someone could add a way for an embedder to get a nsIDOMEventReceiver without going through private interfaces, we'd be able to rely solely on public interfaces.
File a bug, cc [EMAIL PROTECTED] and [EMAIL PROTECTED] (as well as myself and darin).
Also, there are two other things I care about, the first one would seem to me to be a simple fix and the other seems not to be. The first is that we've finally converted wxMozilla to use embedstring, but it looks as if the embedstring_s static lib isn't included in the SDK? Is there a reason it isn't included?
Are you using the current (1.7) SDK? The "new" embedstring doesn't have a static lib, it is entirely inline functions hooked into the frozen XPCOM embedding string API.
The second issue is static libraries for NSPR.
The reason we could really use these is because currently on Windows, if we hook into an official Mozilla build, we need to either set the PATH to the NSPR dlls or redistribute our own copy of the NSPR dlls. Editing the PATH (or asking users to do it themselves) is something I'd really prefer not to do, but for the wxPython extension, it's either that or putting NSPR dlls in the Python root directory, which basically means we have to set the PATH. ;-)
Static NSPR is not a recommended option because of conflicts with DllMain in various cases, and its inability to keep track of thread-local-storage. Note that you *can* munge PATH at runtime on win32, if you use runtime linking instead of dynamic linking.
say I think wxMozilla gives the embedding libs a good workout!) My main concern is working with private interfaces, which could plain disappear in future releases. And if such a thing were to happen, and no one realized that embedders had to use those interfaces, then we could be up a creek without a paddle, so to speak.
It is unlikely that the *functionality* of a private interface would disappear, just be moved around in small or big ways. However, you should try to make the mozilla devs aware of which functionality you would *like* to see in frozen interfaces. Many of our internal interfaces are destined to be "deCOMified".
--BDS _______________________________________________ mozilla-embedding mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-embedding
