Bug 20669 - [EditorMgmt] tabs: Need a constant location to display the name of the file being edited
Summary: [EditorMgmt] tabs: Need a constant location to display the name of the file b...
Status: RESOLVED WORKSFORME
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.0   Edit
Hardware: All All
: P3 enhancement with 3 votes (vote)
Target Milestone: ---   Edit
Assignee: Boris Bokowski CLA
QA Contact:
URL:
Whiteboard:
Keywords: investigate
: 29005 29552 32203 77932 86154 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-06-19 12:43 EDT by Cedric Beust CLA
Modified: 2007-06-19 14:59 EDT (History)
13 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cedric Beust CLA 2002-06-19 12:43:35 EDT
I find it difficult to know the name of the file I am editing.

While it is indeed available at several places, none of them is really 
obvious:

- The tab on the editor folder is usually abbreviated to the first four 
letters with ellipses, because I usually have quite a few files open

- The package explorer/hierarchy doesn't make it readily apparent (and 
sometimes, it scrolls off anyway)

- Same remark for the Outline view:  if you have a lot of 
methods/fields/imports, the name of the class quickly scrolls out of view

I would love to have the name of the current buffer at a constant location, 
maybe at the bottom right, near the "Writable | Insert | Line:Column" 
labels.
Comment 1 Kai-Uwe Maetzel CLA 2002-06-19 15:54:36 EDT
Ajusting priority. Post 2.0
Comment 2 Randy Giffen CLA 2002-08-12 10:58:06 EDT
Reopened for investigation
Comment 3 Todd Chambery CLA 2002-10-18 16:43:21 EDT
I second this request (if that's what you do with bugs :)).  In my current
workspace I have two branches of the same project, so when working on file X
from project A, and file X from project B, I find that I have to move the mouse
and hover to know which one I'm editing.  In the package explorer, the project
name is expanded out of view, so that doesn't help.

I think this feature might could be expanded to include display of metadata from
any view that supplied that information (on the editor it would be the filename).
Comment 4 Andrew Irvine CLA 2002-12-12 17:53:20 EST
Eclipse 20021213

A new view was introduced (Window>Show view>Other>Basic>Editors) that may 
provide some relief for your issues.  If realestate (sp) is a big issue you can 
set the view so it sorts by MRU (most recently used) and then make the view so 
it is only one file high.  You can then set the option to see the full path 
name.  Then the file name will always be in one location, wherever you chose to 
dock the view (maybe below the default tasks view location).
Comment 5 Andrew Irvine CLA 2003-01-06 11:14:46 EST
*** Bug 29005 has been marked as a duplicate of this bug. ***
Comment 6 Todd Chambery CLA 2003-01-13 11:42:14 EST
The editor view workaround is not a half-bad solution, except that I need know
not just the filename but the project the file is in.  I have three projects in
my view all of which have different versions of the same (or mostly the same)
files.  I can "Show Full Name" to get the project the file is associated with,
but this then pushes the filename out of the view.  Incidentally, the Editor
view doesn't remember the "Show Full Name" setting.

The filename - project/src folder info is displayed in the status bar when the
file is selected in the Package Explorer view...

Would the eclipse guys consider a patch (this is one I think I can do), or is
the solution to this contained in a set of larger fixes?
Comment 7 Andrew Irvine CLA 2003-01-13 15:00:27 EST
The format of the output in the status line displayed when selecting files in 
the package explorer is specific to the java environment.  Moving to JDT Text 
for their input.

Bug 29410 will address the issue of the view and dropdown list not remembering 
the "Show Full Name" setting
Comment 8 Sonia Dimitrov CLA 2003-01-16 09:01:02 EST
*** Bug 29552 has been marked as a duplicate of this bug. ***
Comment 9 Sonia Dimitrov CLA 2003-02-20 10:47:58 EST
*** Bug 32203 has been marked as a duplicate of this bug. ***
Comment 10 Erich Gamma CLA 2003-02-21 04:38:04 EST
Regarding comment #7

The Java views show the fully qualified name of the selection with the 
containing project as a suffix.

In the Java editor the status line is used for dynamic messages and showing the 
name of the edited file there would not be useful.

Moving to platform-ui since this is a general editor management issue.
Comment 11 Gilles Scokart CLA 2003-02-21 04:56:08 EST
It's more "classical" to use the window title for fully quallifed name instead 
of using the status bar.  That's indeed what most editors does, at least on 
Windows (expl: all Microsoft apllication like Excell or Word, Ultra Edit, 
etc.).  And there is good reason for that : 
1. That's the place where you have the more space on a window.
2. That's esier to visualize that in the task bar.
3. This title is used by the window manager for different things like switching 
between windows, iconize, etc.  If you have one window per project, it could be 
usefull to see the project name in the window title for those operations.
Comment 12 Ed Burnette CLA 2003-02-22 18:57:14 EST
While the cursor is in the text editor and there's nothing better to display 
in the status line, why not display the full path there? Also it would be nice 
if the context menu for all text editors (plain text, java comp unit, etc.) 
would include a "Properties" menu at the end. Especially with back-linking 
disabled. I'll enter that as a separate enh request if there's not one already.
Comment 13 Ed Burnette CLA 2003-02-22 19:04:31 EST
Added bug 32573 for the properties menu enhancement mentioned in comment #12.
Comment 14 Todd Chambery CLA 2003-03-04 11:39:08 EST
I totally agree with comment <a
href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=20669#c12">12</a>.  

Regarding comment <a
href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=20669#c10">10</a>
 
I just don't believe the display of the filename (and the project path) would
conflict with messages from editor.  Just make the filename the low priority
consumer of the status line instead of blank space.  A number of editors have
this very same functionality, EditPad for instance (since that happens to be
what I'm using at the moment).

I think the utility of this enhancement is obvious given my <a
href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=20669#c3">previous comment</a>
Comment 15 Douglas Pollock CLA 2004-11-08 10:14:43 EST
*** Bug 77932 has been marked as a duplicate of this bug. ***
Comment 16 Douglas Pollock CLA 2005-02-22 12:50:22 EST
*** Bug 86154 has been marked as a duplicate of this bug. ***
Comment 17 Michael Van Meekeren CLA 2006-04-21 13:19:36 EDT
Moving Dougs bugs
Comment 18 Kim Horne CLA 2007-02-02 13:39:48 EST
Given that the filename is now displayed in both the window title and in the tab (and wont be abbreviated by ellipsis) I'm inclined to close this.  Please reopen if you don't agree.
Comment 19 Warren Paul CLA 2007-03-26 12:29:26 EDT
We're shipping IDE's based on Eclipse and have had several customers ask for this feature.  There is currently no way to get the full file system path of a file being edited.  The window title and tab only show you the filename, which isn't much help if you have mutliple files of the same name in the workspace.  The tooltip on the editor tab gives you the workspace relative path, but for many people this isn't enough.  For one it's an extra step.  Plus you have to use the mouse.  Then there are those people that don't even know what this relative path means.  Most of our users create projects outside of the workspace and get confused when trying to put together what the full file system path is.

The status line is mostly unused by editors.  Most editors use it to display annotations.  When no annotation is at the cursor, nothing is displayed in the status line.  Why not display the full file system path in the status line by default (I guess in EditorPart), then any editors can override this default behavior as they see fit?  I think to ask each individual editor to do this if they want would only cause inconsistencies.  I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=179127 against the CDT editor, but it was (wisely) pointed out that this wouldn't fit with other Eclipse editors.

I don't see a way to reopen this but I think it should be strongly considered.
Comment 20 Kim Horne CLA 2007-03-26 15:37:17 EDT
Reopening to reassign
Comment 21 Kim Horne CLA 2007-03-26 15:37:46 EDT
Boris, could you throw your two cents in on this one?
Comment 22 Boris Bokowski CLA 2007-03-26 16:25:50 EDT
(In reply to comment #19)
> ... The window title and tab only show you the filename, which
> isn't much help if you have mutliple files of the same name in the workspace. 

The window title shows the full (workspace-relative) path.

> The status line is mostly unused by editors.

Yes, but trim space is a scarce resource, and I'm not sure if it would be a good idea to show the full path in the status line whenever the editor does not show a specific message.  Currently, placing the cursor within an error or warning will show details in the status line, and users can notice the change in the UI easily because the status line was previously blank.  If we ended up showing information all the time, we would lose this.

BTW, by passing -showLocation as a command line argument, Eclipse will show the workspace location in the window title, in addition to the path of the file being edited.  I understand that this still does not give you what you want since apparently your users frequently use projects that are not part of the workspace.  So perhaps we should show the full path instead of the workspace-relative path and the workspace location?
Comment 23 Warren Paul CLA 2007-03-26 16:32:50 EDT
(In reply to comment #22)
> The window title shows the full (workspace-relative) path.
Sorry, I'm using 3.2.1 so maybe it's been changed in a newer build.

> > The status line is mostly unused by editors.
> Yes, but trim space is a scarce resource, and I'm not sure if it would be a
> good idea to show the full path in the status line whenever the editor does not
> show a specific message.  Currently, placing the cursor within an error or
> warning will show details in the status line, and users can notice the change
> in the UI easily because the status line was previously blank.  If we ended up
> showing information all the time, we would lose this.

OK, fair enough.

> BTW, by passing -showLocation as a command line argument, Eclipse will show the
> workspace location in the window title, in addition to the path of the file
> being edited.  I understand that this still does not give you what you want
> since apparently your users frequently use projects that are not part of the
> workspace.  So perhaps we should show the full path instead of the
> workspace-relative path and the workspace location?

This sounds like a fair compromise.  Plenty of editors use the window title for this purpose so it's pretty consistent, and won't affect the status line.  +1 from me.

Comment 24 Boris Bokowski CLA 2007-03-27 13:01:27 EDT
As it turns out, this is not as simple as I thought.  In the window title, we display whatever the current editor sets as their tooltip text.  Java and text editors show the workspace-relative path, other editors might show something else.  Because of this, we cannot easily change the window title to show the full path instead of the workspace-relative path.  Any ideas?
Comment 25 Warren Paul CLA 2007-03-27 13:39:38 EDT
It looks like the tooltip text comes from IEditorInput#getToolTipText.  Unfortunately this interface is implemented by a lot of classes.  It looks like the main classes of interest though are FileEditorInput and JavaFileEditorInput.  Maybe we could change getToolTipText for these classes to be something like this:

    public String getToolTipText() {
    	IPath location = file.getLocation();
    	if (location != null) {
        	return location.makeRelative().toString();
   	    }
    	return file.getFullPath().makeRelative().toString();
	}
Comment 26 Boris Bokowski CLA 2007-06-19 14:59:25 EDT
(In reply to comment #25)
> ... It looks like
> the main classes of interest though are FileEditorInput and
> JavaFileEditorInput.

Please file individual bugs against Platform/IDE and JDT/UI for this.  I'm closing this bug, it's just not useful anymore given its age and the number of different things that have been requested.  See comment #22 for how you can get the full path and the workspace location into the window title area.