On Sep 10, 2004, at 3:52 PM, Darin Fisher wrote:
Kevin Ollivier wrote:
Hi Darin,
On Sep 10, 2004, at 2:03 PM, Darin Fisher wrote:
Kevin Ollivier wrote:
Hi all,
As others have said in earlier messages, the SDK isn't nearly as useful as it could be due to the fact that some very important interfaces aren't yet frozen nor will they be for some time. At the same time, however, people are still using Mozilla for embedding and that means everyone has to build their own Mozilla. As an alternative to the SDK, wouldn't it be possible to just zip up the "dist" folder from Mozilla builds and make them available for download? This would make life easier for embedders, at least those who would benefit from the SDK (i.e. not using custom builds), and get people up and running with a new build much quicker.
Thanks,
Kevin
I'm actively working to improve the Gecko SDK. My main focus are dealing with the interfaces listed in this bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=248683
Please let me know if that list does not cover an interface that you are using. (I'm sure there are many.) Just respond to this posting, and we'll review and compile the list from this thread.
Before I list the interfaces, I should say first that I meant for the dist packaging idea to be a temporary stopgap until the Gecko SDK gets some more polish to it. Also, I should note that on GTK+2 we need to fire up an nsIAppShell (you asked about nsIAppShell in the bugzilla page), otherwise the app just segfaults. We just fire it up on all platforms (Windows, Mac, Linux) as it seems to do no harm.
If all you care about are the non-frozen interfaces, then you don't have to build all of mozilla. You could download the source, and type "make -f client.mk export" to only generate all of the header files from IDL. That's at least better than waiting for the whole of Mozilla to compile, but yeah... or, perhaps we should post a package of non-frozen headers on mozilla.org. Hmm...
I'd definitely prefer to have something packaged and downloadable from mozilla.org, as wxMozilla has more users than developers and it'd be nice if we could just point users to the mozilla.org SDK rather than keeping our own "complete" internal SDK, which we currently do. What about adding a "include/non-frozen" dir that has all the non-frozen public interfaces? Anyone who needs those headers just has to add an extra include dir to their makefile and they're set. There is still the problem with the 2 non-public interfaces we use, but at least the SDK would be ready for us "out of the box" once those two private includes were somehow worked around and removed. And it looks like nsProfileDirServiceProvider may already be fixed for Moz 1.8, so if 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.
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? 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. ;-)
[snip]
// for protocol handler nsIStreamListener nsILoadGroup
nsIStreamListener and nsILoadGroup are already included in the Gecko SDK.
Oops, sorry, I was going by the mozilla.org Embedding project docs.
[snip]
Thanks for your input. I appreciate the list of interfaces. Many of those won't be frozen as is, but at least it is good to know what wxMozilla is using.
No problem. Personally, I don't mind using non-frozen interfaces, as most of the APIs I work with haven't changed considerably over the past couple years. So in practice, a non-frozen interface hasn't proven to be much more difficult to work with than a frozen interface. (And I should 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.
Thanks,
Kevin
_______________________________________________ mozilla-embedding mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-embedding
