Re: Attempting to Create Obj-C Gecko Framework

[Pedro Ivo Andrade Tavares]

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