discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Attempting to Create Obj-C Gecko Framework


From: Pascal Bourguignon
Subject: Re: Attempting to Create Obj-C Gecko Framework
Date: Tue, 10 Apr 2001 03:28:27 +0200

> My name is Brian Powell, and I am a member of the Q.Bati project over on 
> SourceForge.  Our goal is to create a native Obj-C (Cocoa based) browser 
> based on Gecko (or NGLayout) for Mac OS X.  Just as a background, Gecko 
> is the rendering, parsing, etc. engine that is used in Mozilla.  It is a 
> fast, fairly small, standards compliant HTML/XML engine.
>
> [...]
>
> So, questions:
> 
> 1) Gecko is a C++ set of classes that do the parsing, rendering, etc. of 
> HTML pages.  It abstracts the user interface (because of its 
> cross-platform nature); however, it is definitely geared around the 
> Windows API.   Therefore, when it needs a submit button, it calls a C++ 
> method which, in turn, is supposed to create a button native to the 
> platform.  Herein lies the first problem.  As far as I can find, I 
> understand that C++ and Obj-C are not exactly friendly.  Additionally, 
> the M-V-C paradigm is not really followed in the Gecko way; however, 
> here is how I see both of those problems being overcome:  We create an 
> additional C library which is called from the C++ classes.  This C 
> library, in turn, would call the Gecko frameworks controller (let's call 
> it NGLController).  The NGLController is written in Obj-C, and, 
> correspondingly creates the button and handles the buttons messages, 
> passing them back to the interfacing C library unto the Gecko C++ 
> classes.  Is this feasible?  Do you see a better way?

Writting  C functions could  do the  job, but  this would  probably be
quite labor intensive.

A better way would be, IMHO, to take advantage of the dynamical aspect
of Objective-C.   Have a look at objc/objc.h  and objc/objc-api.h. The
Objective-C machinery  is published  as C functions  that you  can use
directly  from C++. You  could write  a single  C++ class  "ObjC" that
would allow  you to instanciate  Objective-C objects and to  send them
Objective-C messages. Minimally, something like this:

     class ObjC {
     public:
        ObjC(const char* classname);
        ObjC(retval_t instance);
        virtual ~Objc(void);
        virtual retval_t send(const char* msg,...);
        virtual id object(void);
     };

could be implemented with objc/objc-api.h and used as:

     {
        int   retainCount;
        ObjC* NSString=new ObjC("NSString");
        ObjC* title=new ObjC(NSString->send("stringWithCString:",
                                            "My Window Title"));
        ObjC* NSWindow=new ObjC("NSWindow");
        ObjC* myWindow=new ObjC(NSWindow->send("alloc")); // There's few
                    // differences between a Class and an Object.
        NSRect frame={{10.0,20.0},{200.0,150.0}};
                    // Some typedef and macros extracted from Objective-C 
                    // headers would be usefull too.
        myWindow->send("initWithContentRect:styleMask:backing:defer:",
                    &frame,NSTitledWindowMask,NSBackingStoreRetained,NO);
        myWindow->send("setTitle:",title->object());
        myWindow->send("retain");
        retainCount=(int)myWindow->send("retainCount");
        myWindow->send("makeKeyAndOrderFront:",nil);
        //...
        myWindow->send("close");
        myWindow->send("release");
            // Well, perhaps the ObjC instance should do retain/release in
            // the constructor and destructor.
        delete myWindow.
     }

(Compare with:
     {
        int   retainCount;
        id    title=[NSString stringWithCString:"My Window Title"];
        id    myWindow=[NSWindow alloc];
        NSRect frame={{10.0,20.0},{200.0,150.0}};
        [myWindow initWithContentRect:&frame styleMask:NSTitledWindowMask
                  backing:NSBackingStoreRetained defer:NO];
        [myWindow setTitle:title];
        [myWindow retain];
        retainCount=[myWindow retainCount];
        [myWindow makeKeyAndOrderFront:nil];
        //...
        [myWindow close];
        [myWindow release];
     }
)

Note however  that the Objective-C  runtimes have some  differences in
GNUstep and MacOSX,  which means that two versions  of this ObjC class
(or two concrete subclasses) would have to be written.


> 2) Support?  Is there support in the GnuStep community to build an Obj-C 
> wrapped Gecko framework which build NSButton(s), etc.?  I believe that 
> this project (because it could be used by either Mac OS X or the GnuStep 
> community) could be very valuable.  I am not focusing upon the actual 
> application, but, the framework.  Once we have a nice framework that 
> could be plugged into any GnuStep or Mac OS X application, it could be 
> very valuable to all of the application writers out there.  I would like 
> to see 10 different browsers spring out of it.  Competition of browser 
> interface would bring some great innovations.
>
> Please, feel free to write me directly if you are interested in 
> contributing to building a Gecko framework, and also please discuss it 
> on this mailing list.  I would love to see the best solution come to 
> fruition.
> 
> Sincerely,
> Brian



-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/



reply via email to

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