Community
Participate
Working Groups
I can't open a graphic interface editing tool to make a swing java application!!!! I've installed on Eclipse The VE librarys and the GEF librarys but when the interface try to start a system error pop up in my system!!!!! I've some immage of my eclipse running and crash!!!!
Created attachment 7001 [details] Eclipse error
Created attachment 7002 [details] Library installed on Eclipse
This version of VE is not fully supported on MacOS.
!ENTRY org.eclipse.jem.proxy 2 0 d?©c. 03, 2003 23:41:00.843 !MESSAGE IWAV0070W Cannot find a proxy implementation to use for project "test2.1.2." !ENTRY org.eclipse.ve.java.core 4 0 d?©c. 03, 2003 23:41:01.26 !MESSAGE Exception !STACK 0 java.lang.NullPointerException at org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEditorPart.createProxyFactoryRegistry(Java VisualEditorPart.java:669) at org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEditorPart$Setup.initializeForProject(JavaV isualEditorPart.java:1800) at org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEditorPart$Setup.initialize(JavaVisualEdito rPart.java:1705) at org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEditorPart$Setup.run(JavaVisualEditorPart. java:1588) at java.lang.Thread.run(Thread.java:491) !ENTRY org.eclipse.jem.proxy 2 0 d?©c. 03, 2003 23:41:45.575 !MESSAGE IWAV0070W Cannot find a proxy implementation to use for project "test2.1.2." !ENTRY org.eclipse.ve.java.core 4 0 d?©c. 03, 2003 23:41:45.583 !MESSAGE Exception !STACK 0 java.lang.NullPointerException at org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEditorPart.createProxyFactoryRegistry(Java VisualEditorPart.java:669) at org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEditorPart$Setup.initializeForProject(JavaV isualEditorPart.java:1800) at org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEditorPart$Setup.initialize(JavaVisualEdito rPart.java:1705) at org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEditorPart$Setup.run(JavaVisualEditorPart. java:1588) at java.lang.Thread.run(Thread.java:491)
*** Bug 48487 has been marked as a duplicate of this bug. ***
updated FAQ to mention at this time not support MAC OS X.
*** Bug 60272 has been marked as a duplicate of this bug. ***
The hide bug seems to be back. I can't solidly reproduce it but I just tried the following steps; 1) try to hide Eclipse - would not (Command-h) 2) switch to another application 3) click on the Eclipse icon in the doc 4) Eclipse hid 5) Eclipse would not un-hide This was not a problem since M2 or M3 can't remember exactlly which one it went away in.
Please, put a cue at the download page. There is Status green and Platform All. Most pepole download first, then read the FAQ. Is there more information about this problem? OK the code. Which version was fully supported on MacOS? Is somewhere a comparable (simple) implementation which works? I'm new in Java, but I could spend time in this.
The build page is generated automatically with our build process... we definitely need to fix the process to generate clearer download pages noting what is supported/tested. Especially as we start supporting Windows platforms.. M2 will support Windows and Linux GTK. Note that the main reason for the delay on the Mac OS is that we need to dive into Carbon code to figure out how to screen scrape images - any help will be appreciated. We have just finished this effort with GTK, and would work on Motif support next. ... Carbon is definitely on the list.
> We have just finished this effort with GTK BTW, where can I find implementation for GTK? I see in CVS class ImageCapture, but it looks as only Windows implementation.
The M2 stream is not HEAD, as we have started to put more breaking changes in HEAD. The GTK code will be merge when M2 is released. Looking forward for you help on this matter, Konstantin.
Is anyone looking at OS X support?
*** Bug 69596 has been marked as a duplicate of this bug. ***
I've started looking at the problems with VE on OS X, along with Frank Sanders (fsanders@mac.com). The good news is that we've gotten to the point of being able to bring up the VE and develop Swing/AWT on OS X when running the VE in the development environment. Unfortunately it doesn't work the same when using a binary build. The problem seems to be with the dynamic compilation of the Java JET templates that are used to generate the skeleton code of a new visual class and other templates used within the code generation. The parsing of the JET template itself goes through ok (we've debugged to the point of seeing the CompilationUnit with the correct Java source as the contents) but passing the CompilationUnit to JDT to compile is failing. It seems the classpath for JDT isn't setup properly for this dynamic compile, as it is unable to resolve java.lang.Object necessary for the compilation of the class. The next step is to look into whether the classpath for the JDT is set up properly, and if not, why is it different on OS X than on Linux and Windows. This status update is meant to offer some hope to OS X users that progress is being made on bringing VE to this platform post-1.0.
Hi, I don't know why java.lang.Object would not be found but in the mac env there is no tools.jar, everything is in the classes.jar (its apple, they had to be different). This causes/has caused several problems for other apps that need to compile (jboss at one point asserted that tools.jar was found for example and had to be updated for the mac). Is it posible that something in the VE or JET is requiring this jar file instead of looking for the class? Just a thought. Thanks again for getting stated on this. I for one can't wait to play with it!
OK, VE's not working on OS X due to this bit of code in JDT: In class org.eclipse.jdt.internal.launching.StandardVMType, in method detectInstallLocation() line 148: if (Platform.getOS().equals(Constants.OS_MACOSX)) { return null; } So either JDT needs to implement this function on OS X, or we'll need to try to implement it ourselves.
Are you sure that you are using the org.eclipse.jdt.launching.macosx fragment? IIRC it implements the Mac specific pieces that the generic org.eclipse.jdt.internal.launching.StandardVMType cannot handle. (I'm the owner of that fragment, so let me know if I can help)
This problem seems to occur when JDT tries to find the default installed VM... What if you explicitly sets a VM configuration (for install location)? Will this move you over this hump?
Please check MacOSXVMInstallType.detectInstallLocation() and let me know if it doesn't work for you. However, you have to make sure to use the "MacOS X VM" JRE type and not the "Standard VM" type. If you have the fragment then the default JRE should be "MacOS X VM" automatically.
Whoops, sorry we missed the fragment. But the detectInstallLocation() method in MacOSXVMInstallType is still not working correctly. The problem is that the vm we're using is a VMInstall that's known about by Eclipse. So the if clause on line 101 always fails on the correct VM (the findVMInstall returns non-null). It looks like there should be an else clause to this condition that detects if the current version it's checking is the default that it will set the defaultLocation variable properly before the return. It might need to call the JavaRuntime.setDefaultVMInstall method as well, but I would think that it would automatically be the default.
Created attachment 14756 [details] Patch for OSXVMInstallType This patch makes detectInstallLocation() function properly on an installed JRE. Applying it makes the VE launch properly. The patch applies to the v3.0.1 version of the org.eclipse.jdt.launching.macosx plug-in.
*** Bug 78732 has been marked as a duplicate of this bug. ***
Are we going to have this patch (and whatever else might be necessary to get MacOS X working with VE) applied to the main 3.0.x stream soon? I would very much appreciate being able to use VE. The alternative seems to be for me to build my own Eclipse with this patch applied, but like everyone else my time is limited and it might be simple enough to pick this up in an official build if you folks are ready to do this.
A fix for this bug went into the Eclipse 3.1 M3 build (see bug 75201). Unfortunately I don't have access to an OS X machine anymore so I can't test out the VE on M3. If you'd like to try this out (with the latest 1.0.x Stream Maintenance Build of VE) and report back here, it'd be appreciated. There are quite a few other problems with VE support on OS X, but at least it should start up OK while working with AWT/Swing.
I tested the VE on Mac OS X (10.3.6) (Java 1.4.2_05 (Apple's Update 2)), as indicated by Jeff's comment. I download these components: Eclipse 3.1M3, VE M20041116, which says it is dependent on EMF build 2.0.1, GEF build 3.0.1, Eclipse build 3.0.1, but I skipped 3.0.1 and went with 3.1M3 as indicated. I am so thrilled to actually see this work, I didn't mind the slowness of the response! I noticed that when I brought up the VE, two extra JVM's started and showed up in the dock (along with the Eclipse icon). One of the JVMs corresponds to a "FreeFormComponentsHostDialog" frame which appears to be a "live" view of the components as I build them in the VE Panel within Eclipse. I don't recall that when I first worked with VE on Windows. Thanks for working on this for us Mac OS X switchers! If there is any other testing I can help with, let me know!
My reading of comment #26: - it's running - it's slow, and forks multiple VMs (ugh) Andre: Do you know why they are getting the extra doc icons for the other VMs? Can they just run a command line VM instead to avoid this?
I tested VE with the same component versions as Kathy Lee Simunich. Same problems here: multiple VMs, _very_ slow My hardware shouldn't be the problem: Dual1.8 G5, 1.2 GByte RAM Nevertheless, I'm happy that it finally works on MacOSX :-)
> Nevertheless, I'm happy that it finally works on MacOSX :-) This bug has been quite quiet during the last half year. Is this still the status? Or is there some other bug that tracks the progress on Mac OS X? I couldn't find an updated entry in the FAQ, so I assume that VE still doesn't really work on OS X?
Martin, I no longer have access to an OS X machine (but have been kicking around the idea of getting a mini) so I haven't been able to work any more on OS X support. As far as I know, none of the other developers on the VE team have easy access to a Mac either... so that hampers things a bit. We also lack expertise in OS X development (especially in the Carbon coding necessary to get SWT support working) so progress on this feature is contingent (at least at the moment) on volunteers from the open source community doing development and testing. Even bug reports on specifics of what works and what doesn't are helpful (I don't know if anyone's tried the VE 1.1 milestone or nightly builds on Eclipse 3.1 yet) Volunteers for this effort can voice their interest on the VE development mailing list, newsgroups or on this bug report. I'm sure the VE team will be happy to help with questions on ramping up on development and help work through issues as best we can without having access to a Mac ;)
i just gave it a try: I used eclipse3.1M7, emf I200504141117, GEF 3.1M6, VE 1.1M1 running on MacOSX 10.4.1 with Java1.4.2 Eclipse started fine (quite fast actually), I could create a VisualClass using the wizard. Empty frame displayed correctly (as far as I can tell :-) ). Then the problems began: after adding a JLabel, Eclipse stopped responding. (The JLabel displayed in the GUI view, but further editing was not possible) When I forced quit, i got exit code 143 (don't know what that means). Also, I had 2 additional java processes in the OSX Dock called: org.eclipse.jem.internal.proxy.vm.remote.RemoteVMApplication One had no visible components, the other had 2 windows: 1 called 'Application' (the JFrame i created), 1 called 'FreeFormComponentsHostDialog' There was a second FreeFormComponentsHostDialog, but that didn't seem to belong to one of the remoteVM-processes ?!? These windows appeared nearly out of the viewable screen-area, in the lower right corner of my display (resolution 1600x1024, if that should matter). I restarted Eclipse, started VE -> again two additional java processes in the dock. Quit Eclipse, 1 of the java processes disappeared, the other remained :( I then tried the same with Eclipse3.1M6: exact same behaviour.
I'm sure there are a number of Mac users who are interested in using this feature - but I don't currently see any list anywhere of the 'incomplete' parts necessary needed to make this port complete on Mac OS X. Can someone on the Eclipse team come up with a strategy and task list for tackling this problem - something for the community to rally around and help tick off items on? Solving problems on the Carbon side is definitely something that many of us can help with - if someone can tell us where the missing functionality is to help reduce the burden on those of us familiar with the Mac, but not necessarily with Eclipse.
Coming up with a list with tackleable tasks would be a very good idea. I'll start work on this, and it should be easier to get input from the rest of the VE team now that the stresses of the 1.1 release are over :) But in the meantime here's a task that'd be a good start: The most important code that is needed to get SWT supported on OS X is the ability to capture the image of the widgets being rendered in the remote vm window, and being able to do this while the window is offscreen and/or obscured by other windows. This has required platform specific code on Windows and GTK (including a native library in the case of GTK) - so it's likely that the same will be necessary for OS X. A very good place to start would be to create a Carbon app with a button and a few other widgets. When the button is pressed, an snapshot image of the UI is taken, then another window is opened and the image is displayed. Bonus points if it works properly if the first window is captured properly if the window is partially dragged off screen so that some of the other widgets are not showing at all. The next thing would be to add another button that captures just a specific widget (a table, combo box, etc) that's on the window.
What sort of data is needed for the image? For example, it's pretty easy to get hold of a PDF from a window in Mac OS X, but I'm pretty sure this isn't the feature that you're looking for :-) Also, there's a bunch of stuff in Cocoa classes like NSView; is there any reason why it has to be accessed through Carbon?
I don't know enough about Cocoa to know if we'll be able to use it. I was assuming that we'd need to use Carbon because SWT is implemented in Carbon - so the handles to the widgets and windows that we can get at from SWT are Carbon ControlRef and WindowRef pointers. If Cocoa can be accessed via JNI and can translate these ref pointers into objects usuable from within Cocoa, it should work. As for the image format... we need to be able to create an SWT Image from the data. In the case of GTK we created an SWT ImageData object (http://help.eclipse.org/help31/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/graphics/ImageData.html) and called setPixels(int x, int y, int putWidth, int[] pixels, int startIndex) on it, with integer pixel data that corresponds to the color depth used on the display. The native call we wrote has the signature int[] getPixels(int handle, int includeChildren). The return value of that method has a header that includes the width and height of the image, the type of the image (RGB or indexed colors), the color value masks for RGB, and then the actual pixel data. I'd expect we'd do something similar to construct Images from OS X, but alternate means (that work) would be great.
It looks like RealBasic also works in Carbon when building applications in mac os X. It is possible to create offscreen images with Real Basic, here is an example: http://realgurus.com/tutorials/PictGraph.html the question now is how can it get the handles to the SWT widgets and windows? thanks jose (In reply to comment #35) > I don't know enough about Cocoa to know if we'll be able to use it. I was > assuming that we'd need to use Carbon because SWT is implemented in Carbon - so > the handles to the widgets and windows that we can get at from SWT are Carbon > ControlRef and WindowRef pointers. If Cocoa can be accessed via JNI and can > translate these ref pointers into objects usuable from within Cocoa, it should work. > > As for the image format... we need to be able to create an SWT Image from the > data. In the case of GTK we created an SWT ImageData object > (http://help.eclipse.org/help31/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/ eclipse/swt/graphics/ImageData.html) > and called setPixels(int x, int y, int putWidth, int[] pixels, int startIndex) > on it, with integer pixel data that corresponds to the color depth used on the > display. The native call we wrote has the signature > int[] getPixels(int handle, int includeChildren). > The return value of that method has a header that includes the width and height > of the image, the type of the image (RGB or indexed colors), the color value > masks for RGB, and then the actual pixel data. > > I'd expect we'd do something similar to construct Images from OS X, but > alternate means (that work) would be great. (In reply to comment #0) > I can't open a graphic interface editing tool to make a swing java application!!!! > I've installed on Eclipse The VE librarys and the GEF librarys but when the interface try to start a > system error pop up in my system!!!!! > I've some immage of my eclipse running and crash!!!!
I think it'd be helpful to have a Carbon app that can capture itself first, then worry about SWT integration afterwards. But if you want to see the existing SWT integration for Windows and GTK, take a look at the ImageCapture classes in the org.eclipse.ve.swt plug-in: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ve.swt/vm_swt/org/eclipse/ve/internal/swt/targetvm/win32/ImageCapture.java?rev=1.11&cvsroot=Tools_Project&content-type=text/vnd.viewcvs-markup and http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ve.swt/vm_swt/org/eclipse/ve/internal/swt/targetvm/unix/ImageCapture.java?rev=1.9&cvsroot=Tools_Project&content-type=text/vnd.viewcvs-markup
Ok, maybe this is off base... HIViewCreateOffscreenImage will render an HIView (a canvas and all its children, or a single control) into an offscreen CGImageRef. http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/hiview_ref/ chapter_1.2_section_3.html#//apple_ref/doc/uid/TP30000785-DontLinkChapterID_2- HIViewCreateOffscreenImage Once you've got the view and its children, you should be able to call that to create a CGImageRef which represents the image itself - which you're then free to read the pixels out of. So, if an underlying SWT widget is a HIView, you've got a one-call mechanism of rendering it offscreen and getting the bitmap, even if it's not currently being displayed. Correct?
I had come across that method when investigating the Carbon code that allows this SWT snippet to work: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet95.java?rev=HEAD&content-type=text/vnd.viewcvs-markup and it sounded very promising. But if I recall correctly, from testing it a year or so ago the snippet didn't work properly if the widget being captured was obscured by another window or if it was dragged offscreen. Could you test this out? On Windows, the remote VM's UI is placed offscreen at the location 10000,10000 but most window managers on Linux and I think OS X doesn't allow you to place the windows completely offscreen. But still we should try to minimize the visibility of the remote VM windows whenever possible.
Another aspect that needs to be addressed is capturing the window decorations (the title bar, close/minimize/maximize buttons, etc. Hopefully we'll be able to capture the actual window image, rather than having to mock them up like we do on Linux/GTK. The Window Regions, as explained here: http://www.mactech.com/macintosh-c/chap04-1.html looks like it may be useful, via the GetWindowRegion, and then somehow get the pixmap of that region.
To the best of my knowledge, the whole window, including all nav elements, should be available as the root element; the view area (the primary view) would be retrieved differently. No need, to the best of my knowledge, to resort to old MacOS 8/9 API - offscreen render should do the job for any widget, including the root window and all of its contents; it should render into an offscreen buffer in virutal VRAM which can then be accessed by the CG APIs as a CGImage. I have no doubt that relying on stuff like GetWindowRegion, which found its most common usage by people trying to figure out what window regions are dirty when rendering their view, might have strange behavior on offscreens and obscured content. Offscreen ftw, methinks. Is there existing code that uses it somewhere?
Re comment 39: I've spent a couple hours digging around, and I now have an XCode project that displays two windows, each with a button on them. Clicking the button on window A makes an image capture of the button from window B and displays it in an HIView. This capture works if the widget in window B is offscreen, or obscured by another window, etc. This is on OSX 10.4.2 Would this code be useful? I can attach the XCode project to this defect if desired...
We have to make sure that there are no lic. issues with this code?
(In reply to comment #43) > We have to make sure that there are no lic. issues with this code? AFAIK the code will be EPL as soon as it is available in Bugzilla.
Excellent. Could you see if you can add another button to window A that captures the entire image of window B?
Comment 42: I was wondering what exactly does XCode suite output? Is it an XCode app, or a native Mac OSX app? Because Eclipse relies only on Carbon libraries I think and it would be better not to put additional library requirements for having this. Can you package the API which is called when you press the button as a library which can be loaded from Java?
XCode is a builder; it can output many different types of app, library, or framework. What it's linked against is probably more of an issue, since Cocoa is already a no-go; however, the reference to HIView suggests that it's a Carbon app, rather than a Cocoa one.
re #47: Yes, it's a Carbon app. re #45: I've added a second button which captures the entire contents of the child window, including the frame. I'll attach the project...
Created attachment 26448 [details] Illustrates capture of widget or wntire window XCode 2.1 project, OSX 10.4.2 Click "widget" to capture widget in child window, click "window" to capture entire child window. The red rect is drawn to illustrate the bounding box of the captured image.
Created attachment 26449 [details] Illustrates capture of widget or entire window XCode 2.1 project, OSX 10.4.2 Click "widget" to capture widget in child window, click "window" to capture entire child window. The red rect is drawn to illustrate the bounding box of the captured image.
doh! Sorry for the duplicate attachment... that'll teach me to try and fix a spelling mistake.
Created attachment 26452 [details] VE-MACOSX-capture-framework.zip To test out the interface with Java (which is the end goal), I am attaching a small Java app which will call the native capture mechanism and return the image. Import this into a project which pre-reqs Eclipse OSX SWT plugin, and run the ImageGrabberTest_layout.java file as a SWT app. This will open two SWT Shells - one with widgets and the second to capture the first when the 'grab' button is pressed. fprintf statements in native code to stderr stream, should allow you to debug the status in the native code. Any XCode gurus please feel free to hook in the code presented by bill@hutten.org to make capture of Carbon widgets possible from SWT.
Non-native solution possible? I was going through the code provided by bill@hutten.org and was looking at main.c in his project and realized maybe if this was all possible without any native code at all. In the main.c the code which gets the image is (correct me if i am wrong): ------------------------- HIViewCreateOffscreenImage(childControl, 0, &viewRect, &image); HIViewSetNeedsDisplay(myHIView, true); break; ------------------------- In SWT itself the 'org.eclipse.swt.internal.carbon.OS' class there is an API "HIViewCreateOffscreenImage(int, int, CGRect, int[])" . I was wondering if anyone with a MAC machine could quickly test out if calling this api passing in the control's handle would return and image? If it does then the problem of offscreen capture could be solved, and no messy C-Java native interaction. bill@hutten.org: will this API suffice to capture offscreen/hidden/etc. or is there any additional magic required for that?
Re comment # 53: Yes, this line of code: HIViewCreateOffscreenImage(childControl, 0, &viewRect, &image); Is all that's required to capture the image of a control. To capture the image of an entire window you need to grab the root HIView from a windowRef, ie: rootView = HIViewGetRoot(childWindow); HIViewCreateOffscreenImage(rootView, 0, &viewRect, &image); The image returned by HIViewCreateOffscreenImage is a CGImageRef. HTH - bill
Created attachment 26458 [details] Testcase to test capture using SWT API itself Actually, looking more into this 'org.eclipse.swt.graphics.GC' class has a 'copyArea(Image, int, int)' method which does all the OS.HIViewCreateOffscreenImage() stuff for us. So I created a simple project with SWT JARs in it and the ImageCapture program to use the 'copyArea(Image, int, int)'. ----------------------------- protected Image getImageOfControl(Control control, int includeChildren/*ignored*/){ Image image = new Image(control.getDisplay(), control.getBounds()); GC gc = new GC(control); gc.copyArea(image, 0, 0); gc.dispose(); return image; } ------------------------------ Could anyone test if this simple call works for MAC with offscreen / minimized /etc. widgets?
I got a Mac. If you want me to test it just mail me the project and tell me what to do ;-)
Attachment 26458 [details] is the project itself. Please bring this project into an Eclipse workspace and Run the org.eclipse.ve.internal.swt.targetvm.macosx.carbon.ImageGrabberTest_layout.java file as an SWT application (Run>Run As>SWT Application). This will show two windows - one with a lot of widgets and another with a Grab button on it. Minimize the first window (with widgets) and hit Grab on the second window. Doing this should paint a screencap of the widgets below the Grab button. This should work when the window with widgets is offscreen and partially offscreen etc. Thanks.
Re comment # 57: I'm using Eclipse 3.1 build I20050624-1300 and ImageGrabberTest_layout works fine for me. The capture works if the window is obscured by other windows, if it's minimized to the dock, etc. OSX 10.4.2
this is not the full trueth. it captures the window, but the captured image does not show the text inside the table or the textbox. Version: 3.1.0 Build id: I20050627-1435
Does it only not capture the text when it's obscured or off screen, or does the text not show all the time? This problem sounds like a similar issue that we ran into GTK that there was an SWT optimization to not render text when it's obscured. We were able to disable this feature, but that code is not in the test code that Sri attached.
Created attachment 26465 [details] Testcase to test capture using SWT API itself (Text fixes) comment 59: this is similar to a known problem with SWT/GTK text controls, where SWT blocks paint requests of the native text controls if they are hidden, as it is CPU intensive to paint text. Please try the new project and see if the text controls paint properly when hidden/minimized etc.
Sorry for not catching the problem with the missing text in the table and text area... I've just downloaded and tested the 2nd version of the Testcase, and it still exhibits the "missing text" behaviour for me. As with the 1st version, the text of the table and the two textblocks are missing from the capture. Interestingly, in both versions the text in the list object (upper-right) is captured fine. I'll attach a screenshot which illustrates the behaviour.
Created attachment 26475 [details] Illustrates "missing Text" problem with capture
Opened bug 108635 to track problem of SWT Text widgets not painting in MAC OSX.
Jeff has released changes so that VE uses the correct capture mechanism. It would be great if anyone could try the new 'N20051018' VE build to see if the exceptions go away regarding capture problems. With bug 108635 being fixed, the text painting problems should go away once VE steps up to the latest Eclipse milestone builds.
Also you'll have to try it on the latest Eclipse 3.2 Integration build (I20051018-0932 or later) to get the changes made to resolve bug 108635.
Is this still work in progress? I'm a Mac OS X 1.4.2 User with Java 1.4.2 and Java 1.5.0 installed and since I loved VE on my linux I'd be glad to help with the OS X gitches. I'll grab the 3.2 Integration build right away, just keep me updated what I have to do :) BR; MaC
Created attachment 28777 [details] Illustrating test grab problem on mac os x Using latest VE and Eclipse Integration buils, the problem still exists :(
Created attachment 28778 [details] Illustrating text grab problem on mac os x Using latest VE and Eclipse Integration buils, the problem still exists :(
I've obtained a Mac Mini, so now can work on supporting VE on OS X. Unfortunately, I've come across a pretty big blocker of getting SWT working on OS X after a few hours of debugging. Right now if you attempt to load an SWT file in the VE, it stalls during loading at around 25% complete until the connection to the beaninfo remote vm times out. It appears the cause of this is a bug with Apple's Java implementations in how it handles the Introspection of javabeans. When Introspecting, it only looks for matching beaninfo based on the class name, not the full package and class name. So when we introspect SWT's Dialog class it tries to load beaninfo for AWT's Dialog class instead. And in introspecting AWT's Dialog, it launches AWT, which causes the well known problem of SWT/AWT thread conflicts - which is why the VM freezes (see bug 67384 ). The problem with the Introspector was present in Sun's JREs up till 1.4.2 (which is why SWT development with the VE on other platforms requires 1.4.2 or later). So it looks like we'll have to open a bug report against Apple and hope it gets looked at soon.
Thats bad news :( It's the same behaviour with Java 1.5.0 too. Taken how long it took Apple to release 1.5.0 after Suns, I guess we will have to wait for a long time for this Bug to get fixed :( Have you already filed in the Bug, or should I take care of it? BR; MaC
Oh and BTW: grats to your Mac Mini :)
OK, it looks like I jumped the gun at blaming Apple :) Looking into the problem a little further, I disccovered that AWT is being loaded by simply introspecting a class with the same name as the SWT class being introspected. When searching for the explicitBeanInfo for the SWT Dialog class, it first finds the beaninfo for the AWT Dialog class, who's BeanDescriptor loads the Dialog class itself. This problem appears to be fixed by passing in -Djava.awt.headless=true as an argument while launching the beaninfo remote vm. So right now I have VE opening an SWT class with no errors, but nothing showing up in the graphical canvas. Progress!
I've managed to get image capture of SWT semi-working within the VE. However SWT switching to using HIView in 3.2 M3 has caused a regression with the capture mechanism that prevents the image being captured if the remote vm window is obscured or off screen. See bug 115221.
Created attachment 29400 [details] Screenshot of initial working version of SWT I've hacked up an ImageCapture class based on the code bill@hutten.org provided. The capture mechanism doesn't work perfectly, nor is it elegant, but it's a start.
Adding Silenio to the CC for consideration of comment #74.
For those interested in VE support for SWT development on OS X, an initial working out of the box version of this is available in the latest integration build of VE (I20051130). Play around with it, and open bug reports with me (jeff.myers@eclipse.org) as the owner for issues that come up.
Just to provide a status update on this bug report - many improvements towards support for OS X have been made for VE 1.2 M1 - see bug 119355, bug 119549, bug 120250. On the Swing side, I just addressed bug 120279, so the appearance of JFrames and JDialogs will be much improved in the next VE builds. I encourage everyone to try out the latest VE build on OS X and report problems in bugzilla. Special attention should be given toward random lock ups that can occur - if you run into this problem please add a comment to bug 119530.
We're decided to call OS X supported for SWT and Swing development in VE 1.2. AWT is still not supported - see bug 123850
Closing now that VE 1.2 is released.
