[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Attempting to Create Obj-C Gecko Framework
From: |
Pedro Ivo Andrade Tavares |
Subject: |
Re: Attempting to Create Obj-C Gecko Framework |
Date: |
Wed, 11 Apr 2001 02:39:00 -0300 |
At 13:07 10/4/2001, Brian Powell wrote:
On Monday, April 9, 2001, at 10:23 PM, Pedro Ivo Andrade Tavares wrote:
This framework could implement XPCOM in terms of ObjC objects; if
everything goes alright, Gecko C++ objects (such as nsiWebBrowser and
such) could be seen as ObjC objects, by running the *.idl files through a
xpidl-to-objc tool. That would make the job a lot easier.
Hmmm, interesting; however, I'm not sure that gecko uses XPCOM for
creation of the UI (which is the problem I am looking at right now). I
may be wrong, please correct me if so.
Well, check out http://lxr.mozilla.org/seamonkey/source/gfx/idl - you can
see the XPCOM idl interfaces for several classes, including
nsIFontEnumerator, nsIGraphics, nsIPrintOptions, nsIScreen, and so on.
However, in http://lxr.mozilla.org/seamonkey/source/widget/public/, there
are several idl interfaces for the mozilla/widget objects, but not for some
very important to you, such as nsIButton. So, it appears they are halfway
there.
I still believe doing a XPCOM interface for ObjC would make your job much
easier; especially since it's the base of the embedding API for Mozilla.
Also, I suggest you do not try to go overboard in providing gnustep-gui
buttons, and such, to Gecko. First focus on embedding Gecko as it is
today into a NSView. Then, if XPCOM has been correctly implemented by the
Mozilla team, you will be able to write XPCOM ObjC objects to provide a
wrapper over the gnustep-gui objects.
Well, see the problem with Gecko is that it must render graphical objects.
I understand that. My original suggestion was, leave the rendering layer to
be ported later. Maybe use the Xlib widget set, instead of the GTK one, and
just render it as-is into a NSView. When that is working (and that will be
enough of a challenge for some time) you can focus on the rendering.
Quoted From <http://www.mozilla.org/newlayout/ngport.html>:
There are three parts of the new layout engine that are not cross
platform and therefore need to be implemented for each environment to
which it is ported. These are parts of mozilla/base, parts of mozilla/gfx
and mozilla/widget:
mozilla/base contains a public interface called nsITimer that is used for
triggering timeouts. There is also a test directory in base containing a
test app to exercise the timer.
I don't think this has to be changed much. Maybe you should use NSRunLoop
to implement it over GNUstep, but I'm not sure what would be the gain here...
mozilla/gfx contains a set of interfaces to enable cross platform
rendering of lines, rects, text, images, etc. All of the graphics
interfaces are spec'ed in mozilla/gfx/src. The set of interfaces that
have XP implementations have corresponding .cpp files in gfx/src. The
remaining interfaces are implemented per-platform in subdirectories of
gfx/src. For a list of exactly which interfaces need to be implemented,
use gfx/src/windows as a guide.
mozilla/widget contains a set of interfaces for cross platform support of
user interface widgets (i.e. button, scrollbar, editfield, etc). To date,
the implementation of the widgets is completely platform dependent so
there is no code shared among the various implementations. The scope of
widgets and there functionality is essentially that required to support
HTML form elements. The interfaces are defined in widget/public and there
are per-platform subdirectories in widget/src.
So, from reading this and a brief glance through the code, there are
native UI instantiations for each port. This is what I was referring to
in that I needed to create an NSButton from a C++ object. My thoughts
were that the application would create an NSCell (or NSView) and embed
gecko within it. gecko would then create the controls it needed (as
directed by the HTML page, for instance, a text field) via the gecko
controller (NGLController as I am naming things) would handle the
creation, communications, etc. So, the model is gecko, the controller is
NGLController, and the view is created by the application.
That seems right to me. But for now, leave the NSButton for later, and try
getting by with a regular Xlib button (look for the xlib directory inside
mozilla/widget/src).
I am simply in the investigation, study, and recruitment phase right now,
so, everyone who has written, your input has been very valuable.
Thank you!
Good luck on your effort!
Pedro Ivo Andrade Tavares
- Re: Attempting to Create Obj-C Gecko Framework, (continued)
- Library Paths?, Steve Núñez, 2001/04/11
Re: Attempting to Create Obj-C Gecko Framework, Pedro Ivo Andrade Tavares, 2001/04/10