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...
OK, now for the moment you've been waiting for. ;-) Here's some interfaces I don't see on the FROZEN list but that wxMozilla is using:
// for saving to disk nsIWebBrowserPersist
// for editing purposes nsIHTMLEditor nsIEditor nsICommandParams nsIDOMWindow nsIEditingSession nsICommandManager
// we need these to process events on Linux at least nsIEventQueue nsIEventQueueService
// for adding key and mouse event listeners
nsIDOMWindowInternal
nsPIDOMWindow // yeah, private, I know, but right now this is *needed* to get listeners
nsIChromeEventHandler
nsIDOMKeyListener
nsIDOMMouseListener
nsIDOMEventReceiver
// to set chrome/content type nsIDocShellTreeItem
// for setting the HTML for the page nsIDocShell
// for getting page content as HTML nsIDocumentEncoder nsIDocument
// for zooming functionality nsIContentViewer nsIMarkupDocumentViewer
// for right-click handling nsIContextMenuListener2
// for protocol handler nsIStreamListener nsILoadGroup
nsIStreamListener and nsILoadGroup are already included in the Gecko SDK.
nsIProgressEventSink
// for profile management nsProfileDirServiceProvider // is this right?? well, it works...
// Mac-specific - current Mozilla on Mac needs a top level window to "feed" events to it
// working on a fix to that, although it's a major one so will take time
nsIEventSink
Some of these could probably be frozen without much change, while others (like the private interfaces we're stuck using) will require some sort of alternative solution to be coded. But we need these features, and we are still working on wxMozilla so it's very possible new features will be added that utilize private interfaces as well. That's why I think it may be good to have a short term workaround while the Gecko SDK is made into what it really should be.
Thanks,
Kevin
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.
-Darin _______________________________________________ mozilla-embedding mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-embedding
