Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] MacOS X port status?

Martin,

On 11/27/01 1:51 PM, "Martin Sturzenhecker" <msturzen@xxxxxxx> wrote:

> I guess I know now where the problem is.
> I couldn´t build the project with the .pbproj file found in your
> Blackmoon.tar.gz.
> When I attempt to build the project, the build tool says it wasn´t able
> to build the files in /Users/maurice/.... I couldn´t change the install
> path (probably the path is hardwired when you create the project), so I
> created a project (Pure Java) of my own, imported the files into this
> project and added the cocoa packages to the classpath.
> This way the compile is OK, but no cocoa windows show up.
> With what kind of project-template did you create Blackmoon?

Java Tool.

It looks like we're having some issues with how Project Builder does it's
project configuration.  I'd like to switch to using Eclipse for development
soon.  If that doesn't happen, then I'll make these issues don't pop up
again in the Project Builder version.

It's been a busy week for me, so I haven't made as much progress as I'd
like.  Hacking on SWT and Cocoa may be fun, but J2EE keeps the heat turned
on in the winter.  ;-)
 
> Do you want to use the inner class approach you mentioned in an earlier
> post?

That was my original plan.

> Making Event SWTEventObject subclasses of NSNotification would enable us
> to treat SWT events like Cocoa Notifications.
> But then we have to supply the API of java.util.EventObject in
> SWTEventObject to ensure compatibility.

I don't think that NSNotification will provide us enough information to be
used in this capacity.  NSEvent is probably a better match.  Take for
example org.eclipse.swt.events.MouseEvent where we need the x & y
coordinates of the mouse event.

I don't think that we can use the inner class strategy in this case either,
because the properties of the TypedEvents can be public.  I think we need to
morph the NSEvents into TypedEvents (I'm not sure where ImageLoaderEvent
fits into the picture yet) using a pattern similar to how I implemented the
toNSRect() and toRectangle methods() in the Morph class.  I would probably
add the method "public TypedEvent toTypedEvent(NSEvent nsEvent)" that would
return back the correct TypedEvent by evaluating and translating the
NSEvent's properties.

-Maurice



Back to the top