On Wednesday, June 25, 2003, at 12:24 PM, Adam Lock wrote:
Kevin Ollivier wrote:
On Tuesday, June 24, 2003, at 01:33� PM, Adam Lock wrote:
I've just checked in a work-in-progress wxWindows based sample in mozilla/embedding/tests/wxEmbed. It's early days yet, but wxEmbed is meant to exercise the Gecko embedding APIs in more diverse ways than the other embedding test apps. So it might eventually contain various test scenarios (e.g. browser, mail reader, chat, editor etc.). So far it's just a simple browser and a mail-like client and is still in development.
Hopefully some interesting reusable classes (and not just for wx) will also fall out of it. People trying to write protocol handlers or chrome objects might already like to look at the reusable Gecko* classes. These too are in development.
Build instructions are in README.txt, but it only builds on Win32 at the moment. People looking for a proper wxWindows solution should probably check out wxMozilla, from which this code is *not* derived.
Great, it's good to see some wx samples make it into Mozilla! I'll be sure to take a look at this! Is there any reason you chose not to use wxMozilla as the underlying control?
Here are my reasons, none of which have anything to do with wxMozilla as such:
1. wxEmbed is to test the Gecko embedding API. That means hitting the functionality directly and seeing what sucks and what doesn't. Abstracting behind a 3rd party class gets in the way of this and for the same reason I wouldn't use my ActiveX control for testing either.
2. Produce reusable code. I want to produce some reusable classes that work anywhere (not just in wx). For example I have workable (not perfect) generic classes for chrome and protocol handlers already in there which can be used in any system. Embedding desperately needs some helper classes and wxEmbed provides a convenient test bed to develop them. Maybe they can be retrofitted to some of the other code once they're mature enough.
3. I'm trying to test a broad range of functionality, not just being an embedded browser, but being an editor, a chat client, a rich text dialog etc. So far we've been concentrating on just producing browser apps and I've read of some pretty ugly hacks embedders have had to do to work around some stuff when they use Gecko as an editor, or some kind of rich text dialog.� The rich text dialog needs some elaboration, but if you use Gecko to render some kind of fancy message of the day dialog, you might want untargetted/untargetted links and JS onclick window.navigates in the message to spawn an external browser and not reuse the browser in the dialog. Believe me it's a mess to do this right and we need to develop solutions.
4. Licence. This code is being done under the Mozilla sample code licence which allows allowing anyone to do pretty much what they like with derived works. The wxWindows licence is a modified LGPL.
To be honest I have only glanced at the wxMozilla code but it appears to be more of a drop in solution for wxWindows developers and ties the Mozilla functionality firmly to wx derived classes.
Thanks for clarifying! You're right about wxMozilla. Actually, #3 is very much a goal of the wxMozilla project as well (not just for testing though!) - in fact, I personally am far more in need of a WYSIWYG editing solution than the browser itself. (Though I will happily use the browser as well instead of IE. =) So we need a solution for this ourselves, and we've already started looking at the issue of how to expose the Editing API in as simple a manner as possible. We'd like to avoid exposing the entire DOM, but would like to have some simple control over creating/editing links, adding images, etc. and basic text formatting - in that sense we're probably for the moment gearing towards a 'rich text editor' type of solution similar to what you have proposed. The DoCommand interface actually works quite well for simple editing commands, but trying to do things like get properties of a selected item (outside of using nsIContextMenuInfo) has been somewhat difficult for us so far. (i.e. getting an element from the current selection and using Get/SetAttribute - selecting nodes seems to be dependent on the start or end of the selection, rather than the position of the cursor)
At this point we lack expertise on the Mozilla side of the equation, and I think it'd be great if we could move towards a more collaborative effort on this. Also, I think the cross-platform nature of wxMozilla is one of the best reasons to use it as an embedding test control - it helps in finding (and maybe eliminating) subtle behavior differences in the embedding APIs across platforms. I realize this is just a first attempt at embedding efforts, but I think it'd be great to move in this direction in the future.
It's early days yet for wxEmbed but I would be happy to point people towards wxMozilla (links in the README etc.)� if they want an easy way to embed in wxWindows.
There is room for harmonising the code too, either by ensuring both wxMozilla and wxEmbed do the same with respect to initialisation, the implemented interfaces and also in what build flags they use.
In addition to this, I personally would be happy to implement and test new interfaces for editing, etc. in wxMozilla.
Thanks,
Kevin
