Yes this would be a huge improvement for open tab management.

I don't think it is a good idea to use colors to distinguish file's location.

xDesign team may have other ideas how it could be indicated in the UI.

Ondro?

Reassigning to Ondrej for evaluation.

Well, it doesn't necessarily have to be based on file location. I think it would be great to have a config parameter in layer.xml for tab color on file templates. So when you create a file from a template that has a this parameter, that will be the color of the tab (unless you turn that feature off in options). Similar to how you set the icon for the file template.

Then we could have model, view, and controller templates all with different tab colors. Something like this:
<attr name="SystemFileSystem.tabcolor" stringvalue="#3366FF"/>

So the complete template entry in layer.xml would look like this: 

<file name="Controller_Basic" url="templates/controllers/Basic.html">
    <attr name="template" boolvalue="true"/>
    <attr name="SystemFileSystem.localizingBundle" stringvalue="org.myorg.kohananetbeans.Bundle"/>
    <attr name="SystemFileSystem.icon" urlvalue="nbresloc:/org/myorg/kohananetbeans/icon.png"/>
    <attr name="SystemFileSystem.tabcolor" stringvalue="#3366FF"/>
    <attr name="templateWizardURL" urlvalue="nbresloc:/org/myorg/kohananetbeans/templates/controllers/Basic_Description.html"/>
    <attr name="javax.script.ScriptEngine" stringvalue="freemarker"/>
</file>

Changed title back... because colored tabs is exactly what we want. Think Colored Firefox tabs.

If the request really is expressed as "colored tabs" (not "allow distinguishing files with same filenames") ,I tend to say wontfix, only adds complex to configure and hidden feature which would in the end be used by very few power users. 

Note that this may be extremely complex to work properly on all color schemes including negative ones. 

IMO not worth the implementation effort.

(In reply to comment #6)
> If the request really is expressed as "colored tabs" (not "allow distinguishing
> files with same filenames") ,I tend to say wontfix, only adds complex to
> configure and hidden feature which would in the end be used by very few power
> users. 
> 
> Note that this may be extremely complex to work properly on all color schemes
> including negative ones. 
> 
> IMO not worth the implementation effort.

I am certainly not a POWER USER.  This was just an annoyance that I observed within 15 minutes of installing and using the product.  I just wanted to bring it to your attention that it is not easy to distinguish tabs with same file names. If you feel that there is a better solution than colored tabs then by all means incorporate that solution.  But it seems as though you don't want to recognize this as a worthy enhancement just because it is labeled as "colored tabs". 

But thanks for your time anyway.

OK, ok... I can understand NO on the colored tabs, but SOMETHING should be done. Now, I realize you can hover over the tabs and it will show you the full path, but that path could be incredibly long and may run-off the screen. Plus sometimes you just want to glance over to see what file your on.

So, how about adding the path to the file in the Navigator Window? However, display the shown text from right to left and hide the beginning part of the path to fit within the space available. Which would look like this:

| ..some\path\to\file.php - Navigator |

The amount of text shown would depend on the size of the window.

Second, how about highlighting and focusing on the file within the Projects/Files windows when its tab has focus similar to how the Navigator updates when a tab is clicked? So as your clicking on tabs, the Projects and Files windows are updating and highlighting that file.

Finally, how about adding an Open Files Navigator that list the current open tabs. When you click on each item in the list it would focus that item's tab. Its a window that allows you to organize the tabs. Then you could have the local history of that tab underneath it. It could look like this:

| Open Files Navigator |
+ welcome.php (..some\path\to\1\welcome.php)
+ welcome.php (..some\path\to\2\welcome.php)
- welcome.php (..some\path\to\3\welcome.php)
  - File version 11/10/2010 9:19 AM
  - File version 11/09/2010 10:20 PM
+ welcome.php (..some\path\to\4\welcome.php)

jeremy.f76: Please file these enhancements as standalone bugs, so that we don't loose track of them - they have essentially no relation to this issue.  

UI solution to this issue: 
---
If a file is open which has the same name as one of already open files plus they are in folders of different names: show the tab title as "folder/file" (abbreviate folder if too long) for both files 

If a file is open which has the same name as one of already open files, they're in folders of same names but in a different project, show file title as "project: file" for both files (abbreviate project if too long) for both files. 

Yes, both cases will cause the list of tabs to "jump", but I don't see this as a major issue given this will generally mostly impact users who use such frameworks and for them, it'll be a reasonable tradeoff.  

Would that solve the issue?

I will add those other ideas as feature requests, thanks.

I would say thank you for addressing the problem. There are a few situations where that wouldn't work though...

1. Files with the same directory name and in the same project. This could happen quite a bit depending how a project is organized.

/model/user.php
/view/admin/user/form.php
/view/user/user/form.php


Or when working with different versions of a site (live and test):

/live/controller/welcome.php
/test/controller/welcome.php


2. Working with many open tabs, longer tab names means less tab real estate which means having to scroll documents left and right more often to find the correct file.

<rant> 
Now, I know you guys are against colors for some odd reason. However, if you go into a doctor's office, and if they still haven't gone paperless, one of the first things you will notice about the thousands of files is that they are color coded... The human eye can pick out color far faster and easier than reading text. Plus it requires less tab space to implement. 

Now I mentioned using templates before, but that doesn't have to be the way its implemented. Take a look at PHPStorm, they paint their files by setting up scopes, which are just a set file matching patterns. If the file matches the pattern, it gets colored a certain way. See here: http://blogs.jetbrains.com/webide/2010/04/paint-you-files-to-make-them-stand-out/

Komodo has a plugin that does it too, see here: http://dafizilla.sourceforge.net/colortab/screenshots.php

I still feel strongly that using colors as a visual queue would be a better solution than adding more text to the tab. 

1. Quicker to pick out visually.
2. tabs are smaller and can have more open without scrolling
3. User defined pattern matching allows detailed customization
4. Done right, it will visually enhance the development experience
</rant>

There used to be a time when color coded syntax highlighting used to not exist either. What happened to those IDEs that failed to implement that feature? How many IDEs are around that thought color in text files was a ridiculous idea and too hard to implement?

Colors would be my 1st choice as a solution.
However, how about an .ico image as an identifier?  It would take up less space than an abbreviated path+file name. And all browser use them. My firefox tabs have them as well.

This is surely a duplicate of a set of issues filed a year or two ago. Not sure how to find them now. Too many issue reports, too few people evaluating them.

could we make the tabs taller (2/3 line?):

 +---------------+
/    Filename.ext \
| last few chars  |
| of path         |
-------------------

tabs are evil for file names - they become too wide. And for MVC project I often have x10 files open at the same time. The most common buttons I click are the ones that scroll the editor tabs left and right.

My other suggestion would be to have the tabs movable so you can drag and attach them to the side of the editor window. They could sit above the 'Projects' window and they'd look a little like the Firefox Add Ons manager:

http://blog.mozilla.com/addons/2011/03/22/firefox-4-add-ons/

or like the "too many tabs" extension for chrome:

https://chrome.google.com/webstore/detail/amigcgbheognjmfkaieeeadojiibgbdp

tab management is a pain :)

*** This bug has been marked as a duplicate of bug 178090 ***