Bugzilla – Full Text Bug Listing
| Summary: | DTerm isn't able to determine working directory | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kathryn Huxtable <kathryn> |
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | remy.suen, skovatch |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Kathryn Huxtable
I suspect this has something to do with Accessibility on Mac OS X. DTerm might be taking the file from NSWindow's representedFilename/representedURL. Since we don't set it, DTerm simply falls back to the default directory. I'm not sure whether this could be done in a platform independent way. I'm assigning to SWT for comments. (In reply to comment #2) > DTerm might be taking the file from NSWindow's > representedFilename/representedURL. Since we don't set it, DTerm simply falls > back to the default directory. I think you're right. An untitled TextEdit document or Safari window has the same behavior. > I'm not sure whether this could be done in a platform independent way. I'm > assigning to SWT for comments. Unless Windows 7 and GTK have added a way to put a proxy icon in the title bar, I can't think of a good SWT-level fix for this. You could certainly write an OS X-only plugin to do it, though. (In reply to comment #3) > (In reply to comment #2) > > DTerm might be taking the file from NSWindow's > > representedFilename/representedURL. Since we don't set it, DTerm simply falls > > back to the default directory. > > I think you're right. An untitled TextEdit document or Safari window has the > same behavior. > > > I'm not sure whether this could be done in a platform independent way. I'm > > assigning to SWT for comments. > > Unless Windows 7 and GTK have added a way to put a proxy icon in the title bar, > I can't think of a good SWT-level fix for this. You could certainly write an OS > X-only plugin to do it, though. So you're saying that *if* that's what DTerm is doing, then I should be able to write an Eclipse plugin to solve my problem? (I've asked Decimus support if that is, in fact, what DTerm is using...) -K (In reply to comment #4) > So you're saying that *if* that's what DTerm is doing, then I should be able to > write an Eclipse plugin to solve my problem? That's right. When a file editor becomes focused you can get the current Shell, and use reflection to get at the 'window' field. Then you would need to call setRepresentedFileName and give it the full path to the file in the active editor. Make a selector by calling OS.sel_registerName("setRepresentedFileName:"), and then use org.eclipse.swt.internal.cocoa.NSString.stringWith(String) to convert the Java string to an NSString. Invoke the method with OS.objc_msgSend(winidow.id, selector, your_string.id), and you should see the Finder icon for the file appear in the title bar. And then, if you command-click the icon you'll get the popup with the containment hierarchy for the file. The danger is that you can also drag that icon to the Finder, which could potentially move the file, but since the SWT does not implement window:shouldDragDocumentWithEvent:from:withPasteboard: that may not be an issue. > (I've asked Decimus support if that is, in fact, what DTerm is using...) The answer to that is provided in the DTerm help, as it turns out: "DTerm uses the same Accessibility API used to provide information to screen readers and VoiceOver to obtain information about the frontmost window when you activate DTerm. If the window represents a document, well-behaved applications will provide the location of the document file to the Accessibility system, allowing DTerm to provide a context-sensitive interface for documents in nearly any application. (If a window does not represent a document, or does not provide the document's location to the Accessibility system, DTerm will open a window set to your home directory, attached to the top of the screen.)" In Cocoa, the way to indicate whether or not a window represents a document is to call setRepresentedFileName:, as described above. The SWT has no concept of a document, so there's no way we could address this at the SWT level. (In reply to comment #5) > (In reply to comment #4) > > > So you're saying that *if* that's what DTerm is doing, then I should be able to > > write an Eclipse plugin to solve my problem? > > That's right. When a file editor becomes focused you can get the current Shell, > and use reflection to get at the 'window' field. Then you would need to call > setRepresentedFileName and give it the full path to the file in the active > editor. > > Make a selector by calling OS.sel_registerName("setRepresentedFileName:"), and > then use org.eclipse.swt.internal.cocoa.NSString.stringWith(String) to convert > the Java string to an NSString. Invoke the method with > OS.objc_msgSend(winidow.id, selector, your_string.id), and you should see the > Finder icon for the file appear in the title bar. And then, if you > command-click the icon you'll get the popup with the containment hierarchy for > the file. > > The danger is that you can also drag that icon to the Finder, which could > potentially move the file, but since the SWT does not implement > window:shouldDragDocumentWithEvent:from:withPasteboard: that may not be an > issue. Yes, I created a simple Cocoa app with no representedFilename (lowercase "n" for "name", BTW) and DTerm didn't recognize it. Then I set an existing filename for the representedFilename property and it added the icon and DTerm recognized the directory. I haven't written an Eclipse plugin since version 2.x. What kind of plugin do I write to get access to file editor's becoming focused? And thanks, by the way, for all your help! (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > > > So you're saying that *if* that's what DTerm is doing, then I should be able to > > > write an Eclipse plugin to solve my problem? > > > > That's right. When a file editor becomes focused you can get the current Shell, > > and use reflection to get at the 'window' field. Then you would need to call > > setRepresentedFileName and give it the full path to the file in the active > > editor. > > > > Make a selector by calling OS.sel_registerName("setRepresentedFileName:"), and > > then use org.eclipse.swt.internal.cocoa.NSString.stringWith(String) to convert > > the Java string to an NSString. Invoke the method with > > OS.objc_msgSend(winidow.id, selector, your_string.id), and you should see the > > Finder icon for the file appear in the title bar. And then, if you > > command-click the icon you'll get the popup with the containment hierarchy for > > the file. > > > > The danger is that you can also drag that icon to the Finder, which could > > potentially move the file, but since the SWT does not implement > > window:shouldDragDocumentWithEvent:from:withPasteboard: that may not be an > > issue. > > Yes, I created a simple Cocoa app with no representedFilename (lowercase "n" > for "name", BTW) and DTerm didn't recognize it. Then I set an existing filename > for the representedFilename property and it added the icon and DTerm recognized > the directory. > > I haven't written an Eclipse plugin since version 2.x. What kind of plugin do I > write to get access to file editor's becoming focused? > > And thanks, by the way, for all your help! Okay, I have this working in the sense that when I press a key it sets the icon for the current editor in Eclipse. I just need to know how to make this happen automatically when an editor becomes active. (In reply to comment #7) > > I haven't written an Eclipse plugin since version 2.x. What kind of plugin do I > > write to get access to file editor's becoming focused? > > > > And thanks, by the way, for all your help! > > Okay, I have this working in the sense that when I press a key it sets the icon > for the current editor in Eclipse. I just need to know how to make this happen > automatically when an editor becomes active. You're far ahead of me in terms of plugin development -- I haven't done much in that area. You might want to have a look at "org.eclipse.ui.editorActions" <http://help.eclipse.org/galileo/topic/org.eclipse.platform.doc.isv/guide/workbench_basicext.htm> -- the example shows an editor action that becomes active when a Java file is *not* being edited, but you should be able to rework that to your needs. You might want to try one of the newsgroups; I'm not sure how much help I can offer you beyond this. Good luck! I'm marking this as WONTFIX as it's not possible to fix this in the SWT. But if you want to ask questions about using the SWT to implement it, feel free to do so. (In reply to comment #9) > I'm marking this as WONTFIX as it's not possible to fix this in the SWT. But if > you want to ask questions about using the SWT to implement it, feel free to do > so. Works for me. Thanks! |