Hi Benjamin,
On Sep 11, 2004, at 7:56 AM, Benjamin D. Smedberg wrote:
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.
Is there anywhere I can learn more information about this?
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.
Not currently, but I plan on moving to it eventually. Looks like I'll need to add Mozilla version detection to the makefiles so that it can know whether or not to link against embedstring...
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.
Do you mean to say that static NSPR can be built already, but isn't working correctly, or that NSPR can't ever be made to work correctly because of the issues above?
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".
Unfortunately, that's a difficult thing to do as I have no idea about what changes are proposed (i.e. which interfaces are to be removed), nor do I know exactly which features wxMozilla will use in the future. So does this mean I have to vote for each interface that isn't frozen that I'd like to use now or in the future? If so, to be honest I find that to be a rather arbitrary way of making decisions. I have never used an API before where I had to ask the vendor not to remove the functions or interfaces I use in future versions.
If you have to do this, please do this only in your new toolkit so that if it breaks wxMozilla in any serious way I can tell people to stick to the old toolkit (1.x releases?).
Thanks,
Kevin
_______________________________________________ mozilla-embedding mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-embedding
