I think 106311 is a different bug, but @nathanr is better qualified than I am to make that call: 106311 deals with why the “Open Files” panel seems to be using the system icons rather than Komodo’s new v9 approach to icons, while the last part of this discussion is about the inconsistency between the language icon (a gray “TXT” icon) in the language type selector from the status bar and the Komodo-generated file type icons (a brown “CFM”) for files of that CFML type. Related to this second aspect is whether the icon generation for the language type selector is or should be picking up something from the language extension itself for the default file type.
In my mind, there are at least two things here, and possibly three. To this point, I have not logged a bug for the second aspect of this (the inconsistency between the language type selector icon and its labeling vs the icons used for the Places panel and the tabs, and whether that language type selector icon should be being generated based on the extension defining that language type).
I will log this other part as a bug if that would help track it?
They’re all the same issue - tabs, places, languages - they are all accessing a new library which parses the request string into an icon. The bug is in figuring out how to map both extensions and language names to the same icon.
@nathanr The inconsistency is not between Places and the tab icon. Those two, I believe, have been consistent in these recent RCs. The current inconsistencies are that the icon used in Places and the tab is not the same icon as the file type/language icon in the menu from the status bar, and is not the same as the icon appearing in the Open Files panel (bug #106311). I don’t have a separate bug filed for the inconsistency with the languages menu from the status bar, given your comment above “They’re all the same issue…”
