Community
Participate
Working Groups
Investigate implementing open document support as well as extended applescript support on OS X.
I haven't had time to look into this much unfortunately. I have some mid-session patches that add an applescript handler but the problem is our launcher. I believe it needs to be the one intercepting the events, not the eclipse process. I'll attach what little I have for any interested parties to dissect. Please not that these patches were created against revisions from HEAD from sometime in late August/early September. They might need some massaging to be applied to HEAD today.
Created attachment 30487 [details] Patch against org.eclipse.swt
Created attachment 30488 [details] Patch against org.eclipse.ui.carbon
So, Galileo on the Mac is using Cocoa. I just saw the preso at WWDC and heard Scott Kovatch talking about it. If eclipse is using Cocoa, then AppleScriptability becomes much easier. Yet, I try to examine the script dictionary of Galileo and Script Editor says that the app is not scriptable. That is unfortunate. On the plus side, one can see Accessibility information in the eclipse interface (both 3.4 and 3.5). If one has accessibility, scriptability is usually not extremely difficult to add. Scriptability would help with testing and there would be many other salutary effect. Let me know if you need arguments in support. I can get them, if needed.
I am excited that there is motion on this bug. I wanted to explain some things that I hope will be possible once the feature is in. If AS is enabled for eclipse, I am hoping to be able to use it to test the interface that has been developed for the WOLips plugin. It is, right now, non-trivial to test the interface for reasons that I am sure are familiar to most of you. I wanted to call out that, while any AppleScript-ability is good, there are things that can be done to make it easier to use. UI elements can be labelled with the appropriate names. If one can say "the console panel" instead of something like "panel 3 in tab 2 in the main window", it will be easier to write scripts against the UI. The only reason I suspect this will be is an issue is that I see the way things are layed out in the Accessibility Inspector. For example, hover over the console tab and one sees: <AXApplication: "Eclipse"> <AXWindow: "WOLips - Eclipse Platform - /Users/ray/Documents/workspace"> <AXStatic Text: "text"> Attributes: AXValue: "" AXRole: "AXStatic Text" AXRoleDescription: "test" AXParent: "<AXWindow: "WOLips - Eclipse Platform - /Users/ray/Documents/workspace">" AXWindow: "<AXWindow: "WOLips - Eclipse Platform - /Users/ray/Documents/workspace">" AXTopLevelUIElement: "<AXWindow: "WOLips - Eclipse Platform - /Users/ray/Documents/workspace">" AXPosition: "x=301 y=582" AXSize: "w=973 h=133" AXEnabled: "true" As you can see, there is nothing here to associate this UI element with what is seen by the user as the "Console pane". In particular, none of the windows are given identifiers. If anyone has suggestions for the ornamentation of the UI, please let me know. I may need to create another bug, or find an appropriate existing bug. Let me know if anyone has questions or suggestions, and thanks again for taking the first steps here, with this bug. cheers - ray
(In reply to comment #5) > I am excited that there is motion on this bug. I wanted to explain some things > that I hope will be possible once the feature is in. Sorry to disappoint you, but we are just "moving around" bugs according to new conventions (see http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009). However, this is only a statement about what the current committers on the Platform UI component are planning to do. Feel free to contribute patches, or otherwise make progress on those features that are important to you. See http://wiki.eclipse.org/Platform_UI/How_to_Contribute > As you can see, there is nothing here to associate this UI element with what is > seen by the user as the "Console pane". In particular, none of the windows are > given identifiers. The reason for this is that some platforms (notably Motif) that we currently support do not allow reparenting of widgets. To allow users to rearrange views without having to dispose and recreate the underlying widgets, the widget hierarchy does not match what you would expect by looking at an Eclipse window. The view- or editor-level top composites are all parented off of the same common composite and then moved to the appropriate positions as the user moves view tabs / editor tabs / sashes. I haven't looked into this closely, but it may be easy to fix it all it takes is to set a property on some intermediate composite. We would certainly welcome a patch to fix just this problem.
Prakash is now responsible for watching bug in the [Mac] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
