Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 317507 - DTerm isn't able to determine working directory
Summary: DTerm isn't able to determine working directory
Status: RESOLVED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.6   Edit
Hardware: Macintosh Mac OS X
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-21 15:43 EDT by Kathryn Huxtable CLA
Modified: 2010-06-23 15:25 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kathryn Huxtable CLA 2010-06-21 15:43:37 EDT
Build Identifier: 20100218-1602

Install DTerm (http://www.decimus.net/dterm.php). This allows a Mac user to press Cmd-Shift-Enter and get a command line window with a directory already set to the directory of the top window. In normal Mac apps this works. In Eclipse it is my home directory.

Fixing this would make using command-line apps with Eclipse much easier.

Reproducible: Always

Steps to Reproduce:
1. Install DTerm (http://www.decimus.net/dterm.php). 
2. Run Eclipse and open a file in an editor window.
3. Press Cmd-Shift-Enter. You should see a DTerm window.
4. Enter "pwd" into the DTerm window and press Enter.
5. You will see your home directory instead of the directory for the file open in the IDE.
Comment 1 Kathryn Huxtable CLA 2010-06-21 15:44:20 EDT
I suspect this has something to do with Accessibility on Mac OS X.
Comment 2 Prakash Rangaraj CLA 2010-06-22 03:30:44 EDT
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.
Comment 3 Scott Kovatch CLA 2010-06-22 12:53:00 EDT
(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.
Comment 4 Kathryn Huxtable CLA 2010-06-22 18:08:18 EDT
(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
Comment 5 Scott Kovatch CLA 2010-06-22 18:34:16 EDT
(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.
Comment 6 Kathryn Huxtable CLA 2010-06-23 04:15:57 EDT
(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!
Comment 7 Kathryn Huxtable CLA 2010-06-23 06:46:04 EDT
(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.
Comment 8 Scott Kovatch CLA 2010-06-23 12:44:34 EDT
(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!
Comment 9 Scott Kovatch CLA 2010-06-23 12:49:42 EDT
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.
Comment 10 Kathryn Huxtable CLA 2010-06-23 15:25:29 EDT
(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!