[Top][All Lists]

[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]